Introducing Jev into agentic workflows

How do we introduce Jev into an agentic workflow? We put it in the agent's control plane as a judge, starting with a tool-call gate that logs its scores and blocks nothing. Jev is TypeSafe AI's first public System One model, which takes a state and typed questions and returns typed answers with calibrated probabilities. It does not generate text and it never runs a tool. After the shadow gate we add a soft gate, then a model router, then catalogue selection, then loop and completion supervisors. Through all five steps the generative model still drafts and plans, and application code still owns permissions, arithmetic and every side effect.

The problem Jev addresses is that most agent harnesses make their small decisions with the same frontier model that writes the plan. Should this tool call run without asking anyone, and is this turn hard enough to need the large model? Has the agent stopped making progress, or is it close to done? Each of those is a bounded judgment with a short list of possible answers.

A generative model answers these in free text that code then has to parse. No probability comes attached, so there is nothing to set a threshold against, and the same question can get a different answer on the next run. The check is also slow and costly enough that teams quietly stop running it on every step, which leaves the middle of a long task unchecked.

This guide covers what Jev is, where it sits in the loop, and its three question types. It then walks through our five-step sequence with one section per pattern, before setting out what stays in code and the failure modes we design against. Two other guides frame this one: How to roll out AI agent autonomy in five levels covers how an action earns authority, and How to scope AI agent permissions covers who may run it.

What is Jev, and why does an agent harness need one?

Jev is a decision model. It cannot write a sentence. TypeSafe announced it on 15 September 2026 as the first of a class they call System One models, after Kahneman's fast System 1.

The interface has two parts, a state and a set of questions about that state. The state can be free text or structured fields, and each question has a type. Jev returns one typed answer per question, with a probability for each option, so every output is bound to a schema you wrote.

That shape rules out a class of failure we spend a lot of time on elsewhere. A generative judge can return an option that does not exist, a paragraph where you asked for a label, or a confident answer with no measure of doubt. Jev can do none of those, because it has no free-form output to do them with. It can still be wrong. A wrong answer arrives with a probability you can threshold, log and compare against what happened.

TypeSafe reports latency of roughly 70 to 500 milliseconds per request and input pricing of about $0.042 per million tokens, with output not metered. LangChain's write-up on building a harness with Jev puts it at 40 to 200 times faster than frontier LLMs on System One-shaped tasks. We have not benchmarked those figures ourselves. The qualifier in the second claim matters most: the comparison holds for bounded judgments, and says nothing about planning or writing.

Speed matters here because it changes what a harness can afford to check on every step. When every judgment costs a frontier call, teams check at the start of a task and at the end, and nothing in between. A judge that answers in well under a second can look at every proposed tool call and every step of the loop. The table below sets Jev beside the two things it usually replaces.

Where does Jev sit in the agent loop?

Jev sits beside the loop, never inside the execution path. The generative model proposes, Jev judges, and code decides what happens, with a person taking the cases code routes to them. We draw the boundary this way on every build: Jev judges, code enforces, and the model generates.

This figure is a framework showing who owns each decision, and it does not describe the internals of any product.

The boundary matters most at the tool runner, where a judgment turns into an action. When Jev picks a tool with a Choice question, the winner is only an input to the tool runner. The runner still checks the caller's permission, the allowlist and the spend cap before anything executes.

If Jev could trigger a side effect directly, a wrong answer on unusual input would reach a production system with nothing between them. Keeping execution in code means the worst outcome of a bad Jev answer is a refused call or an unnecessary question to a person.

Code also assembles the state Jev reads, because Jev only judges what it is given. It does not look at a screenshot and work out what the agent was trying to do. Your code extracts the task, the proposed tool, its arguments, the user and the relevant history into named fields, and Jev judges that.

Incomplete state still gets a confident answer. Jev judges the fields it received and has no way to flag the ones that are missing. Our governed context layer guide covers how to give every agent the same business definitions, and those definitions are often most of the state Jev needs.

A low-confidence answer is a signal in its own right, and code should act on it. When the probabilities spread across options instead of concentrating on one, the right response is usually to route the case to a person. A system that picks the top option regardless has thrown away the one piece of information a generative judge could not give it.

What are Choice, Score and Noul?

Jev answers three types of question, and most of the design work is choosing the type and writing the options. The table sets them side by side, using the limits TypeSafe documents.

Of the three types, Choice has the limitation that catches teams most often. Asked which of forty tools fits a request, Choice returns one of the forty, even when the right answer is that no tool fits. We add a none-of-these option to every Choice, and for tool selection we pair it with a separate Noul that asks whether the request needs a tool at all. The Noul can say no, where the Choice never will.

Split any question that asks two things into two questions. A question such as "is this call safe and within the user's intent" gives one probability for a combination nobody can act on, because a low score does not say which half failed. Jev evaluates several questions in parallel in one request, so two questions cost no extra round trip. The split also gives two separate numbers to log, which you will need when calibrating thresholds later.

In what order does Bigcircle introduce Jev?

We introduce Jev in five steps, and each step gives Jev's answer more influence over what the agent does. The order matters more than any individual pattern, because each step produces the logs the next one is calibrated against. On a single agent we plan about a week per step, and a step starts when its predecessor has the logs to support it, whatever the calendar says.

This figure is an illustrative model of our rollout, and the step order is the one we use. The pacing varies with traffic and risk, and the figure reports no measured result.

The guardrail always goes first, for three reasons that reinforce each other. It is the smallest change to an existing agent, because it adds a check without removing anything. It is never the only thing standing between the agent and a bad action, because the allowlist and permission checks stay in place.

A shadow gate on every tool call also generates labelled traffic fast. Each logged score can be compared with what the agent did and with whether a person later reversed it.

Threshold governance runs underneath all five steps and never finishes. Every threshold is a named constant in code, reviewed like any other change. A sample of cases in the middle band goes to a person on a schedule, and a gate whose outcomes drift goes back one step.

That is the same demotion discipline our autonomy guide applies to agent actions. It applies here for the same reason, since a gate that stays promoted after its evidence has gone keeps auto-running calls that nobody would approve today.

How do you run the tool-call gate?

The tool-call gate asks, before each proposed call runs, whether it is safe to run without a person. It starts in shadow mode, so for the first step Jev scores every proposed call and the score goes to the log. Nothing else changes. The agent behaves exactly as it did before, which makes the shadow step safe to ship on a production agent.

The shadow step gives you a distribution of scores set against real outcomes. After enough traffic you can see where the scores for routine reads cluster and where the scores for reversed calls cluster. You can also see how much traffic falls between them, and those three facts set the first thresholds. Setting thresholds before seeing the distribution means choosing numbers from intuition, and the first sign of a bad choice would be a production incident.

The soft gate, the second step, turns those scores into outcomes. A call with a high probability of being safe and a low blast radius runs automatically. A call in the middle band goes to a person, and a call with a low probability is refused. The deterministic checks run first and stay in place, so a call outside the allowlist is refused without Jev being asked.

This figure is an illustrative model, and its thresholds of 0.40 and 0.90 and its blast-radius cutoff are examples chosen to show the shape. They are not defaults from TypeSafe or from any system we run, and your thresholds should come from your own shadow-step logs.

The gate itself is a few lines of code, and the thresholds belong in it as named constants. The client call below is schematic, because SDK names change faster than the policy does.

# Thresholds are reviewed like code. Change them in a PR, never at runtime.
AUTO_RUN_MIN = 0.90
REFUSE_BELOW = 0.40
MAX_AUTO_BLAST_RADIUS = 3
 
def gate(call, user, task):
    if not policy.allows(user, call.tool, call.args):
        return log_and_return("refuse", call, reason="policy")
 
    answers = jev.evaluate(
        state={"task": task.summary, "tool": call.tool, "args": call.args, "user_role": user.role},
        questions=[
            noul("safe_without_person", "Is this call safe to run without a person reviewing it?"),
            score("blast_radius", "How much damage could this call do if it is wrong?", levels=5),
        ],
    )
    p_safe = answers["safe_without_person"].p_yes
    radius = answers["blast_radius"].score
 
    if call.tool in IRREVERSIBLE or radius > MAX_AUTO_BLAST_RADIUS:
        outcome = "ask_person"
    elif p_safe >= AUTO_RUN_MIN:
        outcome = "run"
    elif p_safe < REFUSE_BELOW:
        outcome = "refuse"
    else:
        outcome = "ask_person"
    return log_and_return(outcome, call, answers=answers)

Look at where the sketch puts the proposed arguments, and where it puts the question. The arguments sit in a named field of the state, and the question text is fixed. Tool arguments, web pages and model output are all text an attacker can reach. Concatenated into the question, that text can rewrite what Jev is being asked, which is prompt injection aimed at the judge.

Several integrations already package this gate, so you may not need to write the call yourself. LangChain's harness post describes an auto-mode middleware that makes the run, ask or deny decision, and community MCP servers expose tools such as jev_guard_tool_call for clients that speak MCP. Whichever you use, the policy check before it and the thresholds after it are still yours to write.

How should Jev route between models?

Once the gate has run long enough for the team to trust its logs, we add a router. A Choice question over model tiers reads the task and the conversation so far and picks the tier that should handle the next turn. Easy turns go to a smaller model. Planning and hard reasoning stay on the frontier model. The generative model still writes every word the user reads, and Jev only decides which one writes it.

The failure to design against is a hard turn sent to a small model. The small model writes a plausible, wrong plan. Nothing in the output says that a routing decision caused the error. We make the frontier tier the default whenever the router's confidence is low, so an uncertain routing decision spends more on the frontier model and does not risk a wrong plan. Model routing earns its place only if the routed system matches the all-frontier system on the cases that matter.

We check that with a fixed set of real tasks, run once with routing and once with every turn on the frontier model, comparing outcomes and not only final answers. Our LLM evals guide covers how to build that set from real failures. LangChain's post describes a model-router middleware and community MCP servers expose jev_route_model, and both still need that comparison before routing goes live.

The same Choice pattern extends to task routing in multi-agent systems. Vercel's writing on Jev for agent control describes routing a task to proceed quickly, go to deep review, split into subtasks or block. That is a good fit for fan-out to specialist agents, where the wrong route wastes a whole subtask rather than one turn.

How does Jev pick from a large tool catalogue?

The fourth step moves tool selection out of the generative model's context. When an agent holds every tool definition on every turn, selection degrades as the catalogue grows. On Solarpunk, a product that works across more than a hundred tools, selection held until somewhere around thirty tools and then went quietly wrong. The model returned a confident result from the wrong tool, and it did not look like an error.

With Jev, code assembles a shortlist of candidate tools or playbooks and asks a Choice question over them, with a none-of-these option. In parallel it asks a Noul question: does this request need a tool at all? When the Noul says no, the agent answers directly without calling anything. When the Choice confidence is low or none-of-these wins, the agent asks the user or searches again, and it does not guess.

Jev picks the tool. It does not write the arguments. Arguments are free-form values, such as an ID, a date range or a message body, and Jev has no way to produce free-form values. Code or the generative model builds them against the selected tool's schema, and the gate from step two checks the finished call. Asking a decision model to fill arguments means encoding every possible value as an option, which breaks at the first unseen customer ID.

This step pairs with two of our guides on catalogue design. Agent playbooks as MCP tools covers how to shape a catalogue of workflows the agent can search. MCP tool design: fewer, larger tools covers keeping the catalogue small in the first place. Jev makes the selection step more predictable, and it cannot rescue two tools whose descriptions overlap.

How does Jev tell a stuck loop from finished work?

The fifth step adds supervisors to the agent loop itself. After each step, code sends Jev the recent history and three questions. A Noul asks whether the agent is looping, and a Score asks how much progress it has made on a defined rubric. A second Noul asks whether the task is complete against its exit evidence.

A loop that repeats the same tool call with small variations shows up in the first two answers long before a step limit would catch it. The step limit stays anyway. A supervisor that misreads an unusual loop keeps the agent running, and without a hard limit in code that loop runs until the budget or the user's patience runs out. Jev lets you stop a stuck agent earlier than the limit would, and the limit still guarantees it stops.

Agents fail most expensively at completion, because a false report of done ends the task with nobody watching. An agent that reports work as done when it is not has usually confused a successful API call with a finished task. Why AI agents report unfinished work as done covers the expected-state contract and the independent read that proves the final state.

Jev's completion Noul judges that evidence, which code gathers from the system of record. It never judges the agent's own claim that it finished, since that claim is the thing being checked.

What has to stay in code?

Everything that changes state or enforces a limit stays in code, however good Jev's answers become. A decision model with calibrated probabilities still gives a wrong answer some of the time. For some actions any rate of wrong answers is too high without a deterministic check, so on every build we keep these in code:

• permissions, checked against the user and task at execution time;
• allowlists of tools and argument ranges;
• spend caps and rate limits per user and per run;
• arithmetic, dates and any calculation with one right answer;
• step limits and timeouts on the loop;
• the thresholds themselves, as named constants;
• the assembly of the state Jev reads.

Log every Jev call with the full probability distribution, never only the winning option. Record the state fields sent, the questions and their versions, the thresholds in force and the outcome the code chose. When a person asks later why a call ran without review, the answer is then a probability of 0.93 against a threshold of 0.90 on a named version of the question.

Our guide on building an audit trail for AI decisions covers how to connect that record to the business case it belongs to. The log itself should sit in the same observability stack as the rest of the agent, so an incident review can follow one call through the proposal, the judgment and the outcome.

What goes wrong when teams adopt Jev?

The failures we design against come from treating Jev as more than a judge. Each one below has a plain fix, and most of the fixes are code.

The first row deserves a rule of its own, stated without exceptions. We do not let Jev be the only decider for an action that cannot be undone, at any confidence. A calibrated 0.99 is still wrong one time in a hundred. On a system that deletes accounts or sends payments at volume, one in a hundred is a steady run of customer incidents that nobody can reverse.

How does this map to autonomy levels and permissions?

Jev fits inside the release model we already use, and it changes none of the rules. Our autonomy guide releases each action class through five levels, from read to act inside a bounded policy. A shadow gate fits any level, because it only observes. A soft gate that auto-runs a class of calls moves that class to level five, so it needs level five's exit evidence: a written policy, a monitored error rate and a demotion trigger.

The permission model does not change. How to scope AI agent permissions sets out the Agent Action Boundary, where discovery, eligibility and permission are separate checks bound to a principal and a task. At most, Jev's answer is one input to the eligibility check. It can say a call looks routine, and it cannot grant a permission the caller does not hold.

We treat Jev the way we treat any other component that makes a judgment in production. It has named versions of its questions, thresholds reviewed like code, an eval set that measures it, and a log that lets a reviewer reconstruct any decision. We build these control planes for clients as part of our AI agent work.

Questions buyers ask

What is Jev?#

Jev is a decision model from TypeSafe AI, announced in September 2026 as their first public System One model. It takes a state and typed questions of three kinds, Choice, Score and Noul, and returns typed answers with calibrated probabilities. It does not generate text, so it cannot return an option outside the ones you defined.

Is Jev an LLM, and how is it different from an LLM judge?#

No. An LLM judge generates text that code then parses, and it attaches no probability to its answer. Jev returns one option per question from a schema you wrote, with a probability for each option. That gives code a number to threshold and log, and it removes the class of failure where a judge returns an answer that does not parse.

Can Jev replace permission checks for agent tool calls?#

No. Jev advises on whether a call looks safe, and code still enforces permissions, allowlists and spend caps before anything runs. A call outside policy should be refused without asking Jev at all. For irreversible actions such as deleting an account or sending a payment, a person or a deterministic rule makes the final decision at any Jev confidence.

Where should we start with Jev in an existing agent?#

Start with a shadow tool-call gate on the agent's existing tool calls. Jev scores every proposed tool call and the score goes to the log, and nothing blocks. The agent's behaviour does not change, and after enough traffic the logs show where routine calls and reversed calls sit. That distribution sets the thresholds for the soft gate that follows.

How do we choose thresholds for a Jev gate?#

Set them from your own shadow logs, never from a vendor default. Compare the score distribution for routine calls against calls a person later reversed, then set the auto-run and refuse thresholds around them. Keep the thresholds as named constants in code, send a sample of middle-band cases to a person on a schedule, and move the gate back a step if its outcomes drift.

Does Jev make agents faster or lower cost?#

TypeSafe and LangChain report large speed and cost advantages over frontier LLMs on bounded judgments, and we have not benchmarked those figures ourselves. The saving comes from moving small decisions such as gates, routing and progress checks off the frontier model. Planning and writing stay on the generative model, so the effect on a whole run depends on how many of its steps were judgments.

What should happen when Jev is unsure?#

Treat low confidence as a reason to escalate, never as noise. When the probabilities spread across options, route the case to a person, fall back to the frontier model, or ask the user a clarifying question. Picking the top option regardless throws away the one signal a generative judge could not give you.

Further reading

• How to roll out AI agent autonomy in five levels. The release model a soft gate has to fit inside.
• How to scope AI agent permissions. The Agent Action Boundary, which Jev advises and never replaces.
• How to build an audit trail for AI decisions. Where the full probability distribution for each gate belongs.
• Why AI agents report unfinished work as done. The exit evidence a completion check should judge.
• Agent playbooks as MCP tools. A searchable catalogue for Jev to select from.
• MCP tool design: fewer, larger tools. Keeping the catalogue small enough to select from reliably.
• Shared business context for every AI agent. The governed definitions that make up much of the state Jev reads.
• How to build LLM evals. Measuring a router or gate against real tasks before it goes live.
• TypeSafe, Introducing System One models and Jev, 15 September 2026. The launch post, the three question types, and the vendor's latency and pricing figures.
• LangChain, Building a harness with Jev. Auto-mode and model-router middleware, and the speed comparison against frontier LLMs.
• Learn Jev, Agent harness tutorial. A step-by-step harness with gates and supervisors.
• Vercel, Jev for agent control. Task routing and the AI SDK evaluate integration.
• Jev patterns index. A community index of decision patterns for agents.