What is a reasonable pass@k threshold before promoting an agent to production?

For most workflows, an output consistency rate above 80% over five runs on identical inputs is a workable minimum. For workflows with irreversible side effects, such as payment processing or external communications, you should require a higher threshold and a larger k, typically eight to ten runs.

How is pass@k different from just running accuracy benchmarks?

Accuracy benchmarks measure whether the agent gets the right answer on a fixed test set, usually once per input. Pass@k measures whether the agent gets the right answer reliably across repeated attempts at the same input, which reveals variance that a single-run accuracy score cannot show.

Do I need to instrument every step, or is measuring the final output enough?

For single-step agents, final output measurement catches most failures. For multi-step agents, step-level instrumentation is necessary because two runs can produce identical final outputs via different tool paths, and those path differences may indicate fragility that will surface under different conditions.

How often should I re-run consistency tests after initial evaluation?

Re-run after any change to the model, the prompt, or the tools available to the agent. In practice, this means consistency tests belong in your deployment pipeline, not just in pre-launch evaluation, because model provider updates can shift behaviour without any change on your side.

Reliable Single vs. Multi-Step: How to Evaluate Agent Consistency Across Repeated Runs

What this article covers

You will learn how to measure agent consistency across repeated runs, why pass@1 scores mislead deployment decisions, and what evaluation methods catch variance before it reaches production. The methods apply whether you are running a single agent or a multi-agent orchestrator across several workflows.

Why pass@1 scores are not enough

A pass@1 score tells you whether an agent succeeded on one attempt at one task. Teams use it because it is fast to compute and easy to report. What it does not tell you is whether the agent will succeed on attempt two, or attempt eight, on the same input.

Research published by Stanford HAI in March 2026 measured agent consistency across repeated runs on the τ-Bench and GAIA benchmarks. Despite 24 months of model development, overall reliability showed only small improvements, and consistency remained inconsistent across benchmarks. Capability went up. Reliability did not follow at the same rate.

The pattern shows up in production data too. Fiddler AI's October 2026 enterprise agent failure analysis found that agent performance can drop from a 60% success rate on a single run to just 25% when measured over eight consecutive runs. That gap, from pass@1 to pass@8, is where production incidents live.

Klarna's customer service agent handled 2.3 million conversations in its first month with a 67% automation rate. By May 2025, the company had walked back full automation because consistency problems emerged on edge cases at scale. A strong single-run result did not predict what happened across millions of varied, repeated executions.

What pass@k actually measures

Pass@k is a consistency metric. You run the same agent on the same input k times and record how many runs succeed. The output is not a single score but a distribution: how often does the agent succeed, and does that rate hold as k grows?

A few configurations worth distinguishing:

pass@1: one run, one outcome. Useful for capability screening, not for reliability assessment.
pass@k on identical inputs: same prompt, same tool availability, same context. Isolates non-determinism in the model and runtime.
pass@k on semantically equivalent inputs: inputs that differ in phrasing but express the same request. Isolates sensitivity to surface variation, which matters when users phrase things differently each time.

For multi-step agents, the math compounds quickly. If each step in a three-step chain succeeds 70% of the time independently, the end-to-end success rate drops to roughly 34%. A pass@1 score on the final output will not surface where in the chain the variance originates.

How variance compounds in multi-step workflows

Single-step agents expose variance through output inconsistency. Multi-step agents hide it. Each step may look acceptable in isolation, and the final answer may even pass a surface-level check, but the path taken can differ substantially across runs. Trajectory-level evaluation measures whether the agent took the right actions at each step, not just whether the output looks correct.

Execution tracing is how you detect this. When you record each tool call, the inputs passed to it, and the output returned, you can compare runs at the step level rather than only at the final result. Two runs that produce identical final outputs may have taken different paths, called different tools, or retrieved different context. Whether that matters depends on whether your activity schemas require a specific sequence or only a correct result.

Princeton HAI's reliability tracker, published October 2026, evaluated 14 agents on consistency, predictability, robustness, and safety metrics. Agents showed divergent trends across benchmarks, and the ability to distinguish solvable from unsolvable tasks had, in some cases, worsened over time. That finding matters for multi-step workflows: an agent that cannot reliably recognise task boundaries will produce inconsistent results even when each individual step looks fine.

Building a consistency evaluation framework

A consistency evaluation framework runs the same agent across repeated inputs and records enough information to distinguish four failure types:

Non-deterministic output failures: the model produces a different answer on the same input without any change in context.
Tool selection variance: the agent calls different tools across runs, leading to different information retrieval paths.
Step-ordering instability: the sequence of actions changes across runs in ways that affect the result.
Threshold collapse: the agent succeeds above some accuracy threshold for k=1 through k=3, then falls below it as k increases.

For each of these, you need span-level data from each run, not just the final output. Prefactor records spans for each tool call and model invocation, which gives you the raw material to compare run-to-run behaviour without relying on manual inspection.

ServiceNow's internal deployment measured task completeness, tool-calling correctness, and tool-choice accuracy across ITSM, HR, and finance workflows, reaching 90% self-service on IT support. That level of instrumentation, tracking not just outputs but the correctness of individual tool calls, is what makes consistency assessment possible at scale.

Thrive, a ServiceNow customer, routed 315,000 tasks through automation over six months and achieved 73% first-contact resolution. Evaluation gates before production were part of that deployment. The rate held because the team measured consistency before scaling, not after incidents surfaced.

What to measure and how to act on it

Run pass@k tests before promotion to production and after any model or prompt change. A reasonable minimum for most workflows is k=5. For high-stakes or irreversible actions, k=8 to k=10 is more appropriate.

Record three things per run: the final outcome (pass or fail), the tool calls made and their order, and any intermediate outputs that are used as inputs to downstream steps. Compare these across runs to compute:

Output consistency rate: the fraction of runs that produce the same or equivalent final answer.
Tool call stability: the fraction of runs that select the same tools in the same order.
Step-level pass rate: for each step in the workflow, how often it succeeds independently across runs.

When output consistency drops below roughly 80% over k=5 runs on identical inputs, the agent is not ready for unsupervised production use. That threshold should be lower for workflows with irreversible side effects. Auditing agent behaviour after deployment gives you a way to continue measuring these rates in production, but pre-deployment measurement is what prevents incidents rather than merely recording them.

An August 2025 G2 survey of enterprise teams found that accuracy and consistency problems, not cost or capability, were the leading blockers to production deployment. The teams moving agents to production reliably are the ones treating consistency as a first-class metric alongside accuracy, not as an afterthought once issues appear.

For autonomous background agents operating without human review on each run, consistency evaluation is the primary control you have before incidents compound. Silent failures in production agents are harder to catch after the fact than they are to measure in advance with structured pass@k testing.

Where to start

Pick one agent that is close to production, define five representative inputs, and run each input five times. Record the outputs and the tool calls made on each run. Compare them. If the outputs or paths differ in ways that would matter to a user, you have found your first consistency gap to address. Start evaluating your agents and see the docs for how to instrument spans and run structured consistency tests across your workflows.