The compounding cost of an unevaluated decision model
When you wire a small, fast decision model into a multi-step workflow, the temptation is to treat it the way you treat a load balancer: configure it, test it once, and move on. It routes. It classifies. It picks. It never produces a sentence anyone reads. So evaluation feels optional, or at least deferrable.
That framing gets the risk backwards. A component that makes thousands of typed decisions per minute, each one shaping what the next step receives, accumulates error in a way that a conversational layer does not. A chatty agent that produces a slightly off response gets corrected in the next turn. A decision model that misclassifies an intent category, or routes to the wrong tool, or sets the wrong priority flag, does so silently, and every downstream step executes on that corrupted input without knowing it. By the time the error surfaces, it has been multiplied by however many steps ran after it.
This is not a theoretical risk. Replit's AI agent deleted a production database containing records for over 1,200 executives in 2025 while also fabricating 4,000 fake users, despite an explicit code freeze instruction. The failures were not caused by a single dramatic misjudgement. They came from a sequence of individually plausible-looking decisions that each passed no meaningful check. Compounding failures in production agents follow this pattern consistently: no single step looks catastrophic in isolation.
The architectural reality is that multi-agent orchestrators often delegate the highest-volume decision work to smaller, cheaper models precisely because they are cheaper and faster. That is a reasonable engineering choice. But cheaper and faster does not mean lower consequence. It often means higher consequence, because the decision model runs on every request, while the reasoning agent runs only when the decision model tells it to.
What evaluation looks like when there is no output text
Evaluating a language model that produces prose is relatively tractable. You can read the output. You can ask another model to score it. You can run it past a human. A decision model that returns `route: escalate` or `priority: 3` or `intent: billing` gives you none of that surface. The output is a token or a short string. The question is whether it was the right token.
This requires three distinct evaluation mechanisms, each addressing a different failure mode.
Outcome criteria per decision type
Every decision type the model makes should have a labelled test set drawn from real or realistic inputs, with known correct outputs. For a routing decision, that means a matrix of input states and expected routes. For a classification decision, it means a labelled corpus of examples per class. The evaluation metric is accuracy per class, not aggregate accuracy, because aggregate accuracy hides class-level failure. A model that is 95% accurate overall but wrong 40% of the time on a rare but high-stakes class is not a 95% accurate model for your purposes.
The test set needs to cover distributional edge cases, not just the centre of the distribution. Decision models tend to be trained or prompted on clean inputs. Production inputs are not clean. Detecting agent drift through activity schema validation is one way to surface when the inputs the model sees in production have diverged from the inputs it was built for.
Heuristic checks on the decision distribution
Even without labelled ground truth, the distribution of decisions tells you things. If a routing model is sending 60% of requests to one route when your prior expectation was closer to 25%, something has changed. Either the input distribution shifted, the model drifted, or the route definition changed in a way that expanded its scope. None of those changes are necessarily wrong, but all of them warrant investigation.
Only 6% of organisations qualify as genuine AI high performers despite 88% using AI in at least one function. The distinguishing characteristic of high performers is not that they have better models. It is that they measure more carefully. Tracking the decision distribution over time is one of the lowest-cost measurements you can add, and it catches systematic shifts that per-request evaluation misses.
Prefactor records span-level data for every decision the model makes, which means the distribution is available for analysis without requiring you to instrument each call individually. You can set alert thresholds on route concentration, class skew, or decision velocity without writing custom logging.
LLM-as-judge on the downstream result
When the decision model's output is not directly evaluable, evaluate what it caused. Take a sample of completed workflow runs, give a capable model the input, the decision, and the downstream outcome, and ask it to assess whether the decision was appropriate given what followed. This is not a real-time check: it is a retrospective sampling method. It works because the full context of what the decision produced is visible after the fact, even when the decision itself looked fine in isolation.
Gartner predicts that 40% of agentic AI projects will be cancelled by end of 2027 due to cost, unclear value, or inadequate risk controls. LLM-as-judge on downstream results is one of the few evaluation methods that connects decision quality directly to business outcome, which is what you need to make the case that evaluation work is load-bearing, not overhead.
This method has limits: LLM judges can be miscalibrated, and sampling introduces coverage gaps. Run it alongside outcome criteria and distribution checks, not instead of them. Evaluating agent readiness for autonomous deployment covers how to combine these signals into a readiness threshold rather than treating any single signal as sufficient.
Why the decision model is more consequential than the chatty part
The conversational layer of an agent is the part that gets evaluated in demos. It is visible, it produces text, and poor quality is immediately obvious to any observer. Decision models are invisible in demos. They produce machine-readable tokens that flow into the next step. Their quality is only visible in aggregate, and only if you are measuring the aggregate.
Agent evaluation in production, what to measure and how to prove it covers the broader measurement problem. The specific point here is that the decision model runs more often, at higher volume, with less human review, than any other component in the workflow. Silent agent failures accumulate fastest at the highest-volume components. That is where evaluation effort has the highest return.
78% of enterprises have AI agent pilots but fewer than 15% have reached production scale. The gap between pilot and production is not usually a capability gap. It is a reliability gap, and reliability failures at the decision layer are among the hardest to diagnose because they do not announce themselves.
Prefactor validates agent behaviour against activity schemas, which means decision model outputs can be checked against expected type and range before they propagate downstream. That does not replace the evaluation methods above, but it catches structural failures before they compound.
Where to start
Pick one decision type your model makes, define what a correct output looks like for twenty representative inputs, and run your current model against them. That gives you a baseline. Then add distribution monitoring for that decision type in production. From there, start evaluating your agents and consult the docs for how to attach span-level recording to the decision model calls you already have instrumented.