Agent handoff
carry the check, not the story

One card in our queue is two days overdue. Its title says the stop-loss refresh failed and the failure was swallowed. Behind it sit four more cards, all opened within five days, describing four different cross-sections of the same chain.

These five cards are not five incidents. They are one problem split into five parts.

The first, from 09-21, said the prices on execution cards are structurally invisible to automated monitoring, and six consecutive execution windows had already been missed. The one from 09-22 said two fields in the holdings table contradict the trade history. The one from 09-23 said the stop-loss model has had no fresh input since 08-26, so every position’s stop level had degraded into a number computed from the current price. The one from 09-24 said three silent failures in production data were all discovered by accident, one of them in risk control. Four cards, four owners, four repair paths.

Put them side by side and the repetition stops being invisible.

Put them side by side and the first reaction is that the same problem keeps getting diagnosed from scratch. The real question is why: Laid side by side, the first reaction is that the same problem keeps getting diagnosed from scratch. The useful question is why: the people picking these up are not careless and the tooling already exists. The repetition happens in the step where information moves from one owner to the next. Our judgement is that this rework is not caused by the receiver. It is caused by the payload. What gets handed over is a description, not a check.

One: the protocol defines the task, not the reason it closed

We run on A2A. A collaboration is defined as a Task object with a taskId and a contextId; its outputs are Artifacts built from Parts, which may be text, file references or structured data. The state machine has explicit terminal states: completed, failed, canceled, rejected. Long-running work reports back by push notification, and a client can retrieve status, artifacts and optionally history at any point.

The value of that design is that a task can be tracked, retrieved and replayed by the other side. What matters just as much is where it stops. The protocol does not require that the reason the previous attempt was closed travels with the task. The state machine belongs to the protocol; the acceptance condition belongs to the payload. What you buy with the protocol is traceability, not decidability.

Which means the protocol can tell you where a task currently sits, not why it was stopped the last time.

That sounds abstract until it lands on a single card. The next agent or engineer can look up what state the task is in. They cannot look up why it was closed last time, or what evidence that decision rested on. So they diagnose it again, from the beginning.

The result is the same either way. The receiver runs the diagnosis again.

Two: the three things a handoff drops

The first is the acceptance condition, the thing that decides whether the work counts as done. Without it, done degrades into looks fine to me, and that is a self-report. It cannot be re-checked, and it cannot be handed to a third person.

So looks done to me cannot travel; it lives in one person’s head at one moment.

The second is the previous owner’s conclusion. Whoever held the task before has usually already investigated once: what they found, what they ruled out, why they closed it. If that does not travel with the task, the next owner starts from the symptom list, and the symptom list is always longer than the root cause.

The third is the deadline and its owner. Who accepted it, when it is due, and who inherits it when it slips. In our own queue, all 11 overdue tasks carry an executable check command and the oldest has been sitting for seven days; six of them were marked high priority. What was missing was not a way to verify them. It was a person designated to finish them by a date.

None of this is a question of trust. The receiver has nothing usable on hand.

Once all three are gone, the receiver has exactly one option left: run the diagnosis again. Nothing here is a question of trust. There is simply nothing on hand that could be trusted.

The three things also fail in an order. The acceptance condition goes first, because it reads like the most redundant sentence in the payload. The previous conclusion goes next, because the person who would write it is already preparing to leave. The deadline and its owner go last, and once the first two are gone the task is a title in a system that nobody has claimed. Our five cards are sitting on the third step.

Three: why a description always loses the check

A description is complete when a reader understands it. A check is complete when it runs. The two standards look adjacent and are not, because the difference is whether something can be omitted. Drop a boundary condition from a paragraph and it still reads as complete; the author will not feel a gap. Drop one condition from a check and it produces the wrong answer immediately, for anyone who runs it.

In other words, the difference is not strictness. It is what can be omitted.

So when a payload degrades into prose, what falls out first are exactly the conditions that only exist to make the text longer: whether the input is fresh, where the value came from, whether a failure counts as a pass. Those conditions are the whole of the judgement. The smoother the prose, the cleaner the loss, because smoothness asks for the conditional clauses to be cut.

This can also be solved at the process level, by requiring a retrospective every time a task is closed. Whether that works depends on who does the checking, and the supply of checking is always smaller than the supply of tasks. Writing the same requirement as a field moves the dependency onto the database, which does not look away. The difference between the two is not strictness. It is the supply of inspection.

That is why a smooth handover note so often loses conditions: the smoothness is what removed them.

The mechanism is testable. If it holds, the same root cause should resurface as newly opened tasks, each starting from a symptom. The week we just had is that prediction being read off the instrument: five cards on one chain, a few of them mentioning an earlier card’s identifier in passing, none of them carrying the earlier conclusion in a required position.

Four: two numbers from our own queue

We treated our own task queue as the sample. Read at 08:00 on 2026-09-28: of 50 open tasks, 32 carried an acceptance standard and 31 carried an executable check command. In plain terms, roughly four in ten tasks were handed over with nobody able to say, without reconstructing context, whether they were finished.

These numbers matter for direction, not magnitude.

Those numbers come from our own queue, not from a survey, and the sample is too small to quote as a benchmark. What they are good for is direction. Field coverage is something you can push upward week by week, and the lever is not asking people to be more careful. The lever is making the fields mandatory.

Five: our judgement

Whether a handoff is decidable is decided by the fields in the payload, not by the competence of the receiver. Treating understanding as a default capability of the next owner pushes the cost of rebuilding context onto them, and that cost never appears on a timesheet.

Between people, the missing field shows up as rework, and the two sides can still ask each other questions. Between agents there is no question to ask. The receiver executes literally: a condition you left out is not filled in for you, it just is not there, and a run completes with a plausible-looking result. That is also why we treat the payload schema as the first asset of a multi-agent system and the orchestration console as the second.

Using our own queue as the sample has an obvious limitation: it is a single sample, and the business it runs happens to be ours, so the numbers indicate a direction rather than a general condition. The direction is the more reliable part, because field coverage is controllable and recomputable week by week without waiting for outside data.

So our ordering for an orchestration layer is blunt: settle the payload fields first, argue about the console later.

Six: compress the handoff payload into three required fields

Before any task moves, it should carry three things. An acceptance command: a check that runs and returns pass or fail. A previous-owner snapshot: why it was closed last time and where the evidence sits, as a link or a recomputable pointer. A deadline with an owner: who accepted it, when it is due, who inherits it on the slip.

That means handoff quality needs no new scoring system. It needs three fields marked required.

If only one can be added now, add the acceptance command. A task without one cannot be declared complete, no matter how well it was executed, so it survives only on human memory. Human memory is not a state machine.

Then track one metric: the re-created card rate, meaning the number of tasks opened in the last thirty days for a root cause that had already been closed. It is more honest than task volume, because volume counts activity while the re-created rate counts what was never actually resolved.

There are two common ways to write an acceptance command badly. The first is to write one that only runs on the author’s machine: it points at a local path, a script that was never committed, or an account only they hold, so the next person cannot run it and the command degrades back into a sentence. The second is to write one that passes too easily. In our own case the check asked whether a process was running, when what actually went wrong was never the process but the number it computed. The difference between a check that can only pass and no check at all is that the first one makes you feel safer.

Seven: what belongs in the snapshot

The snapshot is not a retrospective. It serves one purpose: the next owner should not have to investigate the same thing again. Three lines will do.

Line one is the conclusion, one sentence on why the task was closed: fixed, judged a false positive, or converted into another class of work. Line two is an evidence pointer that can be recomputed, a query, a line number in a log, a hash, rather than a screenshot in a chat thread. Line three is the hypotheses that were ruled out, and that line saves the most time, because the next owner’s first move is usually along the path you already walked and discarded.

In our own queue those three lines have no format and are not required, so a card will occasionally mention the previous card’s identifier. That is still prose, not a field. Whether it gets read depends on how much slack the next person has.

Put differently, the snapshot serves the next person, not the one who writes it.

Eight: when not to require these fields

So set the boundaries once, or the rule grows by itself.

The requirement carries a cost, so two boundaries are worth writing down, or it becomes a ceremony that only ever grows.

A once-only investigation does not need it. Something breaks, someone looks, someone fixes it, and the work ends without ever passing to a third person; three fields just make the path longer. Exploratory work whose conclusion cannot be recomputed does not need it either. When the point is to run twenty directions and see which one carries signal, demanding an acceptance command only forces someone to write a fake one. That kind of task needs a different payload: a budget ceiling, a stop condition, and one person who can call it off.

The other way round, whenever work will be picked up by a second person or opened a second time, the fields are cheap. The test is not the size of the task. It is whether the task comes back.

Nine: three questions for an orchestration vendor

First, which payload fields are mandatory when a task moves to the next executor? Ask for the schema, not a screenshot. The proof that a field is mandatory is that a task cannot be created without it.

Second, when a task is closed, where is the reason written, and can a machine read it? If the answer is a retrospective document, the next owner cannot reach it, because it does not sit on the task’s path.

Third, what are the overdue and escalation rules, and who is notified when they fire? This one asks whether the system can hand a problem onward by itself when nobody is watching.

All three questions come down to the same test: without it, does the system complain?

Ten: two things to do tomorrow

First, add two fields to the task objects you already have, an acceptance command and a previous-owner snapshot, and report the fill rate as a delivery metric every week. Second, pick the chain you depend on most and count how many tasks in the last thirty days were opened for a root cause that had already been closed, then count how many of them carried the previous conclusion in their payload.

The same way, recomputing that number once a week is enough. No live dashboard required.

The re-created rate is harder to count than it looks, and the definition has to be fixed in advance or it becomes a beautiful number that gets revised upward every year. We use four rules: a thirty-day window; clustering by root cause rather than by title, done by a person, once a week; only a genuine repeat of the same root cause inside the window counts in the numerator; and anything judged a different root cause gets the reason recorded in the snapshot. None of the four needs a new system. They need ten minutes a week.

That second number is closer to the truth than any maturity score. It needs no new system. It needs you to admit that the tasks arriving again and again were the same task.

Sources

Agent2Agent (A2A) Protocol Specification, v1.0.0, for the Task object, Artifacts and terminal states: a2a-protocol.org/latest/specification.

Queue readings (50 open tasks, 32 acceptance standards, 31 check commands, 11 overdue) come from the task queue we run, snapshotted around 08:00 on 2026-09-28. They are first-party operating data, not a survey, and should not be quoted as an industry benchmark.