Let the LLM Write, Let Jev Decide: Splitting Decisions from Generation in Agent Loops

If you look at the trace of a production agent and count the calls, you notice something odd. Most of the expensive LLM round-trips don't produce anything a human will read. They produce decisions: which tool comes next, which queue a ticket goes to, whether a draft is good enough to send, whether to stop the loop. In each of these calls we take the context, wrap it in a prompt that asks for JSON, wait while the model writes it token by token, parse it, validate it, retry if it comes back malformed, and in the end we get something like true.

So here is the question: does it make sense to call a full LLM, have it generate text, and then turn that text back into data, just to reach a yes or a no? TypeSafe AI's answer is that it often doesn't. I've spent the last few years building agent harnesses, first as an AI Tech Lead for agentic development at CI&T and now at AIDM. I agree, and I want to explain what this means for how we design agent loops.

Two kinds of work hiding in one loop

Every agent loop mixes two very different kinds of work:

• Generation: writing the reply to the user, drafting the email, writing the SQL, filling in a tool call's arguments. The output is open-ended text, and an LLM is the right tool.
• Decision: picking from a closed set (which tool, which route, which team), scoring something on a scale (how urgent, how frustrated), or a yes/no gate (is this safe, is this done, should a human review it). The output is a value that code will branch on.

For two years we've been sending both kinds of work to the same model through the same interface, which is a string. That works well enough in a demo. In production it shows up as latency, cost, schema-validation code, and a quieter problem. When an LLM tells you it is "90% confident," that number usually isn't a measured confidence. The model wrote it as text like everything else.

The heuristic fits in one line, and I've already started using it in design reviews: if the output of a step is a value your code will branch on, consider a decision model. If the output is text a person will read, use an LLM.

What Jev actually is

Jev, released in early access on September 15, 2026, is TypeSafe AI's first "System One" model. The name comes from Daniel Kahneman's fast/slow thinking split. Jev doesn't generate text, code, or explanations. You send it a state (the context for the decision: a support ticket, account data, an error code) and a set of typed questions, and it returns typed answers with probabilities and, for some question types, confidence.

According to TypeSafe's documentation, there are three primitives:

• Choice: pick one option from a closed list you define ("which team should handle this ticket: billing, technical, or account?"). The model can only return one of the options you supplied.
• Score: a position on a scale you define ("how frustrated is this customer, 0 to 2?").
• Noul: a yes/no answer expressed as a probability ("is this ticket urgent?").

All the questions go in one call and are answered in parallel. The model reads the state once and answers everything together. Two things make that possible: an architecture with a parallel sampler instead of token-by-token generation, and a training method TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD). RLHF trains models to produce answers people prefer. RLCD trains the model to make a decision and report how sure it is in a way that matches how often it turns out to be right. TypeSafe's own docs add a caveat that matters: calibration is measured across groups of predictions. It doesn't guarantee that any single answer is correct.

"Zero schema errors" doesn't mean "never wrong"

There's a distinction here I think every architect should take on board. TypeSafe says Jev produces no type errors, and that holds by construction because the answer space is defined before the call. But a perfectly valid answer can still be semantically wrong. A model choosing technical when the right answer was billing hasn't hallucinated a schema. It has made a bad call.

So "it can't hallucinate" means something narrow. It can't invent a tool that doesn't exist or return a malformed object. It can still misjudge. What changes is that the misjudgment comes with a number you can act on.

Designing the split: a sketch

Here is how I'd structure one step of an agent loop that handles support tickets. This is illustrative pseudo-code, not the exact TypeSafe SDK:

# One step of the agent loop
state = {
    "subject": ticket.subject,
    "message": ticket.body,
    "account": account.summary(),
    "error_code": ticket.error_code,
}

decision = jev.ask(state, questions={
    "route": Choice(["billing", "technical", "account"]),
    "urgent": Noul("Does this ticket need same-day handling?"),
    "frustration": Score(0, 2, "How frustrated is the customer?"),
    "next_tool": Choice(["lookup_invoice", "fetch_logs", "reset_access", "none"]),
})

# Deterministic policy owns the branching, not the model
if decision.route.confidence < ROUTE_THRESHOLD:
    return escalate_to_human(ticket, decision)  # or to a reasoning LLM

tool = TOOLS[decision.next_tool.choice]
args = llm.generate_args(tool.schema, state)  # LLM writes the arguments
result = tool.run(args)

reply = llm.write_reply(state, result, tone_hint=decision.frustration.score)
return reply

There are three layers here, and each does one job:

• Jev decides: route, urgency, frustration, next tool. It runs in one parallel call and returns typed values with probabilities.
• Code governs: thresholds, escalation, and the mapping from decisions to actions all live in plain, testable, versioned code.
• The LLM writes: tool arguments and the customer-facing reply, the open-ended parts where language actually matters.

This is the same move we make in classic software architecture when we separate policy from mechanism. The decision model doesn't become "the agent." It becomes something like an intelligent if. Flavio Copes, quoted by The New Stack, called it "a smart if statement," and I can't improve on that.

Why this matters for the sectors we serve

At AIDM we build AI systems for healthcare, education, nonprofits, and associations. In all of them, "the model sounded sure" doesn't count as an audit trail. What matters to these clients:

• Confidence gates become explicit policy. "Auto-route above threshold X, send to a person below it" is a rule a compliance team can read, review, and change without touching a prompt.
• Decisions become measurable. When each decision is a typed value with a probability, you can log it, compare it against outcomes, and check calibration on your data instead of taking anyone's word for it.
• The LLM's job gets smaller and easier to check. If the LLM only writes, its failures are easier to spot and evaluate.

That's what we mean by our motto, foundation before innovation. The new model matters less than the boundary it lets you draw.

On the numbers: be a skeptic

TypeSafe makes big claims. Its launch post reports end-to-end responses of roughly 70–500 ms, speedups of 40–200x over frontier LLMs on "System One-shaped" queries, and input pricing of $0.042 per million tokens with free output. Its workflow evals report figures as high as 193.6x faster and 444.6x cheaper.

To TypeSafe's credit, the post says those figures are probably at the higher end of real-world gains. It also acknowledges the evals were built by its own team and scored against other frontier models' answers as the reference. All of these figures are vendor-reported. Runtime Wire noted the same thing: the headline gains are still vendor-tested.

Caution is warranted. Jev is promising but still very new, and it is only available in early access. There are hard limits too. Jev accepts text only, and the blog notes Choice questions support up to 255 options.

My advice is to benchmark on your own workflows. Take one decision your agent already makes with an LLM, such as routing or a stop condition, and run both paths in shadow mode. Compare accuracy, latency, cost, and especially calibration: when the model says 0.9, is it right about nine times out of ten?

The takeaway for teams building agents

You don't need to adopt Jev tomorrow to use the idea. Start with an audit:

1. 1.List every LLM call in your agent loop.
2. 2.Tag each one: does it produce text a human reads or a value code branches on?
3. 3.For the value-producing calls, define the answer space explicitly (a choice, a score, or a yes/no) and move the branching logic and thresholds into code.
4. 4.Then pick the engine. A System One model like Jev, a constrained LLM call, or even a classic classifier can all sit behind the same typed interface.

Let the LLM write. Let something built for decisions decide, and let your code own the policy. That separation is what makes an agent maintainable, auditable, and affordable, whichever model ends up behind it.

Sources & references

• TypeSafe AI, "Introducing System One Models & Jev" (Diogo Almeida, Sep 15, 2026): https://typesafe.ai/blog/introducing-system-one-models-and-jev (all benchmark figures cited here come from this vendor post)
• TypeSafe AI Docs, "System One": https://docs.typesafe.ai/concepts/system-one
• The New Stack, "TypeSafe launched Jev because sequential LLMs are 'totally useless for computers'" (Adrian Bridgwater, Sep 21, 2026): https://thenewstack.io/typesafe-jev-system-one/
• Runtime Wire, "TypeSafe opens Jev early access for fast, typed AI decisions" (Ryan Merket, Sep 15, 2026): https://runtimewire.com/article/typesafe-jev-system-one-ai-model-early-access

About AI Data Management

We are a forward deployment team: enterprise AI systems, built inside your business. We work alongside your leadership, learn how your operation actually runs, and build the systems your business runs on. Your data stays yours throughout.