By submitting, you consent to our use of your data. Privacy Policy.
Categoría
Agentes de IA
Compartir artículo
Most of the conversation about AI agents assumes the model's job is to write: draft the reply, compose the summary, generate the plan. But if you watch a production agent run, most of its steps are not writing at all. They are decisions. Route this ticket. Classify this document. Is this input safe. Which tool do I call. Should this go to a human. We have been solving those with text-generation models, and then acting surprised when they hallucinate a tool that does not exist.
TypeSafe's new model, Jev, takes the opposite bet. It does not generate text. It returns a typed decision with a confidence score, and that single design choice makes it one of the more interesting things to happen to agent architecture this year.
What Jev actually is
Jev, from TypeSafe, entered early access in mid-September. Its founder, Diogo Almeida, came from OpenAI, and the framing is deliberate: TypeSafe calls Jev a "System One" model, the fast, intuitive counterpart to the slow, deliberate "System Two" reasoning that frontier LLMs are chasing.
Here is the mechanic. You hand Jev a piece of state, an email, a log line, a support ticket, a JSON blob, along with a list of typed questions. It returns typed answers: a choice from a set you supplied, a score on a rubric, or a yes or no, each carrying its own calibrated probability. It does not write a paragraph explaining itself. It returns the decision and how confident it is.
TypeSafe's claims for it are striking, and worth reading as launch claims until independently tested: 40 to 200 times faster than frontier LLMs on comparable tasks, roughly $0.042 per million input tokens with free output, and, critically, an inability to hallucinate or produce a type error. That last point is the one that matters most for agents, and it is worth being precise about what it means.
Why "cannot hallucinate" is a real claim here, not marketing
When a text model answers "which tool should I call," it can invent a tool that does not exist, because it is generating tokens and any token is fair game. Jev cannot do that, because it does not generate. It only ever returns one of the options you gave it, with a probability attached. If you ask it to pick from three tools, it returns one of those three, never a fourth it imagined.
That is a narrower and more honest claim than "never wrong." Jev can still pick the wrong option. What it cannot do is return something outside the set, or malformed, or off-schema. For an agent, that distinction is enormous, because the failure that quietly derails an unattended run is usually not a bad judgment call. It is a hallucinated tool name or a broken output format that nothing downstream can parse.
The agent failure this targets is the expensive one
This is where it stops being abstract for us. When we broke down how agent evaluations actually fail, the single most impactful failure pattern was tool selection errors: the agent picking the wrong tool, or a tool that was not real. It sits at the top of the list because it is the one that breaks a run silently and is hard to catch without reading the trace.
A typed decision model attacks exactly that failure. If the "which tool" step returns a guaranteed-valid choice with a confidence score, an entire class of production incidents disappears, and the step becomes something you can gate on confidence rather than hope about. The same applies to the other decision-shaped steps that dominate a real agent: triage, classification, record scoring, and screening inputs or outputs for jailbreak attempts.
Where Jev is most relevant to use
The honest answer is not "everywhere." Jev is built for the decision steps, not the generative ones, and knowing the difference is the whole point.
When our team put Jev through a range of test cases, a clean rule of thumb fell out. Reach for Jev when three things are true at once: you already know the set of possible answers, you make the same decision repeatedly, and you can act on a confidence score. Reach for an LLM when you need text generation, open-ended answers, or data extraction. If any of those three conditions for Jev is missing, it is probably the wrong tool for that step.
Agent step | Usually done with | Better as a typed decision |
|---|---|---|
Route or triage an incoming request | A frontier LLM prompt | Yes, a choice from your routing set + confidence |
Classify or tag a document | A frontier LLM prompt | Yes |
Score a record against a rubric | An LLM judge | Yes, a calibrated score |
Validate which tool to call | The agent's own generation | Yes, a guaranteed-valid choice |
Screen an input or output for jailbreak or policy | A second LLM pass | Yes, a fast yes/no with probability |
Extract a field from a document | An LLM prompt | Hybrid: an LLM extracts, Jev verifies the result |
Draft the customer reply | A frontier LLM | No, this is generation, keep the LLM |
Plan a multi-step task | A reasoning model | No, this is System Two work |
The pattern is clear. Anywhere the real task is "pick one of these" or "score this" or "is this true," a typed decision model is a better fit than a text model pressed into service. Anywhere the task is genuinely to write or to reason across many steps, you still want a frontier model.
The hybrid pattern that works for extraction
Extraction is the interesting edge case, because it is neither a pure decision nor pure generation. Pulling a total, a date, or a counterparty name out of a messy document is a job an LLM does well. Trusting that the LLM got it right is a decision, and that is where Jev fits.
The pattern our team landed on is to use both. Let the LLM extract the field, then hand the extracted value and its source to Jev to verify, as a typed yes/no with a confidence score. You get the LLM's flexibility on the messy input and a fast, non-hallucinating check on the output, which is exactly the kind of verification that is slow and unreliable when a second LLM does it. For high-volume document work, that split is the difference between an extraction step you can trust unattended and one that quietly ships wrong values.
Why this is the logical end of per-step model choice
We have written before that the right way to build an agent is to assign a model per step rather than standardise on one. Jev pushes that idea one step further. The question is no longer only which model, cheap or frontier, but which type of model: a generator, a reasoner, or a decider.
The economics make the case on their own. In our own workload analysis, the same enterprise agent ran 26 times cheaper on a cheap model than a frontier one, and most of that cost sat on high-volume, simple steps that never needed a frontier model. A typed decision model is the sharper version of that argument: those steps did not need a language model at all. Routing them to a decider is how you take down the cost debt and the reliability debt at the same time, because the step gets cheaper and stops being able to hallucinate in one move.
The caveats worth keeping
Jev is days into early access, and the headline numbers are TypeSafe's own. The speed and cost claims need independent testing on real workloads, and calibrated confidence is only useful if the calibration holds on your data, which is worth verifying before you gate anything important on it. It is also, by design, useless for generation: if you point it at a task that actually needs prose or open-ended reasoning, you are using the wrong tool. Treat it as a specialised layer, not a frontier replacement, and it is genuinely useful. Treat it as a general model and it will disappoint, because it was never trying to be one.
How Beam thinks about a decision layer
The reason this fits how we build is that Beam already treats an agent as a pipeline of steps, each routed to what fits it, with governance and audit around the whole thing. A typed decision model slots naturally into the decision steps of that pipeline: the routing, the scoring, the tool validation, the guardrail checks. The generative and reasoning steps stay on the models that are good at those. The value of a launch like Jev, for anyone running AI agents in production, is not that it replaces your model. It is that it finally gives the decision steps a tool shaped like the job.
Common questions about Jev by TypeSafe
What is Jev by TypeSafe?
Jev is a "System One" AI model from TypeSafe that returns typed decisions with calibrated probabilities instead of generating text. Given some state and a list of typed questions, it returns a choice from a set you defined, a rubric score, or a yes/no answer, each with a confidence value. TypeSafe reports it runs 40 to 200 times faster than frontier LLMs at very low cost.
How is Jev different from an LLM?
An LLM generates text token by token, which is powerful for writing and reasoning but means it can produce a hallucinated or off-schema answer. Jev does not generate; it selects from options you supply, so it cannot return something outside the set or malformed. It is built for decisions, not prose.
Can Jev really not hallucinate?
TypeSafe's claim is specific and defensible: because Jev only ever returns one of the typed options you provide, it cannot invent an option or produce a type error. It can still choose the wrong option, so it is not "never wrong," but it cannot hallucinate a tool that does not exist or break a downstream schema.
Where should you use Jev in an AI agent?
On the decision steps: routing and triage, classification, scoring records against a rubric, validating which tool to call, and screening inputs or outputs for jailbreaks. Keep frontier models for the steps that genuinely require writing or multi-step reasoning. It is a specialised decision layer, not a general-purpose model.
Can Jev extract data from documents?
Not on its own, because extraction is a generation task and an LLM does the pulling. The pattern our team found works is hybrid: let an LLM extract the field, then pass the result to Jev to verify it as a typed yes/no with confidence. You get the LLM's flexibility on messy input and a fast, non-hallucinating check on the output.
