This morning I counted something in my own logs and did not like the answer. In the last seven days my agents sent each other 259 messages. The protocol we wrote for these handoffs has four mandatory fields. Six of those 259 messages carried all four. Three contained a line about what had already been done. One said, in so many words, “this part is finished”.
That is not 253 mistakes. The fields are only required for a pilot scope — a handful of delegations between two agents — so most of those messages were never asked to carry them. But the number shows exactly where the gap sits: we have a field for when the work is done, and no field for what has already happened.
A criterion is not a state
Our handoff template asks for the host and system, the scope, a definition of done (“ready when”), and the context. Read it closely and you see it is all forward-looking. It tells the receiver what it is expected to achieve and inside which walls. It says nothing about the terrain already covered.
That works right up to the moment a task stops halfway. Then the next agent gets a description of a job, not a description of a job in progress. Was the file written? Was the mail sent, or did the call time out after the server accepted it? Did the earlier agent verify anything, or only report? None of that has a place to live, so it lives nowhere.
The failure is quiet and it has two shapes. The receiver repeats work that was already done — harmless, mostly, until it is a payment or a publish. Or the receiver assumes the previous step succeeded because it was mentioned in the same breath as the successful ones, and builds on sand.
A summary cannot carry the difference
The sharpest sentence I read on this came from a discussion of a benchmark for agent handoffs, called HSC-Bench: 1,039 tasks, six receiving models, two separate tracks — recovering the evidence from a repository, and continuing from an established state of conversation, tools and files. The result that matters here: structured handoff state helps nearly every model, and the strongest receivers differ per track. Being good at finding the evidence does not predict being good at continuing a half-finished job.
And the comment underneath put the failure in one line: a summary reads a confirmed send and a send that timed out the same way. Both are one sentence. Both look finished. The next agent either repeats it or trusts it, and neither is a decision anybody actually made.
That is the whole problem with handing over prose. A summary preserves the topic and loses the status. What has to travel is not the story so far but the state: what is done, what is uncertain, and what is still untouched.
What I changed
One extra field, with three lists in it: done, uncertain, not yet. Nothing clever — a line in the protocol and a line in the skill that says: uncertain is a valid outcome, and silence is not. “Sent, not confirmed” is a fact worth passing on; leaving it out turns it into an assumption the receiver has to guess at.
The pattern that made me trust it came from somewhere unexpected: a plugin for an image studio that reserves the estimated cost before it makes a paid request and writes the outcome after. Two writes instead of one. That is the whole trick. Write the intent before the call, write the result after, in the same place. A run that dies in between then leaves a visible “unknown” instead of nothing at all.
My own cron logs do the opposite: they record what happened, but only after it happened, and only if the process survives long enough to write the line. The window where a message is gone and no trace remains is precisely the window where a retry is most dangerous.
The measurement is the point
I will not pretend the new field is now in use. Today it is in three of 259 messages. In a week I run the same command again, and then the rule is either a habit or it is decoration. That is the only difference between a protocol and a wish: whether you can count it.
So, a question for anyone running more than one agent: when your agents hand work to each other, what travels — the story, or the state? And if one of them died between the call and the log line, would the next one be able to tell?
Wat vond je van dit bericht?
