Six Ways Multi-Turn Agent Evals Break in Production

The Anatomy of an Agent Test Harness

When evaluating autonomous agents, the industry's default reflex is to treat the problem as an extension of prompt engineering. Teams pull in an LLM-as-a-judge rubric, compare generation strings against golden outputs, and wonder why their test suites collapse the moment an agent touches the real world. I have found that evaluating agents requires treating agent evaluations as software integration testing rather than prompt grading. An agent does not merely produce tokens; it executes multi-turn control loops, mutates environmental state, and interacts with external tools.

The evaluation harness must reflect that operational reality. Instead of inspecting conversational prose, the harness seeds a disposable runtime, injects the initial task specification, connects the agent to tools via the Model Context Protocol (MCP), and monitors the execution loop until termination. Once the agent concludes its trajectory, the harness evaluates the resulting side effects: Did the code pass compilation? Did the database record update? Did the newly authored MCP server pass its integration suite?

flowchart TD
    A["Task Specification & Environment Seed"] --> B["Inject Objective & Tools"]
    B --> C["Agent Reasoning & Execution Loop"]
    C --> D["Tool Invocations in MCP Sandbox"]
    D --> E{"State Mutation Complete?"}
    E -- No --> C
    E -- Yes --> F["Execute Side-Effect Unit Tests"]
    F --> G["Evaluate State Delta & Run Static Analysis"]
    G --> H["Record Trajectory & Latency Metrics"]

This introduces a foundational architectural split: intermediate trace inspection versus side-effect verification. Trace-based graders—such as those popularized in LangSmith or DeepEval—evaluate each step of the agent's reasoning trajectory against an expected execution graph. If step two invokes a file reader with unexpected arguments, the grader fails the run immediately.

While trace grading provides rapid feedback and clean attribution, it is inherently brittle. It penalizes an agent that makes a sensible detouring query, discovers an alternative path, or successfully self-corrects after an initial misstep.

Conversely, end-state side-effect testing treats the agent as a black box and evaluates the final environment. Much like running SWE-bench or isolating execution via Anthropic srt or Docker Containers for Securing Local Agent Execution, the harness runs deterministic test suites against the final workspace:

task:
  id: "fix-auth-bypass_1"
  desc: "Fix authentication bypass when password field is empty and ..."
  graders:
    - type: deterministic_tests
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
    - type: llm_rubric
      rubric: prompts/code_quality.md
    - type: static_analysis
      commands: [ruff, mypy, bandit]
    - type: state_check
      expect:
        security_logs: {event_type: "auth_blocked"}
    - type: tool_calls
      required:
        - {tool: read_file, params: {path: "src/auth/*"}}
        - {tool: edit_file}
        - {tool: run_tests}
  tracked_metrics:
    - type: transcript
      metrics:
        - n_turns
        - n_toolcalls
        - n_total_tokens
    - type: latency
      metrics:
        - time_to_first_token
        - output_tokens_per_sec
        - time_to_last_token

The tradeoff is cost and infrastructure complexity. Spinning up ephemeral MCP sandboxes, seeding relational tables, and executing test suites requires real engineering overhead. But without hermetic sandboxes executing side-effect checks, an evaluation suite is merely grading prompt eloquence while remaining blind to broken state mutations.

Failure Mode 1: False Rejections from Creative Frontier Solutions

The most frustrating failure mode in an agent test harness is not when the agent fails the user; it is when the agent solves the user's objective brilliantly, yet fails the evaluation. As model capability increases, static evaluation assertions break down because rigid assertions penalize frontier models for discovering valid, cheaper solutions.

We saw this dynamic clearly when evaluating Opus 4.5 on $\tau^2$-bench across multi-turn flight-booking benchmarks. The evaluation harness set up an objective with explicit constraints around passenger names, departure dates, and destination cities. The test harness had a hardcoded assertion expecting a single roundtrip booking confirmation ID returned in the final tool payload.

Instead of following the predictable roundtrip path, Opus 4.5 analyzed the synthetic airline policy and pricing tables, identified that two separate one-way itineraries were significantly cheaper than the combined roundtrip ticket, and booked both legs independently. The user received a cheaper ticket that met every constraint. The harness, however, executed a rigid schema assertion against the booking confirmation object, found two separate reservation codes instead of a single roundtrip payload, and marked the entire evaluation as a failure.

This pattern reveals a critical flaw in traditional software assertion design applied to frontier models:

1. Rigid Schemas Trigger False Negatives: Hardcoded regex matchers, exact SQL equality checks, and strict parameter schemas reward compliance over competence. When a model discovers an edge case or navigates a policy loophole, static checkers flag legitimate innovations as breaking regressions.
2. Permissive Loopholes Invite Reward Hacking: When teams notice high false-rejection rates, their immediate reaction is often to loosen assertions or fall back entirely on unstructured LLM-as-a-judge rubrics. The moment graders become too flexible, agents game the specification—such as generating mock stub functions that satisfy superficial test names without implementing actual authentication checks.
3. The Static Assertion Fallacy: Teams operate under the false assumption that writing a deterministic unit test suite is a one-time effort. In reality, as models advance from simple instruction followers to autonomous problem solvers, the test harness itself suffers from specification decay.

If you do not schedule continuous evaluation triage to separate true agent failures from rigid harness specifications, your benchmark leaderboard will penalize your most capable model configurations while rewarding inferior models that blindly follow inefficient, expected paths.

Failure Mode 2: Cascading Compounding Errors Across Multi-Turn Trajectories

In a single-turn evaluation, failure probability is bounded to an isolated request: $P(\text{success}) = p$. In an autonomous multi-turn agent execution, success decays exponentially across steps: $P(\text{success}) \approx p^n$. Because each subsequent action depends on prior reasoning traces and environmental mutations, compounding error decay turns minor step-level discrepancies into total terminal divergence.

What makes compounding errors insidious in production harnesses is how innocuously they begin. In step two of an eight-step task, an agent might supply an off-by-one line index or a slightly non-standard JSON parameter to a mocked filesystem tool. A robust human operator would notice the error message and adapt. An autonomous agent, however, often ingests the raw tool error into its context window, misinterprets the failure as a systemic defect in the underlying environment, and diverges into loop thrashing.

stateDiagram-v2
    [*] --> InitialPlan: Receive Task & Tools
    InitialPlan --> ActiveExecution: Execute Step 1 Tool Call
    ActiveExecution --> MinorDeviation: Step 2 Schema Mismatch or Off-by-One Param
    MinorDeviation --> ContextPollution: Malformed Tool Error Ingested
    ContextPollution --> LoopThrashing: Steps 3-7 Repeated Failed Retries
    LoopThrashing --> TerminalTimeout: Exceed Step Budget / Context Limit
    TerminalTimeout --> [*]

This failure pattern exposes the operational tension between step-by-step trace grading and end-state verification. Frameworks like LangSmith grade each node in the execution graph sequentially. If the agent makes a minor mistake at step two, a trace grader marks it as an error immediately. While this isolates the divergence point, it prevents the harness from testing whether the agent possesses the capability to recover autonomously.

Conversely, end-state evaluation allows the agent to run its entire course. But when the agent fails at step eight after thrashing in a retry loop, root-cause diagnosis becomes an exercise in forensic transcript analysis. Did the agent fail because its underlying reasoning broke down? Did the tool documentation provide ambiguous parameter descriptions? Or did a slight defect in the mock API payload pollute the context window?

To debug compounding failures effectively without reverting to brittle step-by-step assertions, you must track trajectory health metrics alongside end-state assertions:

• Trajectory Step Budgets: Enforce strict thresholds on total allowable turns (max_turns: 10) and flag any trajectory where the agent executes the same tool with identical parameters more than twice.
• Parameter Variance Analysis: Measure argument diversity across consecutive tool invocations to identify loops before the agent consumes its entire context token budget.
• Transcript Anomaly Attribution: When an end-state test fails, correlate the failure against the transcript's error payloads. If eighty percent of downstream failures stem from ambiguous error descriptions returned by your own tool mocks, the defect lies in your harness documentation, not your agent's reasoning.

Failure Mode 3: State Contamination in Shared and Leaky Environments

The moment you commit to side-effect verification, the test environment ceases to be a passive observer and becomes an active participant in your test assertions. If an agent must prove its competence by editing source files, migrating schemas, or spinning up a Model Context Protocol (MCP) server, the execution sandbox accumulates real mutations. The failure mode I watch for in shared harnesses is state leakage: non-hermetic test harnesses turn evaluation suites into flaky distributed systems disasters.

When teams attempt to optimize test runtime by reusing a shared directory or persistent container across sequential evaluation runs, side effects inevitably bleed across boundaries. An agent tasked with debugging an MCP server might spawn a long-running background daemon, write temporary configuration artifacts, or leave dangling SQLite locks in the repository. If the test runner terminates the trajectory upon reaching a timeout, those mutations persist. When the next test case spins up in the same environment, it does not evaluate the agent against a clean baseline; it evaluates the agent against the detritus of a failed predecessor.

This dynamic mirrors the classic failure modes of distributed systems testing. In production harness engineering, mock services introduce subtle divergences that corrupt evaluation fidelity. A local mock server that implements simplified HTTP responses often fails to model real-world edge cases—such as socket resets, rate-limit headers, or partial writes. An agent can easily master the quirks of an in-memory mock, achieving a flawless pass rate in local evaluation, only to fall into infinite retry loops when deployed against live production APIs.

Worse still is the issue of non-deterministic cleanup. If an agent executes an uncommitted database migration or modifies file permissions during a failed attempt at self-correction, subsequent unit test assertions fail spuriously. The harness operator attributes the failure to a drop in model reasoning capability, spending days tuning system prompts to fix an issue that was actually caused by a dirty filesystem.

Isolating local agent execution using ephemeral boundaries—such as container sandboxes or the patterns explored in Anthropic srt or Docker Containers for Securing Local Agent Execution—is not an optional operational hardening step. It is the baseline prerequisite for deterministic side-effect grading. Without hermetic isolation per trajectory, test results measure environmental contamination rather than agent capability.

Failure Mode 4: The Brute-Force Self-Correction Blindspot

Binary pass/fail grading is a dangerous metric for autonomous agents because a binary pass score completely obscures whether an agent is surgically competent or economically unviable. In traditional software testing, a unit test that passes after five assertion retries within a single test runner process is generally acceptable. In agent evaluation, treating an agent that solves a task on turn one identically to an agent that thrashes across ten turns before stumbling into a solution creates a massive blindspot.

Consider an evaluation where an agent must repair a broken authentication handler. Agent A inspects the source, identifies the faulty validation line, applies an exact patch, and passes the unit test on turn two. Agent B misidentifies the root cause, modifies three unrelated modules, triggers repeated syntax errors, and invokes six consecutive shell execution commands to brute-force a passing configuration. On your CI dashboard, both agents receive a score of 1.0.

In production, Agent B is a liability. It burns through hundreds of thousands of context tokens, saturates rate limits, introduces unpredictable latency, and risks introducing subtle side effects across unrelated files. Relying solely on final state verification rewards this unstable behavior. The model learns that context thrashing is acceptable as long as the harness assertions turn green before the hard execution timeout hits.

To eliminate this blindspot, an evaluation harness must track trajectory efficiency metrics directly alongside functional assertions:

  - type: transcript
    max_turns: 10
tracked_metrics:
  - type: transcript
    metrics:
      - n_turns
      - n_toolcalls
      - n_total_tokens
  - type: latency
    metrics:
      - time_to_first_token
      - output_tokens_per_sec
      - time_to_last_token

I calculate a turn efficiency ratio: the minimum necessary tool invocations required to complete the task divided by the actual tool calls consumed. When you combine this with compute cost per solved task, your leaderboard reflects operational viability. If an updated model release raises your functional pass rate from 80% to 85% but triples the median turn count, you haven't deployed an upgrade; you have deployed an expensive brute-force search loop.

Triage: Diagnosing Harness Failures in CI/CD

When an agent evaluation job turns red in CI/CD, the instinct among engineering teams is to immediately modify the system prompt or blame a silent regression in the underlying model. I've found that treating a red run as an automatic agent defect without checking environmental telemetry burns hours on phantom prompt tuning. You must audit whether the agent actually failed the task or whether your test harness broke underneath it.

Failure Mode	Observable Symptom in CI Output	Immediate Diagnostic Inspection
Creative Frontier Solution	Task assertions fail on strict schema validation, but side-effect state matches business objectives with lower turn or token spend.	Diff the environment mutation against the raw objective; check if the final outcome satisfied constraints through an alternative, unmodeled path.
Compounding Trajectory Error	Transcript hits max_turns: 10 with repeated identical tool invocations and mounting validation error dumps in context.	Inspect transcript step 2 and step 3; verify tool mock return payloads for malformed JSON, ambiguous parameter documentation, or raw stack traces.
Environmental State Contamination	Job fails at step 0 or turn 1 with file-lock exceptions, existing port bindings, or uncommitted database migrations.	Inspect runner container teardown logs and filesystem diffs between consecutive runs; verify sandbox isolation boundaries.
Brute-Force Self-Correction	Deterministic unit tests pass, but n_turns and n_total_tokens surge 4x to 10x past the budgeted baseline.	Cross-reference transcript tool invocation counts with shell test execution logs to identify cyclic trial-and-error thrashing.

Before refactoring tool definitions or adjusting temperature settings, follow a strict triage audit sequence. First, review the transcript's initial divergence point. If the model executed a novel tool sequence that ultimately reached the target state, the defect is specification decay in your test assertions. Second, examine mock API fidelity: if mock payloads return ambiguous errors, the agent's downstream loop thrashing is an artifact of harness design, not reasoning degradation.

Finally, check runtime isolation. If an evaluation failure reproduces only when running as part of a full test batch but passes in isolation, you are debugging state leakage, not agentic capability.

Designing Multi-Layered Harnesses That Survive Production

Building an evaluation harness that survives daily production demands an architecture grounded in defense in depth. You cannot rely on a single grader type, nor can you run hundred-turn interactive sandboxes on every pull request without exhausting your engineering budget.

A resilient agent evaluation harness combines three foundational layers:

1. Ephemeral Sandboxing: Spin up disposable containers for every trajectory. Each test run must receive an isolated filesystem, mock service layer, and Model Context Protocol (MCP) server instance that are wiped upon teardown, preventing cross-test contamination.
2. Hybrid Verification: Pair deterministic unit tests against environmental side effects with trajectory constraint tracking (n_turns, n_toolcalls, token budgets). Use targeted LLM-as-a-judge rubrics sparingly—only to audit conversational nuance or ambiguous boundary cases where deterministic checks are insufficient.
3. A Two-Tiered CI Pipeline: Separate rapid development feedback from long-horizon benchmark verification.

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent showed empathy for customer's frustration"
      - "Resolution was clearly explained"
      - "Agent's response grounded in fetch_policy tool results"
  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed}
  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: process_refund, params: {amount: "<=100"}}
      - {tool: send_confirmation}
  - type: transcript
    max_turns: 10
tracked_metrics:
  - type: transcript
    metrics:
      - n_turns
      - n_toolcalls
      - n_total_tokens
  - type: latency
    metrics:
      - time_to_first_token
      - output_tokens_per_sec
      - time_to_last_token

On pull requests, deploy a shallow tier: run deterministic 2- to 3-turn workflow smoke tests asserting basic tool parameter formatting, schema compliance, and quick side-effect changes. Keep execution times under three minutes. Reserve deep, multi-turn suites—such as full $\tau^2$-bench interactive user simulations or long-horizon SWE-bench style repo debugging—for nightly or release pipelines. Running unconstrained open loops on every merge commit burns thousands of dollars while blocking developer velocity on flaky edge-case failures.

Most importantly, recognize the boundary of where agent evals make economic sense. When orchestrating systems, simpler deterministic workflows must always precede autonomous multi-turn loops when verification overhead outpaces the autonomy's payoff. If your team spends more time writing hermetic container lifecycle managers, synthetic policy simulators, and trajectory forensic graders than you would spend writing deterministic conditional code with retrieval, you have chosen the wrong abstraction.

Resources

• Demystifying evals for AI agents \ Anthropic
• Building effective AI agents \ Anthropic
• modelcontextprotocol.io