AI Agent Testing Runs on Failure Traces

Agent tests should start from a failure under real traffic.

Teams want to re-run the exact failure in the trace to test the agent. A test case, not a screenshot, not a dashboard page, not a Slack thread of people agreeing to “watch it.”

That is where ai agent testing is heading. The useful unit of learning is no longer the benchmark score on Friday afternoon. It is the trace from a real run, turned into a verifier, owned by a team, and wired into the release path.

I don’t see the mysticalness fading much more from ai agent testing, but the interesting step in LangChain launching the Eval Engineering Skill is that the workflow now reads the repo, inspects the agent output, reads the traces, interviews the human who ran the task, and emits Harbor evals. The agent does not generate an opinion about quality. It generates a task the system can execute. The interesting part is that the agent is no longer only doing the work. It helps improve the engine that will run the next task.

I wrote this months ago: Traces collected from live agent behavior only become the basis for harness rewriting once an individual closes the loop from observed failure to change to the harness. This is fundamentally different from just trace storage, a pretty museum of weird agent behavior. Terrible for a test suite, nice for a touring show.

A score is a weak owner

Evaluations of agents have carried too much emotional weight. There is a simple number that a model score and a human score (a “judge” in the evaluation lingo) by definition get. Follow that up with a benchmark suite that scores by a few points here and there, and everyone pretends that that score corresponds in a simple manner to how an agent will actually behave under real traffic.

It does not.

Failures under real traffic have names: The agent picked the wrong tool. The retriever returned outdated policy text to the agent. Subagent mismeasured the error. Workflow failed to include required human in the loop. Agent attempted to write after a timeout and as a result duplicated side effect of the write.

An agent’s performance metric can improve in a benchmark setting while live traffic stays confusing. Conversely, a score does not say what broke. The trace says what is failing and why.

That distinction matters because ownership starts at the failure mode. LangChain’s IssueBench writeup, for instance, describes Engine processing batches of traces, then separating out the clean runs from the issue runs, and failing each of those into categories and attaching relevant traces to open issues or creating new issue cards for newly detected failures. In this way, the primary function of Engine’s input (traces) is turned into a usable stream of engineering work.

That is a healthier direction for agentic engineering. The artifact has to route. A hallucination, a silent tool error, a missing feature, and a bad recovery path belong to different owners. If the eval cannot preserve this, the team will be left with noise instead of work.

In Agent Failures Should Open Tickets, we wrote the ticketing version of this rule: recurring live-system failures ought to become owned work. In other words, trace + hypothesis + regression check. The new wrinkle is that the ticket should point at an executable eval opened by the failure.

The eval is a repo object

“eval” is still widely used to mean a spreadsheet (e.g. a balance sheet), a prompt (e.g. discussion prompt) a judge configuration (e.g. the evaluation configuration for a Harbor task). So all this feels pretty amorphous and soft.

A key distinction to keep in mind about Harbor artifacts is that they have boring form. The official Harbor task documentation describes a task directory with instruction.md, task.toml, a container environment, solution files, and tests. The core concepts documentation for Harbor says roughly the same thing: instruction, container environment, and test script.

An agent failure that matters should translate to something tangible: an instruction to reproduce the failure, the environment where it happened, the tools and constraints the agent had, a fixture or trace link, a verifier, and an owner who decides what change is allowed to make the test pass.

This is where the primary ai agent workflow conversation needs to get concrete and this is the concrete part: the soft path (agent runs, agent answers, team observes dashboard in a web UI) vs. the useful path (live trace turns into failure cluster turned into an owned issue turned into a Harbor eval turn into a harness change turn into a rerun turned into a release gate).

Benchmarks should change the harness

The Deep Agents team is treating benchmarks similarly. In How We Benchmark Deep Agents, LangChain describes moving toward end-to-end Harbor evals for longer running tasks, then using those results to inform harness tweaks like removing todo-list middleware or slimming down the system prompt.

That is the right level of abstraction. The eval exists so evaluation steers the harness instead of decorating a model leaderboard.

This is where “ai agent workflow automation” gets tricky to use as a term. Automation conjures up images of more things running automatically. But the reality is to automate the feedback loop (agent fails, get trace, eval fails, fix on main (patches to prompts, tools, routing, context, middleware, model choice, etc.) and then the build proves the fix stayed fixed).

Deep Agents is a useful example because the harness is the product surface. A todo-list middleware seems benign until evals show that it distracts newer models or burns context. A longer system prompt looks safe until benchmarks show that it crowds out task instructions. A verifier that only checks the final answer looks fine until the trace shows that the agent skipped the required tool.

The reason to keep running evaluation after the release is that the data used for pre-release evaluation catches what the team had remembered to encode. And the traces from live evaluation catch what users, tools, permissions, and weird state transitions do to the plan after it has hit reality. Annoying. The job.

Graphs help when the loop has state

But for testing, graph-shaped agent systems make the story easier to follow. LangChain’s graph engineering essay describes LangGraph as a mix of deterministic paths and agentic steps, with nodes for work and edges for what happens next. The LangGraph Graph API shows conditional edges routing from graph state and Send fanning out work only known at runtime.

That matters because agent failures happen across transitions. The agent performed the first step correctly, then retried the wrong thing. It found the right document and sent it to the wrong specialist. It asked for approval while a sibling branch kept writing. It recovered from a tool error by losing the original intent.

A flat final-answer eval fails to capture that. A trace-linked task can assert the transition the agent took, and the verifier can check the produced artifact, issue category, approval state, absence of side effect, or route shape. That is closer to how agentic AI workflows break under real traffic.

There are failures worth capturing in an eval artifact and failures that can wait. The rule of thumb is to capture failures that would cost customer trust, failures that recur from the same root cause, and failures that teams argue about after the fix. Everything else can probably stay in triage.

Approval is part of the workflow

GitHub’s new issue automation controls are a good adjacent signal to us. GitHub recently made a public preview available for agent automation in Issues. In this preview, the issue UI shows the rationale for label assignment, field assignment, issue type changes, closing, and assignment. Importantly, all of these approval panels, and associated automation, are merely workflow conveniences and do not map to any server-side security controls.

A release gate should test what the system enforces, not what the UI suggests. If an approval panel holds a label suggestion, test the suggestion path versus the agent directly applying the change. Test the permission boundary. Test the side-effect boundary when the workflow says rejection means zero side effects.

So, the release question is whether the trace, artifact, and verifier functioned properly under the same circumstances that previously failed.

This is why vibes are not an evaluation strategy. A person can like the demo. The dashboard looks great and the trend is up. The judge liked the final answer. The build still needs a particular failing case, and it must turn green when that failure mode is gone.

Own the loop

AI is simply another component in the larger engineering system. As Honeycomb’s CTO recently wrote in a letter to customers, AI amplifies the engineering system as it exists. Good practices get amplified. Bad practices get amplified. Engineering rigor matters more when AI enters delivery, not less.

A team with a healthy delivery system will turn traces into evals (because that is how the org already thinks, traces == evals). Failures create tests. Tests protect changes. Changes ship behind gates. Gates produce evidence.

A team without this muscle simply want a better dashboard. They’ll call out an interesting trace from time to time, rename a category here or there, add a sentence or two to a prompt. And of course the same failure will recur with a new name, dressed up in a new set of slides or a new Slack thread.

The engineering advantage is to treat every serious agent failure as a build opportunity. Mine the trace. Name the failure. Create the Harbor task. Assign an owner. Gate the release. Then use the release process to produce evidence that the fix held.

Then the agent workflow learns from real traffic instead of it being something it tries to survive.