ConceptAgents & Tool Use
Decision Model
At a glance
A model that picks from a list the harness wrote and returns a probability, used inside an AI agent for the small repeated choices.
- Who this is for
- Engineers and technical readers learning the terms used in AI systems.
- Topics
- Agents & Tool Use
- Concept
In short
A decision model in an AI agent picks from a list the harness already wrote and returns a probability for each option, instead of writing free text. Bigcircle recommends keeping that pick beside checks code can already make, such as a permission scope and a validation loop, and letting it replace a model call only after an eval on real runs shows a gain. The guide on introducing Jev into agentic workflows covers TypeSafe's Jev, and this page stays with the category.
Key facts
Definition
A decision model returns a probability for every option in a list the surrounding code wrote, and it does not write the plan or the tool call.
How Bigcircle does it
- On Solarpunk, the executive operations agent Bigcircle built, a critic chooses continue, retry or escalate after every step, and that short list is the question a decision model is built to answer.
- On Skionis, Bigcircle's DevOps agent on a live AWS account sends a template that fails structural and semantic checks through a bounded revision loop and then to a person, and that validity check stays in code.
- Bigcircle traces a real run before changing a harness, and a decision layer has to be scored on the states its own answers create before it replaces a call.
Comparison
A language model writes the next action as text that code must parse, while a decision model picks from options the harness listed and returns a probability the harness can threshold.
Key number
Sumanth's 25 October 2026 account of JevAgentHarness says the best model on isolated decision questions completed only 69.5% of full agent tasks, and that an unfitted confidence threshold dropped task success by 19 points.
A decision model, in an AI agent, chooses from a list your code already wrote and returns a probability for each option. It does not write the plan, the tool arguments or the message a person reads. Search results for the phrase usually describe a business framework for a pricing or hiring choice. This page is about decision models in AI agents and agentic workflows, where the same small choice repeats on every step.
On Solarpunk, the executive operations agent we built, a critic looks at each step and chooses continue, retry or escalate. On Skionis, our DevOps agent on a live AWS account, a template that will not come clean after bounded revision goes to a person.
Both questions already have a short list of answers, which is the shape a decision model is built for. The check that says whether the template is valid stays structural and semantic against the account, and most errors die in that loop before AWS is asked to start anything.
What is a decision model in an AI agent?#
Sumanth's account of JevAgentHarness, posted 25 October 2026, puts the return value in one line: the decision model returns probabilities over the available options, and a low confidence sends the choice back to the larger model. Cloudflare's Clef and Clef-flash are open-source decision models for fast, bounded structured outputs in agentic workflows. A generative model answers the same question as text your code has to parse, and that text arrives with no probability to set a threshold against.
The list has to exist before the call. Onur Solmaz built Switch as a harness framework for decision models like Jev, because a decision model cannot generate tool calls the way a coding-agent harness expects. Switch builds the choices in code, and the model only picks from that finite set.
He writes that there is no single harness for every decision model, since each domain has to generate its own choices. Chess is one domain he names, and a rubric judge for evals is another.
We already separate those two jobs on Solarpunk. Tool selection held until roughly thirty tools sat in the prompt, and then the model began picking plausible but wrong tools. It recovered once each plan step searched a registry for the few tools that step needed.
Give a decision model that short list. Keep the permission check in code the agent cannot edit, which is how our harness engineering treats every action that can change something. We leave the validity check in code on Skionis too, because comparing a template with the account does not need a model.
How do decision models fit inside a harness?#
Put the rule you can write in code ahead of any model. younes plugs decision models into safeagents as a stronger check on top of rules. The model is asked only about calls the rules have already flagged as suspicious, so a clean call adds no model cost.
The verdict is a short JSON object, allow or block plus one sentence. The prompt holds the user's request, the tool call and the scan findings, and it leaves out the agent's reasoning and the tool outputs, so the agent cannot talk the check out of a block.
That is the order on Skionis, where a machine check runs before a person is asked to approve anything. Show a decision model the agent's own argument and the agent can steer the verdict. Ask it about the call and the rule that fired. Leave the reasoning out of the prompt, and leave the permission scope in code the agent cannot rewrite.
Kush writes that decision models can act as scouts inside a harness, checking whether a file is worth reading before the agent spends a call on it. The same post records that his team had to remove Jev from the Puffle harness, because, he writes, Jev kept making wrong assessments that led the agent astray.
A scout that skips a file helps only when that file was never needed, and a wrong skip removes a fact the next step would have used. Log every skip and read the log against the questions that failed.
What is a Jev decision model?#
Jev is TypeSafe's decision model, and it is the one these posts are written around. It takes a state and typed questions and returns a probability for each option you listed, and it writes no text and runs no tool. Where those answers should sit in an agentic workflow, and the order for giving them more say while code keeps permissions and side effects, is our guide to introducing Jev into agentic workflows. Our agents already make those short-list choices, and the guide is where we set the order. This page does not repeat it.
Amy Slawson moved a classifier off an LLM judge and onto Jev. She writes that it matched the LLM on accuracy and runs much faster, and that it did not do so out of the box. The post is five lessons from tuning it, which are not restated here.
Solmaz, in the Switch post, writes that Jev is not yet a match for the generative judge in the domain he is working on, and that it plays chess badly. Keep a generative judge, as on our page about LLM-as-a-judge, until labels from your own traffic exist to tune against.
Where does a decision layer sit?#
Sumanth uses decision layer for the smaller model that takes the bounded choices between a larger model's reasoning steps, such as which tool to call, whether the task is done and what should happen next. Above a threshold learned from the agent's own trajectories, the harness uses that answer. Below the threshold, control returns to the larger model.
He writes that accuracy on the isolated questions was not enough. The model that scored best there completed only 69.5% of full agent tasks, and delegating tool choices without fitting the confidence threshold dropped task success by 19 points. One wrong tool call changes the state the next decision sees, so a model that looks right on a worksheet meets situations its training never included.
We trace a real run before we change a harness, and our harness work starts from that trace. Score a decision layer on the states its own answers create, in the loop you already log, before it replaces a call.
When a decision model does not pay for itself#
Karthik Bhaskar posted a decision model that advised an agent when to continue or when to verify. Cost per attempt rose 1.19x, with a 95% confidence interval from 1.02 to 1.36, and the pass rate was 73.0% with the model and 73.0% without it. He marks the underlying study as one author and 21 tasks, so the matching pass rates are no detectable difference. His distinction is the one we use.
A layer that decides for the model is overhead until an eval shows a gain, so remove it and run the eval again. A layer that limits what the model can do, the permission scope and the validation loop, stays and gets tested.
Leave those limits where they are. Add a decision model beside a check you already record, compare its answers with what happened, and take it out when the eval shows no gain.
A team with no labelled outcomes for that check has nothing to fit the threshold to. An unfitted threshold produced the 19-point drop in the result Sumanth cites. Our page on loop engineering is where the run cap and the trace around that check belong.