Who did it
Four agents touched the decision. One of them got it wrong. Establishing which is harder than it sounds.
Every step looked reasonable on its own.
The one that was wrong looked exactly like the three that were not.
In a multi-agent system, an output is the product of several steps and each step consumed the one before it. When the result is wrong, the failure is rarely in the last step — it is in an earlier one whose output looked reasonable. Attribution has to be designed in, because the intermediate states are gone by the time anybody asks.
A retrieval agent finds the documents. A summarising agent condenses them. A reasoning agent draws a conclusion. A drafting agent writes it up.
The output is wrong. Somebody asks which one caused it, and the honest answer is that nobody knows.
This is not a logging problem, though it is usually mistaken for one. The logs exist. What they contain is the input to each agent and its output, and both look reasonable in isolation. The summarising agent produced a fair summary of what it was given. The reasoning agent drew a defensible conclusion from that summary. The error entered when the retrieval agent returned a document set that was subtly incomplete, and nothing downstream could have known.
The intermediate states are the evidence, and they are gone. By the time anybody asks, the run has finished. What survives is the final output and whatever was logged at each boundary. What is not recoverable is why the retrieval agent chose those documents, what it ranked below them, and whether a different formulation of the query would have returned something else.
An agent that cannot say why it chose what it chose has not been built to be questioned.
What makes it possible
Three things make attribution possible, and all three are design decisions taken before the system runs.
Every agent records its own reasoning, not just its output. What it considered, what it rejected, and on what basis. This is more expensive than logging the boundary and it is the only thing that makes the middle of a chain examinable.
Every artefact carries the identity of what produced it. Not a timestamp — the agent, its version, its configuration, and the run it belonged to. A document that arrives at the reasoning step should be traceable to the retrieval that found it.
The chain is reconstructable in full from the record alone. The test is whether somebody can replay the whole sequence six months later without access to the running system. If reconstruction requires the system to still be there, the record is a debugging aid rather than an audit trail.
- The failure is rarely in the last step, and the last step is where everybody looks first
- Boundary logging shows what each agent received and returned, and both look correct
- Attribution has to be designed in, because intermediate states cannot be recovered
- The test is whether the chain can be replayed without the running system
This describes agent systems we have built and reviewed in production. It is engagement observation rather than a study, and it says nothing about systems where a wrong output costs nothing — those may fail somewhere else entirely.
Limits
Engagement observation, not a study
Drawn from agent systems we have built or been called into, which selects for systems where somebody already suspected a problem.
It describes chains, not single agents
The attribution problem starts when one agent consumes another's output without a human in between. A single agent with a human reviewing its output has a different and simpler failure mode.
It says nothing about low-consequence settings
Where a wrong output costs nothing, the expense of designing attribution in may not be worth it. This describes systems where somebody eventually has to answer for the result.
Questions
Is this not solved by observability tooling?
Observability shows you what happened at each boundary. It does not show you why an agent chose what it chose, and that is where multi-agent failures live.
Can we add this to an existing system?
Partly. You can add identity and versioning to artefacts retrospectively. You cannot recover the reasoning of runs that have already happened, and those are usually the ones somebody is asking about.
Does this apply with two agents?
Less sharply, because there are fewer places for the error to hide. It applies from the moment one agent consumes another's output without a human in between.
What if the agents are from different vendors?
Then the record has to be yours rather than theirs, held outside any of the systems producing it. Vendor logs are built for vendor debugging and they are not designed to be joined.
How much does this cost to build?
A day or two of engineering specified at the start. Considerably more retrofitted, and the runs that already happened stay unrecoverable.
Is a human in the loop enough?
It helps at the boundary they sit on and it does not help upstream. A reviewer accepting a conclusion cannot see that the retrieval three steps back was incomplete.
Govil, A. (2026). Who did it. The Field Report, XONIK.