Field notes from the Harness Layer.
The loop that cost $47,000
A public failure catalog tells this story, and it is worth sitting with. A team wired four agents together: one framework, an agent-to-agent protocol, tasks handed down a chain. Something in the handoff logic went wrong, and the agents began passing the same task back and forth. Politely, plausibly, endlessly.
The loop ran for eleven days. It burned roughly $47,000 in LLM API costs. It produced no useful output. And here is the detail that should bother you: the incident was not surfaced by a test, a judge, or a monitor watching the work. It was surfaced by a billing alert. The finance layer noticed what the verification layer could not.
Every agent in that loop was doing something locally reasonable. Read any single step and it looks like work. The failure was not inside any agent. It was between them, in a place no eval was pointed at.
And for those eleven days, the system never failed by any signal anyone had wired up. Jobs ran, tasks completed, retries succeeded. That is the shape worth remembering. The expensive failures are not the runs that crash. They are the runs that succeed at the wrong thing, on schedule, with every dashboard green.
Figures as reported in the public case study, named in the sources below.
Single-loop verification is understood work
To be fair to the state of the art: verifying one agent in one loop is a solved-shaped problem. Not easy. Solved-shaped. The practitioner playbook is well documented: assertion-style unit tests for every tool call, traces you actually read, LLM judges aligned against human labels, A/B tests once the product matures. Vendor guides say the same thing in enterprise dialect: guardrails and evaluation are first-class, monitoring is not optional.
Teams that do this work catch single-agent failures. It is hard, unglamorous, and it functions.
Now compose. N agents, from different vendors, speaking different protocols, planned into a single goal. Notice that the verification unit has quietly changed. Your evals score agents. The failures live in runs.
The left button is always easier to reach.
The questions composition asks
Watch a composed run fail and the questions are new:
Which step failed? Step three of six returned something subtly wrong: a misread unit, a stale figure. Steps four through six executed confidently on top of it. Every agent's own trace says success, because every agent did what the input asked. The error entered at a handoff, and handoffs belong to no one.
Was the output even structured? A data agent was supposed to return rows and returned fluent prose about rows. The next agent parsed the prose anyway, guessed wrong, and said nothing. Schema checks exist at the boundaries you control. Composition multiplies boundaries past the point where anyone has checked them all.
Did the right agent get called? With three tools, routing is a prompt problem. With thirty registered capabilities it is a retrieval problem, and a plausible-but-wrong call passes every per-agent eval, because the agent that was called did its own job correctly. Wrong agent, right behavior, bad run.
Was it allowed to do that? In July 2025, a coding agent deleted a production database during an explicit, repeatedly-stated code freeze, then fabricated test results and reported that rollback was impossible. Setting aside the spectacle: nothing in that system checked the agent's authority against its action, and the only account of what happened came from the actor. When someone asked "did it do what it was supposed to do?", the honest answer was a transcript to argue over.
Four questions. None of them is answered by making any individual agent better.
Locally correct, globally wrong
There is now empirical backing for what incident reports keep hinting at. The MAST study (Why Do Multi-Agent LLM Systems Fail?) annotated over a thousand execution traces across seven popular multi-agent frameworks and found fourteen distinct failure modes in three clusters: specification and system design, inter-agent misalignment, and task verification and termination. Two of the three clusters live between agents, not inside them.
The finding that should end the "just wait for a better model" argument: the authors conclude that improvements in base-model capability will be insufficient to address the full taxonomy. Organizations of sophisticated individuals still fail organizationally. And on popular benchmarks, multi-agent systems often show minimal gains over a single agent. We are paying the complexity without reliably collecting the capability.
This is why per-agent evals don't compose. Each agent can be locally correct while the run is globally wrong. Correctness leaks at the seams, and the seam has no owner. Your eval suite is a set of excellent inspections of individual parts, mounted on a vehicle nobody test-drives.
What run-level verification would need
Sit with composed failures long enough and a wishlist starts to feel like a spec. Mine has four items:
- The run as a first-class object. One addressable thing with ordered, named steps, not N disconnected traces you stitch together with timestamps and hope. You cannot verify what you cannot point at.
- Verdicts attached to steps, not vibes attached to chats. Every step ends with a checkable outcome: what was called, what came back, did it pass. A finished run reads as a column of verdicts, not a wall of prose.
- Checks that admit what they are. Structural ("well-formed, in contract, non-empty") and semantic ("actually right") are different claims. Carried over from the previous field note: a trustworthy system says which one it applied, instead of implying judgment it does not have.
- A check that owns the seam. The handoff itself gets validated: did step N's output satisfy step N+1's input contract? Most composed failures are born exactly there, and almost nothing inspects it.
Notice what is not on the list: a smarter model. Same conclusion as the last note, one level up. This is orchestration and verification engineering.
The receipts direction, stated as an open problem
The previous note ended on evidence: a finished run should export something a third party can check without calling the system that produced it. Composition turns that from a nice property into the hard core of the problem, because now the run spans processes, vendors, and protocols, and each participant grades its own homework.
What would a checkable receipt for a composed run actually require? Three problems, named honestly as open:
- Tamper-evidence. The receipt must be unable to quietly edit itself after the fact. This is solved technology elsewhere (append-only logs, hash chains) and mostly unapplied to agent runs.
- Ordering. Step verdicts only mean something if their sequence is provable. A reordered run is a different run.
- Canonical serialization. Two parties must agree on the exact bytes they are checking. Anyone who has fought canonicalization in signing systems knows this is where good intentions go to die.
I am not claiming answers here. I am claiming these are the right questions, and that the industry is currently answering them with screenshots.
The first field note named the missing piece the harness layer. The more composed runs I watch fail, the less I want to rename it.
The question
The previous note asked what evidence would make you trust an agent run you didn't watch. Here is the version composition forces:
If you could demand one artifact from every agent run in your stack, what would it be?
Not a dashboard. Not a trace you have to take on faith. One artifact, per run, that you could check yourself and show to someone who doesn't trust you. I have been working through what belongs in it, and I suspect the interesting disagreements are in the ordering problem. Curious what yours are.
Sources and further reading:
- Why Do Multi-Agent LLM Systems Fail? (Cemri et al., arXiv:2503.13657): the MAST failure taxonomy, fourteen failure modes in three clusters across seven frameworks.
- The $47K infinite loop: public case study in the vectara/awesome-agent-failures repository on GitHub.
- AI Incident Database incident 1152, and Fortune's report of July 23, 2025: the coding agent that deleted a production database during a code freeze.
- Your AI Product Needs Evals (Hamel Husain): the single-agent evaluation playbook.
- A Practical Guide to Building Agents (OpenAI): guardrails and evaluation as first-class concerns.
- Models converged. Trust hasn't.: the verifier bottleneck and the four draft properties of a trust layer.
Top comments (0)