Jev: A Different Approach to AI Decision-Making

Anshul kumar — Thu, 24 Sep 2026 17:14:22 +0000

Jev: A Different Approach to AI Decision-Making

For the last few years, much of the AI ecosystem has focused on making language models better at generating and understanding language.

We built increasingly capable autoregressive models that generate text token by token. We added reasoning capabilities, tool calling, structured outputs, and increasingly large context windows.

That approach is extremely powerful.

But there is a problem when we use these models inside backend systems:

Sometimes the application doesn't need an answer in natural language. It just needs a decision.

For example:

Which model should handle this request?
Is this support ticket urgent?
Should this transaction be reviewed?
Does this prompt contain sensitive information?
Which workflow should execute next?
Should this agent action be allowed?

In these situations, generating a paragraph of reasoning and then parsing it into a boolean, score, or enum can be unnecessary overhead.

This is the problem TypeSafe AI's Jev is designed to address.

Jev is a System One model designed to make fast, structured decisions that software can consume directly.

TypeSafe describes Jev as a model that gives up general-purpose string generation in exchange for structured outputs, parallel sampling, and calibrated probabilities.

What is Jev?

Jev is TypeSafe AI's first public System One Model.

The name is inspired by the distinction between System 1 and System 2 thinking from Daniel Kahneman's Thinking, Fast and Slow.

The basic idea is simple:

LLMs generate strings. Jev generates decisions.

Instead of asking a model:

"Read this support ticket and tell me what department
should handle it, whether it is urgent, and how frustrated
the customer appears to be."

and expecting a generated JSON response, you define the decisions your application needs.

Conceptually:

             Application State
                    │
                    ▼
        ┌─────────────────────────┐
        │          Jev            │
        │                         │
        │  Evaluate typed         │
        │  questions in parallel  │
        └────────────┬────────────┘
                     │
                     ▼
          Structured Decisions
          ┌──────────────────────┐
          │ Choice               │
          │ Score                │
          │ Yes / No             │
          │ Probabilities        │
          │ Confidence           │
          └──────────────────────┘
                     │
                     ▼
             Application Logic

The important architectural difference is that Jev is optimized around structured decisions rather than arbitrary text generation.

TypeSafe describes its architecture as using a new model architecture, a parallel sampler, and a training approach called Reinforcement Learning for Calibrated Decisions (RLCD).

State + Questions

One of the most interesting concepts in Jev is its API model:

State + Questions → Typed Decisions

1. State

The state is the information the model needs to evaluate.

It could contain:

Customer messages
Logs
Support tickets
Agent traces
Transaction information
Application state
Other structured or unstructured context

2. Questions

You then define the decisions your application wants the model to make.

TypeSafe currently exposes three core primitives:

`Noul`

A yes/no question.

For example:

Does this request appear urgent?

The result includes a probability for the statement.

`Choice`

Select one option from a predefined set.

For example:

Which department should handle this ticket?

billing
technical_support
sales
general

The model returns a distribution across the available choices.

`Score`

Evaluate something on a defined scale.

For example:

How frustrated is the customer?

calm
slightly_annoyed
highly_frustrated

The result includes a score and probabilities across the levels.

These primitives are also used in TypeSafe's published workflow evaluations.

Why Typed Decisions Matter

Consider a traditional LLM workflow.

You might ask:

Classify this ticket and return JSON.

{
  "department": "...",
  "urgent": true,
  "priority": "..."
}

Your application then has to deal with:

Generated text
JSON parsing
Schema validation
Invalid values
Missing fields
Unexpected output
Confidence estimation

With a typed decision model, the possible output space is defined ahead of time.

For example:

department ∈ {
    billing,
    technical_support,
    sales,
    general
}

The model isn't being asked to invent the structure.

The structure is part of the application.

This creates a useful separation:

AI → semantic judgment

Code → policy + business logic + side effects

That distinction is important.

Type safety does not mean semantic correctness.

Jev can still make the wrong classification. What the typed interface gives you is a constrained output space that is easier for software to consume and reason about.

TypeSafe explicitly frames this as making AI more like a dependable software primitive, with confidence and probabilities available to the application.

The Performance Difference

Traditional autoregressive language models generate output sequentially.

Conceptually:

Token 1 → Token 2 → Token 3 → Token 4 → ...

For a task that ultimately needs:

"technical_support"

or:

true

generating a long textual response can be unnecessary.

Jev takes a different approach, using parallel sampling for its structured outputs. TypeSafe reports end-to-end response times of approximately 70–500 ms for Jev.

Its current website also highlights a workflow comparison showing 193.6× faster and 444.6× cheaper for the particular System One workflows used in that comparison. These are TypeSafe's own benchmark results, not a universal guarantee for every workload.

That's an important distinction.

The useful takeaway isn't:

"Jev is always 200× faster than every LLM."

It is:

For the kinds of structured decision workloads Jev targets, avoiding autoregressive text generation can dramatically reduce latency and cost.

Cost Model

TypeSafe currently lists Jev at:

$0.042 per million input tokens

and states that output tokens are free because Jev does not generate traditional output text.

This creates an interesting economics model for backend systems.

Imagine an application processing millions of events:

Event
  ↓
Should we process it?
  ↓
Which workflow?
  ↓
What priority?
  ↓
Should a human review it?

If each decision requires a full generative LLM call, the cost and latency can quickly become significant.

A specialized decision model can potentially sit in front of or alongside the larger model.

A Simple Mental Model

I think about the difference like this:

Traditional LLM

Input
  ↓
Reason
  ↓
Generate tokens
  ↓
Generate JSON/text
  ↓
Parse
  ↓
Validate
  ↓
Application logic

Versus:

Jev

Input State
  ↓
Typed Questions
  ↓
Decision + Probability + Confidence
  ↓
Application logic

The second model is particularly interesting when the application already knows what decisions it needs to make.

Where Could Jev Be Useful?

1. Intelligent LLM Routing

One interesting use case is deciding which LLM should handle a request.

For example:

Incoming prompt
       │
       ▼
      Jev
       │
   ┌───┴────┐
   │        │
Simple    Complex
   │        │
   ▼        ▼
Small LLM  Frontier LLM

Instead of sending every request to an expensive model, a decision layer could evaluate the request and select an appropriate model.

This is especially interesting in systems where model cost and latency matter.

2. Support Ticket Triage

Consider a support platform receiving thousands of tickets.

The application might need to determine:

Department?
Urgency?
Customer sentiment?
Human escalation required?

Those decisions can be represented as typed questions.

The surrounding application can then implement deterministic business rules:

if urgency_probability > 0.9:
    escalate_to_human()
elif department == "billing":
    route_to_billing()
else:
    continue_normal_flow()

The model provides the semantic judgment.

The application retains control of the actual workflow.

3. AI Guardrails

Another interesting area is using a fast decision model as a gate around an LLM or agent.

For example:

Agent
  │
  ▼
Tool request
  │
  ▼
Jev
  │
  ├── Safe → Execute
  │
  └── Risky → Human review

This pattern could be useful for decisions such as:

Is this tool call potentially dangerous?
Does the request contain sensitive information?
Does this agent output require review?
Does this action violate a policy?

The important architectural idea is that the decision model doesn't need to replace the agent.

It can act as a fast decision layer around the agent.

4. Real-Time Classification

Low latency also opens possibilities for high-throughput classification.

Examples include:

PII detection
Spam detection
Content moderation
Message routing
Event classification
Fraud signals
Log classification

The TypeSafe workflow examples currently include security incidents, agent trace observability, invoice processing, and customer service, which gives a good indication of the kinds of automation problems the company is targeting.

What Jev Does Not Replace

This is probably the most important point.

Jev is not a replacement for an LLM.

If you need:

Code generation
Long-form writing
Conversational responses
Open-ended reasoning
Creative generation
Natural-language explanations

you still need a generative model.

Jev targets a different part of the architecture.

A useful way to think about it is:

                 AI Application
                       │
          ┌────────────┴────────────┐
          │                         │
          ▼                         ▼
   Generative LLM              Jev
          │                         │
   Generate text              Make decisions
   Write code                 Classify
   Explain                    Score
   Reason                     Route
                              Verify
                              Gate

In other words:

LLMs can generate the content. Decision models can determine what should happen next.

That distinction could become increasingly important as AI moves deeper into backend automation.

System 1 vs. Generative LLM

	Generative LLM	Jev / System One
Primary purpose	Generate language	Make structured decisions
Output	Text / structured text	Typed decisions
Sampling	Autoregressive	Parallel
Best suited for	Chat, code, reasoning, generation	Classification, routing, scoring, verification
Uncertainty	Often requires explicit prompting	Probabilities and confidence are part of the output
Application integration	Parse and validate generated output	Consume typed decisions directly
Latency target	Seconds for many frontier workflows	~70–500 ms according to TypeSafe

The two approaches are complementary rather than mutually exclusive.

The Bigger Idea: AI as a Software Primitive

For me, the most interesting part of Jev isn't simply the latency number.

It's the interface.

We've traditionally treated AI as something that produces text:

Prompt → Text

Jev proposes a different abstraction:

State + Questions → Decisions

That is much closer to how backend systems are already designed.

Software is full of decisions:

if condition:
    do A
else:
    do B

The problem is that some conditions are difficult to express with deterministic rules.

For example:

if customer_is_genuinely_frustrated:
    escalate()

The difficulty isn't the if statement.

It's determining:

Is the customer genuinely frustrated?

That's where an AI decision model can potentially fit.

The application owns the workflow.

AI supplies the judgment.

Final Thoughts

Jev represents an interesting direction in AI engineering: not every AI problem needs a chatbot or a text-generating model.

Some problems are fundamentally about making small, repeated decisions inside software.

For those workloads, a model that produces:

Choice
Score
Probability
Confidence

may be a better abstraction than a model that generates paragraphs of text.

Jev is still relatively new and currently available in early access, so there is plenty to learn about where this approach works well, where it doesn't, and how it behaves in production workloads. TypeSafe itself is actively asking developers to experiment with the model and report where it succeeds or falls short.

But the underlying idea is worth watching:

What if the next evolution of AI isn't just better models that talk to humans, but models that make fast, structured decisions for software?

That is the interesting question Jev is exploring.

DEV Community: Anshul kumar

Jev: A Different Approach to AI Decision-Making