The Model That Decides Instead of Writing
Notes on TypeSafe Jev, System One models, and why the bottleneck in agents was never intelligence
I've been annoyed at myself for two years.
Every agent pipeline I've built or read about does the same dumb thing: it takes a five-second judgment call — is this a refund request? — and routes it through a frontier model that bills four seconds of latency and real money to hand back a sentence I then have to parse. We all knew it was wrong. Everyone building agents knew. We did it anyway because that was the tool on the shelf.
The fix was sitting in plain sight the whole time. Classifiers are old. Probability outputs are old. Most of what an agent does is deciding, not writing. Nobody stopped to look because the entire field was sprinting to make the essay-writer smarter.
Then TypeSafe stopped, and shipped Jev.
What Jev actually is
Jev doesn't generate text. That's the whole thing. It takes state in, answers questions you define in advance, and returns calibrated probability out. Sub-second. A fraction of the cost.
The interface is:
state + typed questions → probability distributions / typed decisions → ordinary code
Compare that to a normal LLM call:
prompt → generate tokens sequentially → text or JSON → parse and validate → software
One of those has a parsing step and a failure mode where the model invents a field that doesn't exist. The other doesn't.
A useful shorthand from the TypeSafe docs:
Code calculates. Jev judges. Reasoning models reason and generate.
Jev is for the semantic equivalent of an if statement. Not arithmetic — understanding. Does this message indicate a safeguarding concern? Which team should own this ticket? How severe is this incident? Does this passage support this claim? Does this tool call look unsafe?
The mental model that made it click
TypeSafe's framing: imagine putting all the relevant information in front of a knowledgeable expert and asking one specific question.
If they could answer immediately — without research, without an explanation, without a plan, without a chain of dependent decisions, without creating new content — the task is probably Jev-shaped.
Complex judgments get decomposed into several narrow questions and recombined in code. That's the design principle. Fan out semantic questions, compose the answers in software.
The three primitives
Jev exposes three decision types, and they map cleanly onto what agents actually need.
Noul — is this true? Returns the probability of yes. Binary semantic conditions. Fraud signals, policy checks, prompt-injection attempts, whether a passage supports a cited claim.
Choice — which of these options? Returns the winning option plus a probability for every option plus a confidence value. Classification, routing, intent, document type, model selection. Up to 255 options, and you should always include an "other" or "none of the above."
Score — where does this sit on a scale? Returns a score, a distribution across levels, and confidence. Severity, relevance, quality, urgency. Between 2 and 10 levels, and the levels should be concrete situations rather than vague adjectives.
That last point is worth repeating. TypeSafe's docs specifically call out that defining levels as "low / medium / high" is less useful than defining them as "no operational impact / degraded service but workaround exists / service unavailable and no workaround exists." The model can only judge what you've described.
Probability and confidence as first-class outputs
This is the part that changes architecture.
A Choice question doesn't just return an answer. It returns the whole distribution:
billing 0.58
technical 0.37
account 0.05
The answer is billing. The distribution tells you technical is still plausible. That's a different kind of information than "the model said billing."
And critically: if confidence < 0.80: send_to_human becomes a line of code you can actually trust, because the probabilities are calibrated. TypeSafe trains with something they call RLCD — Reinforcement Learning for Calibrated Decisions — and the intended property is that predictions carrying higher probabilities prove correct more often than predictions carrying lower ones.
Which is not the same as being right. Calibration doesn't mean correctness. A high-confidence answer can still be wrong. But it means uncertainty is now a number you can act on instead of a vibe you have to guess at.
The "zero hallucinations" claim, carefully
TypeSafe describes Jev as unable to hallucinate, because output is constrained to predefined answer spaces. That's true and it needs unpacking.
If the available options are billing / housing / HR / IT / other, Jev cannot output "probably ask Sarah, she usually handles these." It must return one of the supplied alternatives and a distribution.
So it eliminates an entire class of LLM failure: inventing values outside the schema, producing malformed output, drifting off-format. The docs' own terminology distinguishes this from semantic error. Jev can still confidently classify something as housing when the right answer is safeguarding.
Schema hallucination: gone by design. Semantic judgment error: still possible, still has to be measured.
Never read "zero hallucinations" as "zero errors."
Where this fits with LLMs
The framing that's been circulating — and it's the right one — is that Jev doesn't replace the generative model. It surrounds it.
Before the LLM. Classify intent, estimate complexity, detect sensitive content, choose a retrieval collection, pick a tool family, decide whether a human needs to approve the next stage. This is where the money gets saved, because you're deciding what the expensive model sees and whether it needs to be called at all.
After the LLM. Verify bounded properties of what came out. Does the answer address the request? Does the cited evidence support the claim? Does the patch contain unrelated changes? Is clarification still needed?
Code owns the workflow throughout. Jev answers questions. Code applies thresholds, permissions, fallbacks, logging, and human review. A favorable Jev answer is evidence, not authority — it can't grant a capability the caller doesn't have.
There's a line in the field guide that I think is the sharpest version of this:
Do not ask one model to be the author, router, policy engine, judge, and auditor of its own work.
That's the anti-pattern everyone's been shipping.
What this actually kills
Everything I was too cheap or too impatient to put an LLM on:
- Model routing
- Tool-call risk gates
- Intent and domain triage
- Loop and stop decisions
- RAG reranking
- Guardrails and policy checks
- Escalation to a human
All of it becomes a function call. And not a marginally better one. TypeSafe's own numbers claim up to 200x faster and up to 400x cheaper than the frontier-model-as-classifier pattern. Those aren't optimization numbers. Those are delete the old architecture numbers.
Caveats, because they matter: this is early access, the numbers are the company's own, and Jev only picks from options you define. Hallucination risk doesn't disappear — it moves into your option space. That's a problem you can engineer around, but you have to actually engineer around it.
What I'm taking from this
1. The bottleneck was never the model.
It was the decision graph. For two years we've been using a text generator for decisions because text generation was the tool that existed. The moment a purpose-built decision primitive showed up, a huge fraction of agent architecture became obviously wrong.
2. Calibration is the unlock, not speed.
Fast classification has existed forever. Calibrated probability — where 0.8 means roughly 80% likely to be correct across many predictions — is what makes "route to human below this threshold" into real logic instead of a heuristic you argue about in code review.
3. The pattern generalizes.
Deterministic code for exact rules. Jev for bounded semantic judgments. LLMs for open-ended generation. Policy for side effects. The striking thing isn't that someone built this — it's that it took until 2026 for someone to build this properly. If something this obvious was sitting there unnoticed, what else are we walking past right now?
4. Schema-constrained output is a design choice you can make today.
Even if you're not using Jev, the lesson holds: if the answer space is known before the request arrives, defining it in advance removes failure modes for free.
The thing that has me excited isn't the latency numbers. It's the implication. If frontier-level judgment can be a 50ms function call, a lot of what we've been building for the last two years is going to look silly pretty soon.
I don't think this is a feature launch. I think it's the start of something.
What a time to be alive.
Sources: TypeSafe AI — Introducing System One Models and Jev, TypeSafe documentation, How to Use Jev with LLMs (2026 field guide), and Building a Harness with Jev. The two source URLs failed to fetch directly; the guide and knowledge resource were used instead.
If you're thinking about where a decision layer belongs in your own agent stack, I'd like to talk. Let's connect.