A Complete Handoff and a Correct One
The task arrives intact. The receiver reads it, acts sensibly, and returns something well-formed and wrong. Nothing was dropped in transit — what never travelled was the set of conditions that made the task correct in the first place.
A handoff can be complete and still be wrong. The task arrived; the authority, constraints, and decision basis did not — so the receiver did something reasonable, and reasonable was wrong.
The failure does not look like a failure
Something is handed to an agent, or from an agent to a person. The task is stated clearly. It is received correctly. Work happens, and what comes back is well-formed, on topic, and wrong.
The instinct is to call this a quality problem. It usually is not. Nothing was dropped in transit — the task travelled exactly as written. What stayed behind were the conditions that made the task correct.
Those conditions are rarely written anywhere. They live in the head of whoever set the work up: what this is actually for, what was already ruled out, which parts are settled and which are still open, what must not happen, and who would answer for the result. A person receiving the same task would surface most of that by asking. A system does not ask, because it has no way to know there was something to ask about.
Complete is not the same as correct
Completeness is a property of transmission: did the message arrive intact? Correctness is a property of the handoff: did enough arrive that acting on it is the right thing to do?
The two come apart most sharply at an ambiguity. A receiver that hits an unclear point has to resolve it somehow, and resolving it sensibly is what a competent receiver does. That is precisely the moment the missing conditions would have mattered — and their absence is invisible, because a confident reasonable answer looks exactly like a correct one.
What tends to have to travel
We run work across several agents daily, and over time we have written down what a handoff has to carry before it is safe to act on. It is a short list, and it is ours rather than a standard:
- the task itself;
- what it is for;
- the source it rests on — or, where there is no retrievable source, the facts stated plainly enough that the receiver needs nothing else;
- the constraints, including what must not happen;
- who decided, where that matters;
- what remains unresolved;
- and an explicit stop: if the basis for a claim cannot be established, say so and halt, rather than proceed on something that merely looks authoritative.
That last one does the most work. A handoff that cannot say where its authority comes from is more dangerous than one that admits it does not know, because the first invites confident action and the second invites a question.
This is not a schema, a standard, or a platform. It is what one working arrangement needs, written down. Not every handoff needs every item, most need very few, and a list like this becomes bureaucracy the moment it is applied where nothing was at stake.
What this is not
- Not memory. Memory is about what a system can recall. This is about what a task carries when it changes hands.
- Not observability. Traces, spans and logs reconstruct what happened. That is useful, and it is a different job: reconstruction happens after the fact, and a record of a step does not carry a constraint forward to the step that needed it.
- Not an audit, an assessment, or a diagnosis of anyone's system. This page explains a failure shape. It does not inspect, monitor, manage, repair or govern the arrangement you are running, and reading it starts nothing.
What the research does and does not say
The most substantial published work on multi-agent failure is a taxonomy built from expert annotation of execution traces across several open-source frameworks. It is worth being precise about it, because it is widely cited loosely.
It does not find that context loss dominates — context loss is one of its smaller categories. What it does find is that the largest classes of failure are specification issues and inter-agent misalignment: agents proceeding on wrong assumptions rather than seeking clarification, failing to follow stated requirements, and acting in ways that do not match their own stated reasoning. Its own improvement evidence comes from writing better specifications, not from watching runs more closely.
That is convergent with what we observe. It is not proof of anything we do — it is a different group, studying different systems, finding that under-specification is where the failures concentrate.
The question worth asking
Before handing work to a system that will not ask you a clarifying question: could a competent receiver read this, do something entirely reasonable, and still have done the wrong thing?
If the answer is no, hand it over. If the answer is yes, the thing that would make it wrong is the thing that has to travel with it.
Why these get confused
Both look identical at the moment of handing over. The task is stated, the receiver acknowledges it, work begins. The difference does not surface until the work comes back — and by then it looks like a quality problem rather than a handoff problem, because the thing that was missing was never written down anywhere to be missed.
Side by side
| A complete handoff | A correct handoff | |
|---|---|---|
| What arrives | The task. Clearly stated, correctly transmitted, understood as written. | The task, plus the conditions under which doing it is the right thing to do. |
| Who decided, and why | Absent. The instruction stands alone, and the reasoning that produced it stayed behind. | Travels with the task, so the receiver can tell a constraint from a preference. |
| What the receiver may not do | Unstated. Permissions are implied by the task; the edges are not drawn. | Stated, because the boundary is the part that cannot be inferred from the request. |
| What happens at an ambiguity | The receiver resolves it — sensibly, invisibly, and sometimes wrongly. | The receiver has somewhere to stop, because the handoff said what is unresolved. |
| How the failure appears | As a bad output, attributed to the receiver's judgment. | It usually does not, which is why the difference is easy to underrate. |
Which one applies
- A complete handoff — the task is small, reversible, and any reasonable reading of it is acceptable.
- A correct handoff — a reasonable reading of the task could still be the wrong thing to have done.
FAQ
- Isn't this just a context window problem?
- Usually not, and the common fix points the wrong way. Passing more — the whole prior transcript, the full history — frequently makes it worse, because the receiver now has access to material that was superseded, rejected, or true only under conditions that have changed, with nothing marking which is which. Volume is not the variable. What matters is whether the conditions governing the task travelled in a form the receiver can act on.
- Wouldn't better logging catch this?
- Logging catches it afterwards, which is worth having and is a different job. A trace records that a step happened and what it produced; it does not carry a constraint forward to the step that needed it. The handoff either includes the conditions or it does not, and that is decided before the work starts, not after it fails.
- Does this mean every handoff needs a formal contract?
- No. Most handoffs are small and reversible and any sensible reading of them is fine. The question worth asking is narrower: could a competent receiver do something reasonable here that turns out to be wrong? If yes, the conditions that make it wrong are the ones that have to travel.
- Is this specific to AI agents?
- The failure is older than agents — it is what a thin handover between two people has always produced. What changed is the rate. Systems accept work instantly, never ask for clarification they were not designed to ask for, and return something plausible, so an under-specified handoff produces confident output rather than a puzzled colleague asking what you meant.