Who Owns Unfinished Work When an AI Agent Hands It Off?

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, and the gap between those two facts is where multi-agent systems quietly lose tasks.

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. The sections below define the states, the context a handoff must carry, what to do when acknowledgment never arrives, the ways a transfer goes wrong, and how to close a task on evidence rather than on a message that says “done”.

A common shortcut in orchestration code is to treat a handoff as a single event: the sender posts a task, the task is now someone else’s problem. That model works when the recipient is a reliable queue with retries. It fails when the recipient is another agent that may be busy, may misread the request, may accept part of it, or may simply not be running. In each of those cases the sender has stopped tracking the work and nobody has started.

The fix is to treat a handoff as a short negotiation with a visible state at every step. The sender proposes a transfer; the recipient either accepts a named scope or does not; until acceptance arrives, the sender still owns the outcome. This costs one extra message in the common case. It saves the user from the uncommon case where a request disappears between two agents that each reported success.

Ownership here means one thing: the obligation to know the task’s current state and to act when it stalls. It is not execution. The owner may do none of the work. Several agents may contribute checks. But at any moment there is exactly one party whose job it is to notice that the task has not moved.

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. The middle column is the evidence that justifies moving into the state, which is what makes the state inspectable after the fact rather than a label the agent assigned itself.

The two transitions that matter most are Dispatched to Accepted and Returned to Closed. The first is where ownership actually moves; the second is where the user’s outcome is actually established. Every other state exists to make those two honest.

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. The test is whether the recipient can start without reading the conversation that produced the handoff; if it has to, the summary was the conversation, not a handoff.

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. An assumption written down can be checked by the next owner; an assumption folded into a confident sentence is inherited as a fact.

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: the notes tell the next session what happened, and the ownership rule tells it whether the work is now its problem.

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, because the most natural reading of “review accepted” by each party is that the other one will.

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. A review that approved revision A and a release that shipped revision B are two different events that one optimistic status line will merge.

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; a patch can be beautifully written and still not fix the bug the user reported.

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. A sender that re-dispatches without checking whether the first recipient quietly started has created the two-workers problem it was trying to avoid.

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.

Set the waiting period from the task, not from a default. For example, a review that normally takes an hour is late after two; a nightly batch is not late until morning. Whatever the period, the owner during it is the sender, and the sender’s job is to notice when it ends.

Each illustrative failure below is a transition that happened in one agent’s model of the world and not in the other’s. The protocol does not prevent them by being clever; it prevents them by requiring a recorded piece of evidence before either side may believe the state changed.

The optimistic sender: the orchestrator posts the task and marks it delegated. The recipient is at capacity and never reads it. The orchestrator’s dashboard shows green. The user waits. The eager recipient: the recipient starts work on the summary before confirming scope, solves a slightly different problem, and returns a result that passes its own checks and fails the user’s. The double-finisher: a re-dispatch after a timeout lands while the first recipient is still running, and both write to the same document, each overwriting the other’s half. The premature close: the recipient reports “done”, the orchestrator closes the task, and the artifact was never opened by anyone.

Map each one back to the table. The first is Dispatched mistaken for Accepted. The second is Accepted without a named scope. The third is a re-dispatch without the stop check. The fourth is Returned mistaken for Closed. The states are not bureaucracy; they are the names of the four mistakes.

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. Closing is a decision about the user’s outcome, made by whoever owns it at that moment, on evidence that someone other than the worker produced or inspected.

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, and it is the same separation our guide to independent review checks recommends for the checks themselves. Keep attribution in the record: who did the work, who reviewed it, who closed it. When something is wrong a week later, that record is the difference between a fix and an investigation. Teams designing orchestration with these states built in can work with our AI transformation practice.