AI

What a decision model changes about agent safety

Editorial · Reveneau · September 24, 2026

What a decision model changes about agent safety

Put an agent in front of a customer and count the decisions it makes before the task ends. A support agent that reads the ticket, looks up the account, drafts a reply and files a note makes a decision at each of those steps, and each step is a place it can go wrong. The usual way to check a step is to ask a second language model whether it is safe. In LangChain's test of agent graders this month, a language model judge took 2.16 to 2.83 seconds per decision. Thirty decisions in one task adds a minute or more of waiting, and the bill for the checking can pass the bill for the work. So most teams check the first message and the last one, and hope about the middle.

What's changed is the cost of one check. TypeSafe released Jev on 15 September 2026 as a "System One model": you send it text plus a set of named questions, and it returns a typed answer and a probability for each question. It produces no prose. TypeSafe states 70 to 500 milliseconds end to end, at $0.042 per million input tokens with output tokens free. At that list price, a check on 2,000 tokens of context costs $0.000084 (our arithmetic from TypeSafe's published price). We now use Jev to grade our own eval suite, and we have started putting it in front of agents. Here is what a check at that price changes, in three parts, and the one thing it does not change.

1. The safety check moves from the first message to every turn

When a check costs a language-model call, it runs once, on the opening message. When it costs a fraction of a cent, it can run on every message in and every reply out, and the shape of the guardrail changes with it.

TypeSafe's own guardrail cookbook shows the shape. One request carries a set of yes-or-no questions about the message (jailbreak, harmful request, medical advice, self-harm) plus a severity score from 0 to 3, and the cookbook runs it on both the input and the output, because an ordinary-looking prompt can still lead to a harmful reply. Each probability is compared against two thresholds: at or above the action threshold the hazard triggers its configured action, at or above the lower review threshold the message goes to a person. The two example policies both review at 0.35 and act at 0.70 (strict) or 0.85 (permissive), with a precedence order of support, block, review, pass when several hazards fire at once.

The cookbook makes one more point that matters for anyone who has written safety rules into the instructions given to the model before the conversation. Those rules sit in the same place an attack talks to. A check that runs outside the conversation reads the attack as data: in the cookbook's words, "Ignore your instructions" scores as a jailbreak instead of working as one.

Openlayer's jevals, an early release under the MIT licence from 20 September 2026, packages the same idea for agents: its security checks (prompt injection, jailbreak, personal data, health data, exposed secrets) run as one Jev request per record of what the agent did. On Openlayer's own benchmark, the median response was 244 milliseconds and the slowest 5 percent finished within 371 milliseconds. That is Openlayer's table on Openlayer's workload. The point for you is the order of magnitude: a check that finishes in a quarter of a second can sit on every turn without the user noticing.

2. Every side effect gets its own yes-or-no question

A side effect is any step that changes something outside the conversation: an email sent, a record written, money moved. With a cheap check, each side effect can get its own question before it runs.

TypeSafe calls that question a Noul: a yes-or-no statement that returns one probability from 0 to 1. Every question in a request is evaluated in parallel, so one request before a tool call can ask three or four things at once: does this call stay inside what the user asked for, does the target belong to this user, is the amount consistent with the ticket. TypeSafe's design guidance is to keep control flow, deterministic rules and side effects in code. The model answers the question. Code reads the probability and decides whether the tool runs.

LangChain has built exactly this into its agent tooling. The langchain-typesafe package ships a piece of code that sits between the agent and its tools and blocks a risky tool call before it executes, alongside a classifier used to route requests between models. The agent still plans and still writes. The gate decides, per call, whether the plan is allowed to take that action outside the conversation.

Browser-use went one step further and made the decision the whole step. Its Jev Ultrafast experiment from 16 September 2026 is a browser agent in which one Jev request picks the action and its target, reading a structured table of page elements instead of screenshots. Across six alternating runs of one Google Flights task, three per setup, the median time fell from 9.45 seconds to 7.09 seconds and the number of browser protocol calls fell from 1,092 to 101. Browser-use says this is repeats of one task, and we repeat that caveat: it shows what a decision per action looks like, and it is one task.

What this changes for you is the unit of trust. Instead of trusting the agent with a task, you trust it with one action at a time, each behind a question written for that action, and each still limited by a fixed list of the tools it may call.

3. The uncertain case goes to a person, at a number you chose

A probability is only useful if something happens at a threshold. The third change is that the uncertain case now has somewhere to go.

For its Choice and Score questions, Jev returns a confidence number from 0 to 1, computed from how spread out the probabilities are. TypeSafe's guidance is direct: at 0.9 and above, act automatically; below 0.5, route to a person, ask for clarification, or fall back to another system; in between, proceed with caution. The same page adds that "different actions within the same system should be gated at different levels depending on the consequences." A $20 refund and an account closure should not share a threshold.

The person is the important part. When a case lands in the review band, a reviewer decides, and that decision is a label. Keep it. The labels are the only evidence you will ever have about whether 0.35 and 0.70 were the right numbers for your traffic, and they are what you re-check the gate against later. We write about how we keep those labels in Jev in production.

LangChain's grader test shows both why a cheap gate is attractive and why the labels matter. On five weather-agent cases with 100 repetitions each, judged against a human label, Jev agreed with the label on 100 percent of its 500 decisions, GPT-5.6 Terra on 99.8 percent, and Claude Sonnet 4.6 on 80.0 percent, and Jev's per-case variance on the quality score was 0.0000149, which the authors report as 92 to 913 times lower than the language models. The full run cost $0.34 with Jev and $28.17 with Claude Sonnet 4.6. The same authors call the result "promising, but early" and "observational, not evidence", say the experiment cannot tell them why Jev's scores varied less, and warn that "low cost can amplify mistakes". Five cases is a small set. A gate that is wrong about one kind of case is wrong on every turn that case appears, at the same speed it is right.

4. What does not change: the check reads text, and text can be written to move it

TypeSafe published a weaknesses page for jev-1.13 alongside the launch, and it is the most useful page in the documentation for anyone building a guardrail. Three lines from it set the limits of everything above.

First: "State is data, and jev-1.13 does not treat it as hostile by default." Content written to steer the model, whether an injected instruction, a misleading framing, or text that argues for its own classification, "can move the answer". An agent that reads web pages and documents will put that text into the state, and the gate reads the same state. Second: accuracy falls as the state grows with content unrelated to the decision. A gate fed the whole conversation is a weaker gate than one fed the one tool call and the one sentence of the request it should match. Third: the model answers the question you wrote, and reads scoping words and negations exactly as written, so a question written loosely is a check that misses cases.

There is also the phrase TypeSafe uses in its marketing, that Jev "can't hallucinate". In TypeSafe's wording that means the answer always matches the shape you asked for, with 0 percent structured output errors. The answer can still be wrong.

So the gate is one layer of three. The first layer is a fixed list of the tools the agent may call at all, enforced in code, which no text can extend. The second is the set of checks that never read text: the account ID on the call equals the account ID on the session, the refund amount is at or below the order total, the recipient is in the customer's own record. The third is the decision model, asked narrow questions about a small state, for the judgment calls the first two layers cannot make. Our guide on taking agents from prototype to production covers the first two layers in detail; the change this month is that the third layer became cheap enough to run everywhere.

Thanks to the teams at TypeSafe, LangChain, Openlayer and Browser-use for publishing their numbers with their caveats attached, which is the only way numbers about a week-old model are worth reading. Our own summaries of the Openlayer and Browser-use releases are in AI News.

A safety check protects only the turns it runs on.

Sources

Common questions

Why can a decision model run a safety check on every turn when a language model cannot?

The cost of one check decides where it runs. In LangChain's September 2026 test of agent graders, a language model judge took 2.16 to 2.83 seconds per decision, while Jev took 0.44 seconds at $0.00035 per call. A check that adds two seconds and a visible cost runs once at the start of a task; a check that adds under half a second can run before every message and every tool call.

What should the guardrail check on an agent's output, and why both directions?

TypeSafe's guardrail cookbook runs the same set of questions on the message going in and on the reply coming out, because an ordinary-looking prompt can still lead to a harmful reply. The output questions cover the same hazards as the input ones (harmful content, medical advice, self-harm) plus a severity score from 0 to 3, so a reply gets blocked on what it says, whichever prompt produced it.

What is a Noul and how do you use one before a side effect?

A Noul is a yes-or-no question the model answers with one probability from 0 to 1. Before an agent takes an action that changes something outside the conversation, such as sending an email or changing a record, you ask one Noul per condition the action must meet: does this call stay inside what the user asked, does the target belong to this user. Code reads the probabilities and decides whether the action runs.

How do you set the threshold for a guardrail?

Set it per action, by the harm of being wrong. TypeSafe's own guidance is to act automatically at a confidence of 0.9 and above, send anything below 0.5 to a person, and gate different actions in the same system at different levels. Its guardrail cookbook uses a review threshold of 0.35 and an action threshold of 0.70 or 0.85 depending on how strict the policy is. Start strict, and loosen an action only after the labels from the review band show the model agreeing with your reviewers.

What happens to the cases the model is unsure about?

They go to a person, and the person's decision is kept. The confidence number tells you how spread out the probabilities were, so a low number means the model could not separate the options. Routing those cases to a reviewer keeps the agent safe today, and the reviewer's labels are the only way to find out later whether the threshold was set in the right place.

Can a decision model be tricked by text inside a document the agent reads?

Yes. TypeSafe's own weaknesses page for jev-1.13 says that content written to steer the model, whether an injected instruction or text that argues for its own classification, can move the answer, and that accuracy falls as the input grows with unrelated content. So the gate is one layer. Keep a fixed list of allowed tools and code checks that never read the text beside it.

Does "cannot hallucinate" mean the check is always right?

In TypeSafe's wording it means the answer always matches the shape you asked for: a yes-or-no question returns a probability and a choice returns one of your options, with 0% structured output errors. The answer can still be wrong. You still need a labelled set to measure how often it is wrong on your own traffic before you trust it with an action.

What checks should stay in code rather than go to the model?

Anything with a deterministic answer. Whether the account ID on the tool call matches the account ID on the session, whether a refund amount is at or below the order total, whether a tool is on the allowed list: these are comparisons code does exactly and the model does unreliably. TypeSafe's own design guidance says to keep control flow, deterministic rules, and side effects in code. Send the model only the judgment calls.

Is a decision model a replacement for the language model running the agent?

Jev returns a typed answer per question and produces no text, so it cannot plan a task, write a reply, or call a tool on its own. TypeSafe's own documentation says it is not a drop-in replacement for the model running a coding agent and is used inside the application for routing, scoring and checking statements. Browser-use's experiment, where a Jev request picks the next browser action, is the exception, and Browser-use says it is repeats of one task rather than a benchmark.

How much does the gate slow the agent down?

TypeSafe states 70 to 500 milliseconds end to end, and every question in a request is answered in parallel, so in TypeSafe's words adding questions barely changes the response time. On Openlayer's own benchmark of its jevals library, the median was 244 milliseconds and the slowest 5 percent finished within 371 milliseconds. Those are vendor and third-party figures on their own workloads; measure your own before you promise a response time to a customer.

What does a cheap check make worse?

It runs its mistakes at the same speed as its right answers. LangChain's authors warn that low cost can amplify mistakes, because a gate that is wrong about one kind of case is wrong on every turn that case appears. That is why the review band and the human labels matter more with a cheap gate, and why every threshold should be checked against the reviewers' labels on a schedule.