When an AI agent hands work off, keep one owner responsible for the unfinished request until the next owner explicitly accepts it. Sending a message proves dispatch. It does not prove that the recipient started, understood the remaining work or agreed to verify the final result.
This is a proposed operating protocol for agent builders. It separates acknowledgment from completion and makes abandoned work visible. The aim is simple: the user should not have to discover that two agents each believed the other would finish.
- 01Name the remaining task.Transfer an artifact and its acceptance rule, not just a conversation summary.
- 02Keep ownership during transit.The sender remains responsible until the receiving owner accepts the handoff.
- 03Verify the final result.A worker’s completion message is evidence to inspect, not an automatic close signal.
01 — Use explicit handoff statesUse explicit handoff states
The states below are a design recommendation, not terminology mandated by a protocol. An owner may be an orchestrator, a human or another agent. Responsibility means tracking the task and resolving gaps; it does not grant additional tool permissions.
| State | Evidence required | Owner’s next responsibility |
|---|---|---|
| Prepared | Artifact revision and remaining work recorded | Sender checks that the handoff is understandable |
| Dispatched | Message or task reference exists | Sender tracks delivery; ownership has not transferred |
| Accepted | Recipient confirms the specific remaining task | Recipient owns the accepted scope; sender records transfer |
| Working | Progress tied to that task and artifact | Recipient preserves changes and reports blockers |
| Blocked | Specific unresolved dependency or decision | Current owner routes the blocker without declaring completion |
| Returned | Result and verification evidence supplied | Receiving reviewer checks the acceptance rule |
| Closed | Result accepted or scope explicitly ended | Final owner records the outcome and any residual limitations |
02 — Package enough context to continuePackage enough context to continue
A handoff should name the user’s intended outcome, the current artifact and revision, what is complete, what remains, the acceptance rule and any actions that still need authorization. Include the evidence already collected and the gaps that could change the next step.
Separate observations from assumptions. “The build passed on this revision” is more useful than “the code is good.” “Recipient access remains unverified” is more useful than silently omitting the access check.
Anthropic’s harness report describes progress notes and version history that help later coding sessions recover state. We apply that continuity idea to handoffs, while adding an explicit ownership rule of our own.
03 — Transfer a fix to review without losing the releaseTransfer a fix to review without losing the release
In an illustrative coding workflow, a worker prepares a fix and reports the reproduction result. The reviewer accepts the task of checking the patch. That does not mean the reviewer accepted deployment responsibility. The handoff needs to say who will release the change if review succeeds.
Record the accepted revision. If the worker changes the patch while review is underway, the earlier verification may no longer apply. The next owner should inspect the updated scope and decide which checks need repeating.
The bug-report evidence guide defines the original acceptance behavior. Keep that requirement in the handoff so a reviewer does not replace it with a general code-style assessment.
04 — Handle missing acknowledgment and partial returnsHandle missing acknowledgment and partial returns
Until acknowledgment arrives, the sender tracks the transfer and selects an authorized fallback if needed. Preserve the delivery reference so the next attempt does not duplicate work.
If the recipient returns only part of the work, preserve the useful result and assign the remaining scope explicitly. Reassigning a task also requires understanding whether the earlier worker is still acting, especially when both can write to the same destination.
Use the background-work stop checks before replacing an active worker. The tool-error reference covers responses where success is partial or unknown.
05 — Close against the outcome and keep attributionClose against the outcome and keep attribution
At closure, inspect the result against the acceptance rule and retain the relevant evidence reference. A reviewer can accept a scoped result with disclosed limitations, but a missing required check should remain visible.
Avoid using ownership as a reason to duplicate execution. One owner tracks the result; several people or agents may contribute separate checks. The distinction keeps accountability clear without forcing all work into one process.
06 — DecisionWhat to do next
Transfer responsibility explicitly and close on evidence.
Give each unfinished request a current owner, a concrete next action and an acceptance rule. A handoff is successful when the next owner can continue and the original request still has a path to completion.
For implementation support, explore our AI transformation services.