Your coding agent passes the happy-path demo, then opens the wrong file, retries the same tool call five times, or edits the right code with the wrong assumption. The usual response is to replay the bug manually, patch a prompt, and hope it never returns.
That does not scale. A better loop is to treat the trace from a failed run as the raw material for a regression test.
OpenAI’s current agent-evaluation guide makes the useful distinction: start with end-to-end traces while you are debugging workflow behavior, then turn the patterns you understand into repeatable datasets and eval runs. Anthropic describes a transcript or trace as the record of a trial, including tool calls and intermediate results. In other words, the failure already contains much of the test case you need.
This is especially useful for coding agents. A correct final diff can hide a bad route: an unnecessary destructive command, a missed test suite, a tool call made before gathering repository context, or a retry loop that makes the task too expensive.
The operating principle: test the route, not only the answer
For deterministic software, a unit test often asks whether a function returned the expected value. An agent needs that check and a trajectory check:
| Check | Question | Example failure |
|---|---|---|
| Outcome | Did it solve the task? | The requested test is still failing |
| Safety | Did it stay within its permissions? | It ran a write command outside the workspace |
| Route | Did it use sensible tools in a sensible sequence? | It edited before reading the relevant module |
| Efficiency | Did retries, tokens, or tool calls stay within a budget? | It searched the entire monorepo three times |
Do not demand one exact sequence for every task. There may be several valid paths. Instead, make the constraints match the risk:
- Strict for prohibited commands, required approval gates, and machine-verifiable checks.
- Flexible for equivalent read/search paths.
- Judged for whether the diagnosis and final explanation are useful.
That split mirrors the available evaluation methods. LangChain’s AgentEvals documentation distinguishes deterministic trajectory matching from an LLM-as-judge evaluator. Use deterministic checks when the tool policy is objective; reserve a judge for nuanced questions such as whether the agent’s diagnosis addressed the actual failure.
A 30-minute trace-to-regression loop
1. Capture enough context to reproduce the decision
When a run goes wrong, retain the task, repository revision, available tools and permissions, tool inputs and outputs, final diff, test result, latency, and cost. Redact credentials, customer data, and tokens before storing anything.
A trace is more valuable than a chat transcript alone because it exposes the decisions between prompt and diff. OpenAI defines a trace as the end-to-end record of model calls, tool calls, guardrails, and handoffs, and recommends trace grading to investigate workflow-level issues such as incorrect tool choice or policy violations.
2. Write the smallest stable expectation
Avoid freezing incidental wording or every intermediate thought. Encode what must remain true after the fix.
case: parser_handles_empty_config
input:
task: "Fix the crash when config is empty and add a regression test"
repo_ref: "fixtures/parser-empty-config"
policy:
forbidden_tools: ["shell:rm -rf *", "network:publish"]
required_evidence:
- "read:src/parser.ts"
- "test:pnpm test -- parser"
assertions:
- "tests.pass == true"
- "diff.touches.includes('src/parser.ts')"
- "tool_calls.count <= 12"
- "no_tool_call.matches(policy.forbidden_tools)"
This is intentionally a contract, not a replay. If the agent reads a nearby helper first, that can be fine. If it skips the parser and invents a fix, the case should fail.
3. Separate hard gates from quality review
Run fast code checks before any model-based grading:
hard gate: test command succeeds
hard gate: no prohibited command or path
hard gate: changed files stay in allowed scope
soft review: tool sequence was relevant
soft review: final explanation names the tested behavior
Hard gates are cheap, consistent, and easy to explain in a pull request. Soft review catches “technically green but operationally odd” behavior. Sample it at first instead of judging every production run, otherwise the evaluation bill can become another unobserved agent cost.
4. Promote real failures into a small, versioned suite
Keep cases next to the agent configuration, tagged by failure mode: wrong-tool, unsafe-write, missing-test, retry-loop, or bad-handoff. Add the trace only after removing sensitive data and shrinking it to the minimum reproduction.
Then run the suite when you change a prompt, model, tool schema, permissions, or routing logic. OpenAI recommends moving to datasets and eval runs when you need repeatability and want to compare prompt changes over time. That is the point at which an anecdotal incident becomes an engineering control.
5. Feed production failures back deliberately
Production is where new edge cases arrive, not where the test strategy ends. LangChain’s recent observability guidance describes the loop clearly: take a production trace, extract the state at the failure point, make a test case, fix it, and validate it. Anthropic likewise notes that evaluations complement, rather than replace, production monitoring and user research.
A lightweight weekly review is enough to start:
- Group failed runs by error signature or tool pattern.
- Select the two highest-impact recurring cases.
- Create or tighten one regression case for each.
- Compare pass rate, unsafe actions, tool calls, latency, and cost before and after the change.
- Delete obsolete cases only when the underlying product behavior has genuinely changed.
What to do now
- Turn on tracing for one non-production coding-agent workflow.
- Pick the most expensive or risky failure from the last week.
- Write one outcome assertion, one safety assertion, and one route or budget assertion.
- Add it to CI before changing the prompt or model.
- Review its trace when the evaluation fails, instead of patching blindly.
If you are working on more durable sessions or background agents, pair this with Claude Code’s July 14 fixes production checklist. If your agent uses external tools, the operational concerns overlap with MCP’s move toward remotely scalable servers. And if your safety policy is only a prompt today, consider the endpoint lesson in why coding agents can trigger EDR rules: observable behavior, not intent, is what your controls see.
When this approach does not fit
Do not block a small prototype on a giant evaluation platform. For a one-off internal script, a fixture plus a test command and a human approval step may be enough. Also, trajectory checks can become brittle if they enforce one preferred path instead of a real policy or outcome. Start with the few cases where a regression would cost real time, money, or trust.
Sources
- OpenAI: Evaluate agent workflows
- Anthropic: Demystifying evals for AI agents
- LangChain: Agent Evals
- LangChain: Agent observability powers agent evaluation
What is the first coding-agent failure you would promote into a regression test: an unsafe action, a bad tool choice, or a costly retry loop?
Top comments (0)