Jev: What Happens When AI Stops Generating and Starts Deciding?

PubDev — Sat, 26 Sep 2026 20:20:13 +0000

Jev: What Happens When AI Stops Generating and Starts Deciding?

For the last few years, the dominant interface to AI has been simple:

Give the model a prompt → generate tokens → parse the response → make a decision.

That architecture works extremely well when the output is meant for a human.

But what happens when the output is not meant for a human at all?

What if the only thing your software needs to know is:

Which workflow should run?
Is this request safe?
Should we call another model?
Is this customer review positive or negative?
Should this transaction be escalated?
Which tool should an AI agent use?
Is the model's previous answer good enough to continue?

For these problems, generating a paragraph of text can be unnecessary overhead.

This is where Jev, TypeSafe AI's first System One model, becomes interesting.

TypeSafe describes Jev as a model designed to make fast, structured decisions that software can consume directly rather than generating prose for humans.

And that introduces a fascinating architectural question:

Do AI systems need a dedicated decision layer alongside reasoning and generative models?

The fundamental difference: Generation vs. Decision

Traditional LLMs are primarily optimized for generating sequences of tokens.

Conceptually:

Prompt
   ↓
Token 1
   ↓
Token 2
   ↓
Token 3
   ↓
Token 4
   ↓
...
   ↓
Final response

If you ask an LLM:

"Classify this customer review as positive, neutral, or negative."

you may receive:

The customer appears to be expressing dissatisfaction
with the product because...

But your application doesn't need the explanation.

It needs:

{
  "sentiment": "negative"
}

So the traditional approach becomes:

Generate → constrain → parse → validate → handle errors → execute

Jev approaches the problem differently.

Instead of asking the model to write an answer, you define the possible decisions.

Conceptually:

Application State
       ↓
Typed Questions
       ↓
Candidate Decisions
       ↓
Probability Distribution
       ↓
Structured Decision

TypeSafe calls this family of models System One.

The idea is simple:

AI doesn't always need to speak. Sometimes it just needs to decide.

What does Jev actually return?

Instead of arbitrary generated text, Jev exposes structured decision primitives.

The public documentation describes three important types:

1. Choice

Select one option from a predefined set.

For example:

Question:
What type of customer issue is this?

Options:
- billing
- technical
- delivery
- account

The model can return a structured choice along with probabilities.

Conceptually:

{
  "choice": "billing",
  "probabilities": {
    "billing": 0.91,
    "technical": 0.04,
    "delivery": 0.03,
    "account": 0.02
  }
}

This is particularly useful for:

routing
classification
intent detection
agent selection
workflow selection

2. Score

Instead of selecting a category, the model can evaluate something on an ordered scale.

For example:

Customer urgency:
1 → 10

This can be useful for:

risk
urgency
quality
priority
relevance
confidence-based routing

3. Noul

A calibrated yes/no probability.

For example:

Should this transaction be reviewed?

Probability:
0.94

This creates a natural interface for:

guardrails
filters
approval gates
escalation
retry decisions
safety checks

These typed outputs are central to TypeSafe's System One approach.

Why is this different from structured output in an LLM?

At first glance, someone might ask:

"Can't I just ask GPT or Claude to return JSON?"

Yes.

And that is exactly what makes this concept interesting.

There is a fundamental difference between:

A language model generating JSON

and

A decision model whose output space is defined as a decision.

With an LLM, you are still fundamentally asking a generative model to produce a sequence.

You might write:

Return only JSON.

{
  "category": "billing"
}

Then your application still has to consider:

malformed JSON
unexpected fields
invalid enum values
explanations outside the JSON
refusal responses
schema violations
token generation latency

With a schema-constrained decision interface, the application defines the possible output space.

That dramatically simplifies the software contract.

However, an important distinction is necessary:

Schema constraints do not mean the model can never be wrong.

A model can return a perfectly valid billing classification when the correct answer was actually technical.

So the more accurate statement is:

Jev can eliminate many classes of format/output hallucinations, but it does not eliminate semantic errors.

This distinction matters enormously when designing production AI systems.

The latency argument

This is where Jev becomes particularly interesting for real-time systems.

TypeSafe currently reports Jev response latency in the range of approximately 70–500 ms, depending on workload and conditions. TypeSafe also reports substantially higher efficiency compared with frontier LLM decision paths. These figures are vendor-published performance claims rather than a universal independent benchmark.

Why could this matter?

Imagine an AI agent performing a workflow:

User
 ↓
Agent
 ↓
LLM reasoning
 ↓
Tool selection
 ↓
API call
 ↓
LLM reasoning
 ↓
Validation
 ↓
Another decision
 ↓
Final response

If every tiny decision requires a large generative model, latency and cost can accumulate rapidly.

Now imagine separating responsibilities:

                 ┌───────────────┐
                 │  Reasoning LLM│
                 └───────┬───────┘
                         │
                 Complex reasoning
                         │
                         ▼
              ┌────────────────────┐
              │   Decision Layer   │
              │       Jev          │
              └─────────┬──────────┘
                        │
             Fast structured choice
                        │
                        ▼
                 Application

The LLM handles the difficult reasoning.

The decision model handles the repetitive decisions.

That is a much more interesting architecture than simply trying to replace every LLM with another model.

Non-autoregressive thinking

One of the most interesting aspects of Jev is the move away from conventional token-by-token generation.

Traditional autoregressive generation works approximately like:

Generate token 1
      ↓
Generate token 2
      ↓
Generate token 3
      ↓
Generate token 4
      ↓
...

The sequence creates an inherent dependency between generation steps.

Jev's public description instead emphasizes parallel decision evaluation rather than sequential token generation. TypeSafe describes its stack as using a parallel sampler designed for efficiency.

The important architectural idea is therefore:

        State
          │
          ▼
    ┌─────────────┐
    │ Decision    │
    │ Evaluation  │
    └──────┬──────┘
           │
    ┌──────┼──────┐
    ▼      ▼      ▼
 Choice  Score   Noul
    │      │      │
    └──────┼──────┘
           ▼
    Structured Output

There is no need to stream a paragraph to the user.

The system is evaluating a defined decision space.

That is a fundamentally different interface.

The e-commerce review example

Consider an e-commerce platform receiving thousands of reviews.

A traditional LLM pipeline might look like:

Review
  ↓
LLM
  ↓
Generated explanation
  ↓
JSON extraction
  ↓
Validation
  ↓
Database

But what do we actually need?

Perhaps:

sentiment
urgency
topic
requires_response

Jev can be thought of as a decision layer:

Review
  │
  ├── Sentiment → positive / neutral / negative
  │
  ├── Topic → product / delivery / payment / support
  │
  ├── Urgency → 1–10
  │
  └── Response Required → probability

The result can immediately feed business logic.

For example:

if sentiment == "negative" and urgency >= 8:
    escalate_to_support()

or:

if response_probability > 0.85:
    create_support_ticket()

This is where the model becomes more like a decision API than a chatbot.

Why confidence matters

One of the most interesting parts of the System One approach is the emphasis on calibrated probabilities.

A conventional classifier might simply say:

negative

A decision system can instead expose:

positive:  0.02
neutral:   0.08
negative:  0.90

Now the application can make its own decision.

For example:

> 0.90
Automatic action

0.60 – 0.90
Additional validation

< 0.60
Human review

This creates a powerful separation:

The model makes an assessment.
The application decides what to do with that assessment.

That distinction is extremely important for production AI.

Also, confidence should not automatically be interpreted as correctness. TypeSafe's benchmark material explicitly distinguishes confidence from guaranteed correctness and emphasizes calibration against real labeled data.

Jev + LLMs instead of Jev vs LLMs

This is probably the most interesting way to think about the technology.

The future doesn't necessarily look like:

Jev replaces LLMs

It may look more like:

              AI SYSTEM
                  │
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
   Reasoning LLM       Decision Model
        │                   │
        │             Fast routing
        │             Classification
        │             Guardrails
        │             Validation
        │             Scoring
        │                   │
        └─────────┬─────────┘
                  ▼
             Application

Different models can specialize in different computational jobs.

LLM

Best suited for:

reasoning
generation
summarization
coding
planning
open-ended interaction

Decision model

Potentially useful for:

classification
routing
gating
ranking
validation
risk scoring
guardrails
real-time decisions

That creates a multi-model AI architecture.

What this could mean for AI agents

Modern agents often spend surprisingly large amounts of compute on small decisions.

For example:

Should I call the database?

Should I retry?

Should I ask the user?

Which tool should I use?

Should this answer be accepted?

Should this request be escalated?

Which model should handle this task?

Not every question requires a 100-billion-parameter reasoning model.

A fast decision layer could sit between the agent's components.

Imagine:

User Request
     ↓
Reasoning Model
     ↓
Decision Gate
     ↓
 ┌───┼────┐
 ▼   ▼    ▼
Tool A Tool B Human

This could potentially reduce unnecessary expensive model calls while making the control flow more explicit.

Real-time UI engineering

There is another application I find particularly interesting.

Modern applications increasingly contain AI-powered interfaces.

Imagine a mobile application that continuously needs to determine:

Should this recommendation appear?

Should this button be enabled?

Should the user see this warning?

Which onboarding path should be shown?

Should we trigger a notification?

Which UI component should appear next?

A full LLM call for every interaction can introduce unnecessary latency.

A specialized decision model could potentially become an AI decision layer for dynamic interfaces.

That creates an interesting architectural pattern:

User Interaction
       ↓
Application State
       ↓
Fast AI Decision
       ↓
UI State
       ↓
Rendered Interface

For mobile and web developers, this is a particularly interesting direction.

But Jev is not a replacement for everything

It is important not to overhype the idea.

A decision model is naturally limited when the problem itself is open-ended.

If you need:

"Write a detailed product description."

Use a generative model.

If you need:

"Explain why this architecture is better and propose three alternatives."

Use a reasoning-capable LLM.

If you need:

"Choose one of these predefined workflows."

A specialized decision model becomes much more interesting.

The architectural question is therefore not:

Which model is the smartest?

It is:

Which model is appropriate for each computation?

The bigger paradigm shift

For me, the most interesting idea behind Jev isn't simply speed.

It is the separation of generation from decision-making.

For years, we have increasingly treated LLMs as a universal AI primitive:

Everything → Prompt → LLM → Text

System One suggests another abstraction:

State → Decision → Structured Result

And a mature AI application might eventually combine both:

                 APPLICATION
                      │
          ┌───────────┴───────────┐
          │                       │
          ▼                       ▼
   GENERATIVE LAYER         DECISION LAYER
          │                       │
      Reasoning              Routing
      Planning               Scoring
      Writing                Filtering
      Coding                 Guardrails
      Analysis               Validation
          │                       │
          └───────────┬───────────┘
                      ▼
                  SOFTWARE

This is a shift from thinking about AI as one giant model to thinking about AI as a system of specialized models.

And that is potentially much more important than one new benchmark number.

What I'm watching next

The questions I find most interesting are:

How well does Jev calibrate on domain-specific datasets?
How does it perform against traditional classifiers and smaller specialized models?
How much latency can be removed from real production agent workflows?
Can decision models become a standard routing layer for multi-agent systems?
How should confidence thresholds be designed safely?
Can similar architectures run efficiently on-device?
Will future AI stacks combine reasoning models, generative models, and decision models as separate components?

The answers will determine whether System One becomes a niche optimization or a new standard abstraction for AI software.

Final thought

The AI industry has spent enormous effort teaching machines how to generate.

Jev raises a different question:

What if machines don't always need to generate an answer? What if they just need to make the right kind of decision?

That distinction sounds small.

Architecturally, it could be enormous.

Generation is one primitive.
Reasoning is another.
Decision-making may be another.

The future of AI engineering may not be about finding one model that does everything.

It may be about building the right system around specialized models — and letting each model do the job it is actually optimized to do.

Resources

TypeSafe AI — Jev and System One
TypeSafe AI documentation
Jev architecture and benchmark documentation
Jev-related open-source implementations and experiments
Community benchmarks comparing Jev with traditional classifiers and LLM-based approaches

DEV Community: PubDev

Jev: What Happens When AI Stops Generating and Starts Deciding?