If my agent scores 90% on a standard benchmark, what does that actually tell me about production reliability?

It tells you how often the agent reached the correct end state on the benchmark's test cases. It does not tell you how many steps failed and recovered silently, whether step-level outputs are stable across model updates, or how accuracy degrades as workflow length increases. A 90% end-state score on a 10-step workflow is consistent with per-step accuracy as low as 99% or as high as lower than you would expect, depending on how errors compound.

How do critic agents differ from just running the same model twice?

A critic agent is a separate model, usually smaller and faster, that evaluates a specific step's output against defined criteria: is this the correct data type, does it contradict information established earlier, is this action irreversible. Running the same model twice tends to reproduce the same errors. A critic with a narrower, explicit rubric catches the semantic errors that schema validation alone does not catch, at lower cost than re-running the full step.

At what workflow length does per-step monitoring become worth the engineering overhead?

The compounding effect becomes practically significant around five to six steps with per-step accuracy in the 90-95% range. Below five steps or above 98% per-step accuracy, end-state monitoring may be adequate. In practice, most production agentic workflows that touch external systems or produce irreversible outputs are long enough that per-step instrumentation pays for itself after the first prevented incident.

How does a model update cause step-level drift even when the new model scores better overall?

Model updates change how outputs are formatted and structured, not just their semantic content. A step that previously returned a plain integer may now return a formatted string with units appended. The next step expecting an integer receives something it cannot parse, and the chain fails at a point unrelated to the model's actual capability improvement. Schema validation at step boundaries catches this class of regression immediately, before it reaches production traffic.

The Step-Level Accuracy Problem: Why Your Agent Works in Benchmarks But Fails in Production

Why benchmarks give you the wrong number

Most benchmark scores measure whether an agent reached the right end state. They do not measure how it got there, or how often intermediate steps degraded before the final answer arrived. That distinction matters a great deal once you move past toy tasks.

A 2026 Zylos Research analysis found a 37% performance gap between lab scores and production outcomes across agent configurations. That gap is not random noise. It is the accumulated effect of step-level errors that benchmarks either average away or never see in the first place.

The math is straightforward. If each step in a workflow succeeds 95% of the time, a two-step task completes correctly about 90% of the time. A five-step task drops to 77%. A ten-step task lands at roughly 60%, meaning four out of ten runs produce a wrong or incomplete result, even though every individual step looks nearly perfect in isolation. Benchmark suites that test end states only will score that agent at 95% and declare it production-ready.

What goes wrong at the step level

Research across 2024-2025 enterprise deployments found that 61% of all AI agent failures trace back to scope creep and data quality issues, with another 31% caused by tool misuse or incorrect tool arguments. Neither of these failure modes is visible in a final-output score. Both are visible if you record what each step did, what it passed to the next step, and whether that output matched what the workflow expected.

Failures compound because agents are stateful. A retrieval step that returns a slightly wrong document does not fail loudly. It feeds a plausible-looking context to the next step, which acts on it, and the error propagates. By step six or seven, the agent may be operating confidently on a premise established in step two that was never correct. The final output often looks coherent even when it is wrong, which is why human review at the end catches far less than per-step validation does.

Scale AI's 2025 State of AI Evaluation reported that 34% of enterprises experienced unexpected agent behavior changes following a model update, and 12% saw incidents severe enough to require human intervention. Model updates are one of the cleaner examples of step-level drift: a prompt that previously extracted a date correctly may now return a formatted string where a downstream step expected an integer, and the chain breaks at a point that has nothing to do with the model change itself.

Real deployments that surface this

JPMorgan Chase's production AI estate now includes agents running for over an hour across multiple back-office systems, processing what the firm describes as part of its $10 trillion in daily transaction volume. At that scale and duration, intermediate validation checkpoints are not optional. A failure at step three of a twelve-step reconciliation workflow cannot wait until the end to be detected. The firm built those checkpoints into agent architecture before expanding coverage, not after an incident forced the change.

Goldman Sachs reported 3-4x productivity gains from autonomous coding agents operating across multi-file refactoring, testing, and deployment validation. A coding agent doing multi-file refactoring is running dozens of discrete steps: parse the call graph, identify affected files, rewrite each file, run tests against each change, validate the deployment manifest. Each step has a defined output that the next step depends on. The productivity gains described are only sustainable if those intermediate outputs are correct often enough that the chain does not break and require human restart.

Stripe's March 2026 benchmark for agent-built integrations found that best-performing runs averaged 63 interaction turns per task. That figure reveals something the headline accuracy score does not: even the best models needed dozens of intermediate steps, each of which could have drifted or failed, to complete tasks that a final-output score records as a single pass or fail.

Replit's agent platform orchestrates workflows from requirements drafting through database provisioning, code generation, testing, and deployment. The platform explicitly tracks autonomy level and step-level failure recovery, because a failure in database provisioning corrupts every downstream step. Teams using the platform report 50% reductions in development cycle time, which depends on the agent recovering from or preventing step-level failures rather than surfacing them only at the end.

Measurement frameworks that work in production

Three operational patterns appear consistently in teams that have moved past benchmark-only evaluation.

Per-step span recording. Each step in the workflow emits a span with its inputs, outputs, latency, and a structured result. This is the same model that OpenTelemetry uses for distributed systems, applied to agent actions. Without spans, you are reading aggregate logs and guessing where failures originate.

Schema validation at step boundaries. Before a step's output is passed to the next step, it is checked against a defined schema: data types, required fields, value ranges. This is what activity schema validation provides. A step that returns a string where a float was expected fails immediately, not three steps later when the math breaks.

Critic agents on high-risk steps. A secondary model reviews the output of steps that are either irreversible or load-bearing for the rest of the chain. This adds latency to those specific steps, typically 200-800ms depending on the critic model, but it catches the category of failure that per-step schema validation alone misses: outputs that are correctly typed but semantically wrong.

Prefactor instruments each of these patterns via its SDK. It records spans per agent step, scores outputs against quality and risk criteria, and validates step outputs against activity schemas you define. The audit trail captures what each step produced, not just whether the final task completed. If a model update changes step three's output format, the schema validation surfaces it before it propagates.

For teams watching production drift rather than just launch-time benchmarks, the gap between "passed evaluation" and "still working correctly after a model rollout" is where most reliability problems live. Rollback detection closes that gap by comparing step-level distributions before and after changes, not just end-state accuracy.

The reliability gap between benchmarks and production is also closely tied to how you define and scope agent identity, since a misconfigured agent boundary means step-level errors in one workflow can affect another.

Teams building autonomous background agents or multi-agent orchestrators face the most acute version of this problem, because their workflows are longest and their intermediate states are least visible to human reviewers.

Where to start

Pick the workflow where a failure has the highest cost, map its steps explicitly, and instrument each boundary with a span and a schema check before you add any other evaluation layer. You do not need to instrument everything at once; one workflow with full step coverage teaches you more than ten workflows with end-state scoring only.

Start evaluating your agents or read through the docs to see how span recording and schema validation are set up in practice.