The failure mode that survives removing text generation
Jev is the decision model TypeSafe AI released on 15 September 2026. It returns typed decisions instead of text, so it cannot hallucinate a string, but it can still be confidently wrong. Production agents are already failing in ways that do not look like hallucinations. Roughly 39% of AI customer-service deployments were pulled back or reworked because the system did something wrong with enough confidence that software acted on it before a human noticed. The text was fine. The decision was not.
That is the problem Jev sharpens rather than solves. When a model cannot generate free text, it cannot hallucinate a product number, fabricate a legal citation, or invent a customer name. That failure mode goes away. What remains is a model that returns a probability-weighted decision from a fixed output schema, and an agent that treats that decision as ground truth and acts on it. If the decision is confidently wrong, the downstream effect is identical to the hallucination case: wrong action, no human check, cost incurred.
Before placing Jev in a production agent, that is the dynamic worth understanding.
What Jev is
TypeSafe AI released Jev on 15 September 2026. The company was founded by Diogo Almeida, a former OpenAI researcher. Jev is what TypeSafe calls a System One model: it takes application state and typed questions as input, runs a single parallel pass, and returns typed, calibrated probabilistic outputs. It does not generate text at any point in that process.
The architecture is deliberately narrow. You give Jev structured state (a user session object, a support ticket, a transaction record) and a question expressed in a typed schema (which of these five intent categories, how urgent on a scale of one to ten, which tool to invoke). Jev returns a typed answer with a calibrated confidence score. That is the complete interface.
TypeSafe trained Jev with a method they call RLCD, Reinforcement Learning from Calibrated Decisions. The effect, as they describe it, is that Jev's confidence scores track actual accuracy rather than drifting toward overconfidence as output length increases. Because there is no sequence of tokens to generate, there is no compounding probability error across a long response.
The performance claims are large: 40 to 200 times faster than frontier LLMs depending on task and infrastructure, and near-zero cost per call. TypeSafe has not published independent benchmarks at time of writing, so both figures should be read as vendor claims rather than verified results.
Where agents will use it
Jev fits four categories of agent work where speed and cost matter more than open-ended reasoning: routing, classification, triage, and tool selection.
For a customer support agent, a Jev call might classify an inbound ticket into one of twelve categories and assign an urgency score before the agent decides which tool to invoke. For a multi-agent orchestrator, it might route a task to the right subagent without the orchestrator spending LLM tokens on a reasoning step that has a deterministic enough answer. For a RAG retrieval agent, it might score query intent to decide which index to search.
The Stanford AI Index from June 2026 recorded real-world agent task success at 77.3%, which means roughly one in four tasks still fails in production conditions. Many of those failures happen at routing and classification steps where the agent sends work to the wrong tool or the wrong subagent. A model that is faster, cheaper, and calibrated for exactly those decisions has a reasonable case to make.
The practical integration pattern is: Jev handles structured decisions, a frontier LLM handles open-ended generation, and the agent composes both. That means your evaluation problem doubles. You are now running two model types with two failure modes in one pipeline, and the gap between offline evaluation and production behaviour applies to both.
The failure mode that does not go away
LLM hallucination rates range from 15% to 52% across modern models, with 69% to 88% on specialised legal queries, depending on domain. Jev cannot produce those failures. It cannot add a clause to a contract that was not in its schema.
What it can do is return a wrong classification with 94% stated confidence, and your agent will proceed accordingly. Calibration reduces this risk but does not eliminate it. A calibrated model is wrong about as often as its confidence implies, which still means it is wrong sometimes, and software does not pause to notice.
The Pandora deployment of an AI concierge handled dramatic inquiry surges during peak shopping seasons without degrading personalisation. That is a routing and classification problem at volume. If the classification layer misfires at 4 AM during peak load with no human watching, the agent routes customers to the wrong flow at scale before anyone reviews the logs.
Pentagon Federal Credit Union projected a 30% reduction in operational expenses from agent-based IT automation. Savings of that size require the agent to be making correct routing decisions consistently, not just most of the time. A confident wrong decision on an IT request does not appear on a cost dashboard immediately. It appears later, as remediation work.
The problem is not Jev specifically. It is that any component making decisions at speed, at low cost, in high volume, with calibrated confidence will be trusted by the software around it. Detecting quality decay after it has started requires measurement infrastructure that treats every Jev-influenced run as a data point worth scoring.
What evaluating a Jev-based agent actually means
Evaluation for a classification or routing component means measuring whether its decisions, not its outputs, were correct in context. That requires knowing the outcome downstream of the decision.
If Jev classifies a ticket as low urgency, and the ticket turns out to be a billing error affecting fifty accounts, the confidence score was well-calibrated to the wrong label. You find that by tracing multi-step failures back to the step that caused them, which requires a trace with enough span detail to see what Jev returned and what the agent did with it.
Prefactor records spans at each step and scores them against an expected activity schema. For a Jev integration, that means defining the schema for what a correct routing decision looks like given the inputs, then validating each run against it. The score is not on the text output (there is none) but on whether the decision was within the expected range for the input state.
Validating agent behaviour against a defined activity schema before deployment is different from evaluating quality in production, and both matter when a new decision-making component enters the pipeline. Jev changes the component, not the obligation.
You also need to track how Jev's decisions interact with the cost structure of the wider workflow. Near-zero cost per Jev call does not mean the total workflow cost drops by the same proportion if Jev misroutes work to a more expensive downstream step.
The six articles in this series
This hub article is the first of seven pieces published this week. The remaining six cover:
- Can Jev's typed outputs still be wrong? Type safety vs correctness
- Does Jev model routing need evaluation? The unmeasured failure
- Did swapping an LLM step for Jev make your agent worse?
- Is Jev's confidence score trustworthy? RLCD calibration explained
- Do decision models like Jev need evals? Why silent steps matter
- What Vercel and Bryo AI's Jev results show, and what they do not
Each piece is self-contained but builds on the framing here.
Where to start
If you are adding Jev to a production agent, define what a correct decision looks like for each call site before you deploy. Then instrument the pipeline so that each Jev span is recorded with its input state, its output, and its downstream outcome. Start evaluating your agents to build that baseline from the first run, and see the docs for how to configure span recording and schema validation for non-generative model components.