Most of what an agent does all day is not writing. It is deciding. Which category does this message belong to. Is it inside the business's scope. Which of these forty tools is worth offering the model on this turn.
Every one of those has traditionally been answered by the same machine that writes the replies: compose a prompt, call a chat model, parse the word that comes back, and hope it is one of the words you offered. It works, mostly. It is also slow for what it is, it occasionally returns something that is not a category at all, and the only sense of how sure it was is whatever it chose to say.
In September 2026 TypeSafe AI released Jev, the first of what it calls System One models. It does not generate text. You give it a state and a typed question; it answers with the value, a probability for every option, and a confidence derived from that distribution. The vendor publishes an input price of USD 0.042 per million tokens, does not bill output, and quotes end-to-end responses of 70 to 500 milliseconds.
A model like that is only as useful as what the platform around it does with its answers. This piece explains how AI Agent Builder treats a decision differently from a generation: where the decision model sits, what happens on the day it is unavailable, what each kind of step does with an answer it is not sure of, and what every run keeps.
What Jev answers, and what it does not
Three question shapes cover everything Jev does:
- Yes or no, with a probability.
- A choice among up to 255 named options, each with its own criterion.
- A score on an ordered scale of levels.
Every question in a request is evaluated together, in one round trip — six yes-or-no questions cost about the same wait as one.
Two properties make it better at routing than a chat model:
It cannot answer with an option you did not offer. There is no string to parse and no near-miss spelling to handle. The value that comes back is one of yours, or the call failed.
The uncertainty is a number you can act on. When a message could reasonably be two things, you do not get a confident guess. You get 0.48 against 0.28 and a low confidence — and the platform can treat that as the signal it is.
The vendor is equally specific about the limits, and they are worth taking at face value: it does not count, do arithmetic, compare dates, extract values or point at character positions, and it reads content literally, so text written to steer the answer can move it. That is why it is never the only line of defence on anything adversarial, and why PII detection stays with tools that return positions.
A decision is its own kind of model
The first design choice is where the decision model lives. AI Agent Builder gives it its own slot in the workspace's model defaults, next to the slots that already exist for embeddings, speech and image generation, and next to the three chat levels — Low, Normal and High — that say how much model a step deserves.
That separation does three things.
A step asks for "the decision model", never for a vendor. The classifier does not know it is talking to Jev. If a second System One model ships next year, or the same one is served through a gateway, the workspace changes one setting and every step follows. The platform tells the two kinds of model apart by what the model can do, not by who sells it.
A step that writes cannot pick it. Only the steps whose whole output is a decision accept the Decision level: a classifier, a business-scope check, a tool router's shortlist. An AI task or a reply never sees it as an option, because a model that cannot write would be the wrong choice there by construction — and the mistake is ruled out where the step is defined, not left to whoever configures it.
It is one setting for every agent underneath. The slot belongs to the workspace, so changing the model once moves every classifier in every agent. If you operate agents for clients, their workspaces inherit the connection from yours without ever being able to read the key, and a client who needs their own quota brings their own.
And when the slot is empty, nothing changes. A step asked to decide with no decision model configured does exactly what it did before the slot existed: a chat model, a prompt, a parsed answer. That is how the capability shipped without altering a single existing agent.
The fallback is one you named
A decision model sits in front of every turn, which makes its outage everybody's outage. So the slot takes a chain, not a single model: a primary and the candidates behind it, in the order you list them.
The chain is allowed to leave the family. A fallback can be an ordinary chat model — a small, inexpensive one is the sensible choice — answering the same typed question through structured output. A chain whose fallbacks could only be other System One models would put a single vendor's status page between you and every classifier you run.
| Situation | What the step does |
|---|---|
| No decision model configured | Exactly what it did before: a chat model, a prompt, a parsed answer |
| The primary fails | The next candidate you listed answers |
| Every candidate fails | The step's own failure path decides |
Nothing outside the chain you configured is ever tried. A model you did not choose is never substituted quietly on the day your primary is down — the same rule that governs the failover for every other model in the platform.
Every attempt goes through the same wrapper as chat traffic, so a failing decision connection counts against its health like any other. After enough failures its circuit opens, and on the next turn the chain starts from the candidate that is still answering instead of waiting on the one that is not.
The fallback is a fallback, not a peer, and the difference is the confidence. A System One model computes it from the shape of a distribution. A chat model is asked how sure it is and answers in the same breath as the decision. The two numbers look identical in a report and mean different things — which is why every answer records which kind produced it.
What each step does when the model is unsure
A confidence is worth nothing if the caller ignores it. Each of the three steps that use the decision model asks a different shape of question, and each has its own rule for the uncertain answer — chosen for what a wrong answer costs in that place.
| Step | What it asks | When the model is unsure |
|---|---|---|
| Classifier | One choice among your categories | Below 0.5, the default branch |
| Business-scope check | One yes or no: is this in scope? | Leans in scope; blocks only on a clear no |
| Tool router | One yes or no per tool, all in one call | Low floor; on any failure, the whole catalogue |
Classifier: fail towards caution
Your categories become the options, and each category's examples become its criterion — the text the model decides against. A vague category is the single most common reason a classifier underperforms, which is why that text is worth writing as a definition rather than a label.
The classifier refuses to route on a guess. Below a confidence of 0.5 it takes the default branch, exactly as if the answer had been unreadable. That follows the vendor's own guidance — below one half, route to a person — and it means a classifier on Jev fails towards caution rather than towards a confident mistake.
When the whole chain fails, the step does not quietly retry the question against a chat model. That would answer with a decision nobody configured and hide a broken integration behind a working conversation. The failure lands on the same unmatched path, and the run carries the error message, so whoever reads it does not need server logs to know what happened.
Business-scope check: the benefit of the doubt goes to the user
The scope check becomes a single yes-or-no question. The business description and the allowed examples define "yes", the blocked examples define "no", and the user's message travels as its own field, not pasted into the instructions — data the model reads, rather than text indistinguishable from the question itself.
The costs of its two mistakes are not symmetric. Wrongly blocking a customer is worse than letting one off-topic question through to a model that will decline it anyway. So a message passes unless the probability of "in scope" falls below 0.35, and below 0.15 the violation is reported at high severity. If the check itself fails, the guardrail's configured posture for a failed check decides whether the door opens or closes; the failure is never swallowed.
It sits next to the deterministic checks, never instead of them. A message written to talk the check into a "yes" can move it; the scope check narrows what reaches the agent, it is not the thing standing between an attacker and your data.
Tool router: a shortlist, not a decision
A router with dozens of tools should not offer all of them to the model on every turn. Before the agent loop starts, the decision model gets one yes-or-no question per tool — would this tool help answer this message? — with each tool's own description as the criterion, and answers all of them in a single call.
The router keeps the tools above a floor of 0.15, up to the node's limit, plus the tools the operator pinned. The floor is low on purpose: this is a candidate list, not a decision to call anything. The agent still chooses, and leaving out the tool the user needed costs the whole turn, while including a marginal one costs a few tokens.
So every failure leans the same way. Above a hundred tools, one question per tool stops being the cheap call it is meant to be, and the router offers the catalogue whole. If the shortlist cannot be built, it offers the catalogue whole. Without a decision model configured, the same questions go to the node's own chat model under the same contract — with a confidence that is claimed rather than computed.
Where a chat selector says "these two", this one tells you how close the third one was.
What the run keeps
Every decision is recorded on the step that made it: the model that served it, which rung of the chain answered and through which connection, its latency and tokens, the confidence, the probability of every option, and whether it fell below the floor. A decision is metered like any model call, because a decision that is not metered is one nobody is billed for and nobody can budget.
That record is how you tune. A category that keeps appearing as the runner-up at 0.4 is overlapping with another one, and the fix is a sharper sentence in its criterion, not a bigger model. A run served by the fallback is visible as such, instead of looking like a strangely shaped answer from the primary.
What it changes in cost
A decision is priced on input alone. At the vendor's published rate, a decision whose state and question come to 2,000 tokens costs about USD 0.000084, and a hundred thousand of them about eight dollars and forty cents.
The comparison worth making is not the vendor's headline. Its launch figures — two orders of magnitude faster and cheaper — are measured against frontier models. Nobody routes with a frontier model. Against a small chat model at USD 0.20 per million input tokens and USD 1.20 per million output (OpenAI's published rate for GPT-5.6 Luna, its model for high-volume work, on 28 September 2026), the same decision costs roughly five times more, and typically takes over a second instead of a fraction of one.
Five times is still the difference between a line item and a rounding error. But it is five, not four hundred, and it is worth knowing which number you are budgeting against. The bigger win is often latency: a classifier and a scope check sitting in front of every turn are wait the user feels.
Where it stops
- Three steps use it today: the classifier, the business-scope check and the tool router's shortlist. Anything that has to produce text stays on a chat model, by design.
- The full distribution is not on the run screen yet. The run view shows the model, latency, tokens and the chosen option; the per-option probabilities and the confidence are in the run record and read through the platform's run-audit tools.
- Above a hundred tools there is no shortlist; the router offers everything, as it did before.
- The scope check is not a security boundary. It reads content literally, and content can be written to move it.
- A fallback's confidence is not the primary's. It is recorded as coming from a chat model, and it should be read that way.
Six invariants to check on any system
Whatever routes your agents' decisions — this platform or another — these are the properties worth demanding, and each one can be tested in an afternoon.
- The answer is always one of the options offered, or the call failed. Feed it a message that fits none of them and see what comes back.
- Nothing outside the configured chain ever answers. Take the primary down and check which model served the next decision. With nothing configured, behaviour should be exactly what it was.
- Every uncertain answer has a named destination, per step. For each classifier, say where a message at 0.4 confidence ends up. If the answer is "somewhere it is quietly lost", that is the bug.
- A failed chain reaches the step's failure path. It is not retried on a model nobody chose, and it is not swallowed into a default that looks like an answer.
- Every decision records which model and which rung answered, and its confidence is labelled with the kind of model that produced it.
- The user's text travels as data, in its own field. Read the request a decision actually sends and check the message is not pasted into the instructions.
