What you get from measuring steps, not just outcomes
Final-output evaluation tells you whether an agent finished correctly. It does not tell you which step went wrong first, or how far a bad intermediate decision propagated before the output landed. For a 10-step workflow, a clean final answer can mask three quietly incorrect reasoning transitions that happened to cancel each other out, until the next run when they do not.
This article covers how to instrument agents so that each tool call, retrieval, and reasoning handoff is scored on its own terms, not just absorbed into the final result. The techniques apply to any agent framework; the goal is to stop compounding failures in production agents before they compound.
Why production failures look different from benchmark failures
On a benchmark, an agent either resolves the task or it does not. Anthropic measured Claude 3.5 Sonnet at 49% on SWE-bench Verified, a set of 500 human-validated real-world GitHub issues requiring step-by-step code generation, repository navigation, and test execution. That number is meaningful, but it describes end-state success. It does not describe which navigation steps failed, which test-execution calls produced stale context, or how errors at step 3 affected the search strategy at step 6.
Production agents run the same workflow thousands of times on inputs that diverge from the training distribution. A March 2026 survey of 650 enterprise technology leaders found that 78% of enterprises have AI agent pilots but fewer than 15% have reached production scale. The gap is not primarily a model capability problem. A June 2026 analysis found that 60% of AI production failures trace to data quality, context, or governance problems rather than model limitations, each of which appears first at an intermediate step, not the final output.
The benchmarks-to-production gap widens because benchmark conditions stay fixed while production inputs drift. An agent that retrieves the right document 94% of the time in staging may retrieve the right document 81% of the time six weeks later, as the knowledge base changes and query patterns shift. That 13-point drop at step 2 may produce a 30-point drop in final-answer quality by step 8, because every downstream step reasons from a weaker foundation.
What step-level evaluation actually measures
Step-level evaluation assigns a score or a pass/fail signal to each discrete action an agent takes, before aggregating anything. The three categories worth instrumenting are:
Tool call quality. For each external call, check whether the agent selected the right tool for the context, constructed the call parameters correctly, and handled the response without discarding relevant information. Zapier's work with structured input validation across more than 7,000 application integrations illustrates this directly: replacing free-text fields with typed inputs such as dropdowns and IDs reduced intermediate-step errors measurably, because the validation probe sits at the tool call boundary, not at the end of the workflow.
Reasoning transition quality. Between each tool call, the agent produces an internal state update: it reads the result and decides what to do next. This transition is where silent agent failures most often begin. A retrieval step that returns three documents when the agent expected one forces the agent to select; if the selection logic is not evaluated, you do not know whether the agent consistently picks the most relevant document or whether it defaults to the first item in the list.
Decision-point consistency. At branch points where the agent chooses between two or more paths, consistency across similar inputs is its own signal. If the agent takes path A for input X on Monday and path B for the same input X on Thursday, a model update or context-window change shifted something. Detecting that drift requires that you recorded what the agent chose and why at each decision point, not just what it produced at the end.
Designing evaluation probes for intermediate steps
A probe is a lightweight scorer attached to a specific span in the agent's trace. Each probe answers one question about one step. Keep each probe narrow: a probe that checks "did the retrieval return a document with cosine similarity above 0.75 to the query" is actionable; a probe that checks "was the retrieval good" is not.
Stripe's compliance review system, which handles payment volume across 50 countries, uses a ReAct framework with human oversight checkpoints built into each reasoning layer. The 26% reduction in review handling time came in part from the checkpoints surfacing which specific steps needed human review rather than routing every case to a human reviewer. That is probe design applied at scale: the checkpoint is a scorer on a span, not a blanket review gate.
For probe placement, instrument at a minimum:
- The first retrieval or data-fetch step, because every downstream step inherits its quality.
- Any step that writes to an external system, because errors there are not recoverable by later steps.
- The reasoning transition immediately before a branch point, because that is where inconsistency originates.
- The final synthesis step, as a baseline to compare against the intermediate scores.
Prefactor records each of these as a span with its own score and metadata, so you can query "show me all runs where the retrieval probe passed but the synthesis probe failed" and identify the steps in between that absorbed the degradation.
Connecting step scores to production reliability
The operational case for step-level evaluation is not abstract. Continuous evaluation reduces production incidents by 67% compared to periodic evaluation, according to a 2025 Deloitte analysis, with evaluation infrastructure typically running 10 to 25% of agent operating costs. Teams that skip intermediate evaluation spend three to five times more on incident response.
Intercom's Fin AI Agent reached resolution rates of 56% on average, with some customer segments reaching 70 to 80%, after the team moved from manual spreadsheet testing to automated evaluation systems. The shift was not just about volume; automated evaluation made it possible to score individual conversation turns rather than only full resolution outcomes, which surfaced which turn types were driving abandonment.
The practical architecture that connects step scores to reliability is straightforward. Each span in a trace carries its own score. A run-level score aggregates the spans. You alert on span-level degradation first, because span-level signals appear earlier than run-level signals. If the retrieval probe for a RAG retrieval agent drops from 91% pass rate to 78% pass rate over 48 hours, you have a signal worth investigating before it surfaces as a drop in resolution rate a week later.
Validating agent behavior against activity schemas at the span level also gives you an audit trail that is genuinely useful for debugging: when a production failure occurs, you can trace it to the specific step where it originated rather than inspecting the entire run.
Where to start
Pick one workflow with at least five steps and instrument three probe points: the first data fetch, the step immediately before the most consequential branch point, and the final output. Run that for two weeks before adding more probes. Once you have baseline pass rates per step, you will see drift before it reaches your users.
Start evaluating your agents and review the docs for SDK instrumentation and schema validation setup.