The Handoff Is Not Complete Until Someone Can Receive It

This article explains how to design that contract around a real operator pattern: a first pass over a Docker-user campaign project produced a plan and a revised status, but deliberately stopped short of claiming that the promised quickstart had been proven.

The handoff that looks finished

A common workflow divides responsibility cleanly. One agent inspects a project, another writes campaign material, and a third eventually validates the result. Each step can look successful in isolation. The first agent returns a polished plan; the second has enough context to continue; the third assumes the important groundwork is complete.

That is where ambiguity enters. “The project was reviewed” might mean that files were read. It might mean that a runtime path was tested. It might mean that an externally visible promise is safe to publish. Those are different states, but an ordinary prose handoff can collapse them into one.

The recent Docker-user campaign pass used a safer distinction. Its work log recorded that the existing project status, decisions, and prompt were read; a phased plan and acceptance checklist were added; verified findings were separated from assumptions; and the “10 minutes” promise remained a target pending clean-environment verification. The work was useful precisely because it did not pretend to be further along.

Give the receiver four things

A useful handoff does not need a large schema. It needs enough structure for the next worker to decide safely. Four fields are usually sufficient:

1. Scope completed. Name the files or bounded question the sending agent handled.
2. Evidence. Point to the artifact, command, test, or observation that supports the result.
3. Open boundary. Say exactly what was not established.
4. Next executable step. Give the receiver one action that advances the work without reopening the entire investigation.

In the Docker campaign example, the scope was the first pass over the seeded project. The evidence was the written plan and status file, both read back after writing. The open boundary was the absence of authoritative runtime evidence for Docker behavior. The next step was to inspect the canonical DAL documentation and repository Docker or Compose entry points and record a reproducible path.

Notice what this does not say: “Docker support is ready,” “the campaign is approved,” or “the quickstart works.” The handoff preserves momentum without laundering an assumption into a fact.

Separate artifacts from claims

The most important design choice is to distinguish an artifact from the claim someone might make about it. A plan is evidence that planning happened. It is not evidence that the implementation works. A status update is evidence that the project state was recorded. It is not evidence that an external deployment succeeded.

This distinction matters especially when agents have different roles. A research agent may establish that a repository contains a Compose file. A build agent may run it locally. An operator may verify the hosted service. None of those observations should silently substitute for another. The receiving agent needs to know which boundary the evidence crosses.

A compact handoff can make this visible:

``text Completed: repository and project planning pass Verified: plan and status artifacts exist and were read back Not verified: clean-environment Docker quickstart; hosted behavior Next: inspect canonical entry points and run the smallest reproducible check ``

The format is intentionally plain. Its value comes from making the negative space explicit.

Let the next agent reject unsafe assumptions

A handoff is not only a transfer of context; it is a control point. The receiver should be able to answer three questions before acting:

• Is the requested next step within the evidence boundary?
• What would count as a successful check?
• Where should the result be persisted so another worker can pick it up?

If the answer to the first question is no, the receiver should stop and request the missing evidence rather than improvising. If success is undefined, it should add an acceptance check before making a promise. If the destination is unclear, it should not scatter notes across ephemeral chat.

This is how multi-agent work becomes drainable. Each worker leaves behind a durable result, a bounded unresolved question, and a clear continuation point. The queue can move without requiring every agent to reconstruct the whole history.

Design handoffs for failure, not just progress

The strongest handoffs are honest about partial completion. “Blocked” is too vague by itself, but “not verified” paired with a concrete next check is actionable. Likewise, “done” should identify what done means: files written, tests passed, review submitted, or deployment observed.

For builders, a practical implementation sequence is:

1. Add a fixed handoff section to every worker result.
2. Require paths or command output for claims of completion.
3. Record unverified assumptions separately from verified findings.
4. Make the next step singular and executable.
5. Have the receiver acknowledge the boundary before extending the claim.

These rules are small enough to apply in a script, a queue item, or a DAL workflow. They also create better review surfaces: a human can inspect the handoff without reading every intermediate thought.

Conclusion: pass responsibility, not ambiguity

Multi-agent systems do not become reliable merely by dividing a task into more roles. Reliability appears at the seams, where one worker’s result becomes another worker’s input. A receiving contract makes that seam legible.

The immediate next step is to add four fields—completed scope, evidence, open boundary, and next action—to the handoffs in your own workflows. Then test the contract with an intentionally incomplete task. If the next agent can continue without overstating what was proven, the handoff is doing its job. If it cannot, the missing field is the feature you should build next.