Not every AI call needs to generate text

For the last few years, the default architecture for adding intelligence to software has been predictable: send application state to a general-purpose language model, ask for text or JSON, parse and validate the result, then decide what the application should do.

It is an understandable default. Modern language models can classify, summarize, reason, write code, and return structured output through the same interface.

But that flexibility can obscure a simpler question:

Does this operation need generated language, or does the software only need a judgment?

Many application decisions are small and bounded:

• Which category best describes this event?
• Does the available evidence support this claim?
• How severe is the impact?
• Should this item be handled automatically or reviewed?
• Which specialist model should receive this request?

We often send these questions to a large generative model, ask it to produce JSON, validate the response, and discard everything except one decision.

Jev, a new model from TypeSafe AI, proposes a different abstraction: intelligence as a typed software primitive.

From generated answers to bounded judgments

TypeSafe describes Jev as its first System One model—a model designed to make fast, structured decisions that software can consume directly.

An application gives Jev some state and one or more bounded questions. Instead of generating a paragraph, Jev returns typed answers and probability distributions.

Its current primitives are:

• Choice: select one option from a predefined set.
• Score: evaluate something against an ordered rubric.
• Noul: estimate the probability that a statement is true.

The model does not decide what arbitrary action to perform. The developer defines the possible answers before making the request.

state + bounded question → typed probabilities

This is narrower than a general-purpose language model. That is the point.

A Choice cannot invent a fourth operational team when the application supplies three. A Score cannot quietly replace the application's severity scale. A Noul produces a probability, not an unrestricted recommendation.

The semantic judgment can still be wrong. Type safety constrains the shape of the answer, not its truth. But the boundary between model behavior and application behavior becomes much clearer.

Intelligence as a software primitive

The interesting idea is not that Jev can classify something. Existing language models can already do that.

The interesting idea is how responsibilities are divided:

                    application
                         │
          ┌──────────────┼──────────────┐
          │              │              │
    deterministic     decision       generative
        code           model           model
          │              │              │
      certainty       judgment       creation and
      and policy     under ambiguity    reasoning

Deterministic code remains responsible for facts, policy, and side effects.

A decision model handles bounded semantic judgment. A generative or reasoning model handles problems that require explanation, creation, or deeper reasoning. Humans remain responsible for ambiguous or consequential decisions.

This avoids treating one model as the application, policy engine, decision-maker, and content generator at the same time.

Use code for certainty, decision models for judgment, and reasoning models for complexity.

A frontend observability example

Imagine a platform serving several independently deployed micro-frontends.

After a release, the observability system detects a JavaScript error-rate increase, a failure concentrated in Safari, a new error inside a payment component, no corresponding increase in payment API failures, and a meaningful but incomplete set of affected tenants.

Some parts of this incident are deterministic:

const startedAfterDeployment =
  incident.firstSeenAt > deployment.completedAt

const exceedsErrorBudget =
  incident.errorRate > configuredErrorBudget

Those comparisons do not need AI.

But other questions require judgment: does the evidence point to the frontend release or an upstream dependency? How severe is the demonstrated user impact? Is there enough evidence to request rollback review?

Those questions have bounded answers but cannot be expressed reliably as a few fixed conditions. A Jev request could look roughly like this:

const result = await client.systemOne({
  state: incident,
  questions: {
    owner: choice('Which area most likely owns this incident?', {
      frontend: 'The latest frontend release',
      dependency: 'An API or external dependency',
      environment: 'Browser, traffic or infrastructure',
      unknown: 'The evidence is insufficient',
    }),
    impact: score('How severe is the demonstrated user impact?', [
      'No meaningful impact',
      'Limited and recoverable degradation',
      'A major workflow fails for some users',
      'A critical workflow is broadly unavailable',
    ]),
    rollbackReview: noul(
      'Does the evidence justify immediate human rollback review?'
    ),
  },
})

The model's response should not trigger a rollback directly. Application policy still controls the permitted action:

const owner = result.answers.owner
const rollbackReview = result.answers.rollbackReview

if (
  owner.choice === 'frontend' &&
  owner.confidence > 0.9 &&
  rollbackReview.noul > 0.9
) {
  requestHumanRollbackReview()
}

The model decides what it believes. Code decides what it is allowed to do.

The application can use different thresholds for different consequences. Automatically assigning an incident is reversible and relatively low-risk. Rolling back production is not.

A medium-confidence answer might attach a suggestion. A low-confidence answer might request more telemetry. A high-confidence answer might page the appropriate engineer—but still require confirmation before a destructive action.

Why atomic questions matter

It is tempting to ask: “Analyze this incident, determine its cause, and take the best action.”

That combines several different judgments with application policy. If the result is wrong, it is difficult to identify whether ownership, impact, causality, or action selection failed.

A composable workflow asks smaller questions:

incident state
 ├── which subsystem likely owns it?
 ├── how severe is the demonstrated impact?
 ├── does timing support release correlation?
 └── is the evidence sufficient?

application code
 ├── combines the answers
 ├── applies risk thresholds
 ├── selects a permitted action
 └── records the outcome

TypeSafe recommends this decomposition: focused questions are evaluated independently, while application code combines the answers using explicit business logic. Questions using the same state can be evaluated together rather than through a chain of prompts. The Jev documentation explains this model in more detail.

This approach also improves testing. Instead of evaluating one opaque “incident agent,” a team can measure ownership accuracy, severity accuracy, false rollback escalations, missed high-impact incidents, human override rate, and confidence calibration independently.

A decision layer for coding agents

The same pattern becomes more interesting around AI coding agents.

An agent may produce a valid change, but the next step should not always be the same. Some changes need ordinary automated checks. Others need security review, browser testing, or deeper model analysis.

AI coding agent
       ↓
generated change
       ↓
decision layer
 ├── touches authentication?
 ├── changes database behavior?
 ├── affects a public API?
 ├── requires browser testing?
 └── contains security-sensitive logic?
       ↓
review route
 ├── standard CI
 ├── specialist model
 ├── expensive reasoning model
 └── human reviewer

Many signals should still come from deterministic tooling: which files changed, whether a migration exists, whether tests failed, whether a dependency changed, and whether a protected path was touched.

A decision model becomes useful for the semantic questions:

• Does this apparently small change alter authorization behavior?
• Does the implementation contradict the issue's acceptance criteria?
• Is the generated test asserting meaningful behavior or merely reproducing the implementation?
• Does the change require browser-level verification?

Jev should not approve security-sensitive code by itself. It could help select the review path.

This points toward a more economical AI architecture: inexpensive bounded judgments handle frequent routing decisions, while expensive reasoning is reserved for cases that actually need it.

Jev is not “an LLM, but faster”

Jev should not replace a generative model when the application needs a written explanation, summary, generated code, conversation, migration plan, or extended reasoning.

It should not replace ordinary code when the answer is deterministic: whether one date is later than another, a required property is missing, a user has permission, or a numeric threshold has been exceeded.

And typed output should not be confused with guaranteed correctness.

TypeSafe says Jev cannot produce type-invalid answers because its output is constrained to the supplied structure. But the company also acknowledges that the model can make incorrect judgments. Confidence is a signal that application architecture must use—not proof of correctness.

The company currently reports substantial latency and cost improvements for System One-shaped workflows. Those are promising but vendor-reported early-access results, with methodology and caveats published in TypeSafe's Jev announcement. Any production team should evaluate the model against its own data, risks, and thresholds.

The broader architectural shift

The first generation of AI applications often placed one large model at the center:

input → model → answer

A more mature architecture may look less dramatic:

input
  ↓
deterministic preparation
  ↓
small probabilistic judgments
  ↓
application policy
  ↓
reasoning model only when required
  ↓
human review when consequences demand it

This is not as visually impressive as an autonomous agent doing everything. It is probably easier to operate.

It gives teams explicit places to define what the model may decide, how uncertainty changes behavior, which operations are reversible, when a more capable model is justified, when a human must remain involved, and how each decision can be evaluated.

That may be Jev's most useful contribution, even before its performance claims are independently proven.

It encourages developers to stop treating “AI” as a single component and start treating different forms of intelligence as dependencies with separate responsibilities.

Not every AI call needs to generate text.
Sometimes software just needs a judgment.
The harder engineering problem is deciding what that judgment is allowed to do.