How it works
An agent handoff turns an informal change of worker into an explicit protocol. The sending agent does not merely forward its transcript. It produces a bounded handoff package that tells the receiving agent what the task is, what has happened, what remains uncertain, and what actions are permitted next.
A reliable handoff usually follows a short sequence:
- Freeze a checkpoint. Record the authoritative task state, completed actions, pending work, and any operations with unknown outcomes.
- Assemble the minimum sufficient context. Include requirements, decisions, relevant evidence, artifact references, and constraints. Separate verified facts from hypotheses and model-generated interpretation.
- Declare authority. State which tools, credentials, resources, and mutations the receiver may use. Authority should be granted independently of context transfer.
- Define the continuation contract. Specify the expected output, acceptance checks, stop conditions, budget, and escalation path.
- Transfer and acknowledge. The receiver validates that required fields and referenced artifacts exist before accepting ownership.
- Commit ownership. The orchestrator records which agent is now responsible and prevents both agents from writing the same state concurrently.
The handoff should be durable enough to inspect or replay. A transcript can support that record, but it is not the record itself. Conversations contain stale plans, abandoned branches, untrusted tool output, and instructions that may no longer apply. The handoff package is a deliberate state transition extracted from that history.
Why it matters in an agent harness
A handoff is where local uncertainty becomes system uncertainty. One agent may understand why a decision was made, which source supports it, or whether a tool call completed. Unless the harness preserves those distinctions, the next agent must infer them. That inference can produce duplicate writes, unsupported claims, permission expansion, and false completion.
The first engineering outcome is continuity. The receiving agent can resume from a named checkpoint instead of reconstructing the task from an arbitrary slice of conversation. This reduces repeated work while making intentional retries possible. If an earlier operation has an unknown outcome, the receiver can reconcile it before acting rather than assuming failure and issuing the mutation again.
The second outcome is containment. Context and authority are different things. An agent may need to know that a deployment failed without receiving deployment credentials. A handoff boundary gives the harness a place to narrow permissions, replace credentials, reduce tool access, or require approval before the next phase. Passing a token or inherited session simply because it is convenient collapses that boundary.
The third outcome is observability. A structured record lets operators answer concrete questions: who owned the task, what evidence crossed the boundary, which permissions were granted, what the receiver accepted, and where the trajectory diverged. Those records also support evaluation. A harness can test whether agents preserve constraints, identify unresolved risks, and avoid treating generated summaries as authoritative facts.
Finally, explicit handoffs improve failure isolation. If the receiver rejects an incomplete package, the failure stays at the boundary. If it accepts the work, the orchestrator can retire the sender, preserve single-writer ownership, and continue from a known state. Without that commit point, two agents may act on different versions of the task while both appear successful.
Agent handoff vs AI delegation
Delegation decides that another agent should perform work. A handoff controls how responsibility and state move once that decision has been made. The distinction changes where the harness needs checks.
| Design question | AI delegation | Agent handoff |
|---|---|---|
| Primary concern | Who should do the work | What must cross the boundary |
| Typical inputs | Goal, role, capability, budget | Checkpoint, evidence, authority, unresolved state |
| Main control | Assignment policy | Transfer and acceptance protocol |
| Common failure | Assigning work to an unsuitable agent | Losing constraints, provenance, or ownership |
| Completion signal | Work has been assigned | The receiver has validated and accepted responsibility |
A delegation can occur without transferring ownership. An orchestrator may ask a specialist for analysis while retaining the authoritative workflow state. Conversely, a true handoff changes the responsible writer or executor. Treating every consultation as a handoff adds coordination cost. Treating every ownership change as ordinary delegation leaves critical state implicit.
The Rifty take
We treat handoffs as typed control boundaries, not prompt-writing conveniences. We optimize for a smaller, inspectable transfer with explicit provenance and authority, even when preserving that structure costs more orchestration work. If the receiver cannot validate the package or the current owner, the handoff should fail closed rather than continue by inference.
Common failure modes
- Passing the full transcript and expecting the receiver to discover the current plan.
- Summarizing evidence without retaining source identifiers or artifact references.
- Transferring credentials, sessions, or tool permissions implicitly with task context.
- Omitting completed mutations or operations whose outcomes remain unknown.
- Allowing sender and receiver to write authoritative state during the same ownership window.
- Treating receiver startup as acceptance without validating required fields and artifacts.
- Losing approval requirements, execution budgets, or stop conditions during context compaction.
- Copying untrusted tool output into the handoff as if it were an instruction.
- Retrying a rejected handoff without recording why it failed or what changed.
- Measuring only final output quality while ignoring duplicated actions, permission violations, and trajectory drift.
Frequently asked questions
What information should an agent handoff contain?
An agent handoff should contain the current goal, authoritative workflow state, completed and pending actions, unresolved or unknown outcomes, relevant evidence with provenance, granted authority, output requirements, budgets, stop conditions, and acceptance checks. It should reference durable artifacts rather than embedding an undifferentiated transcript.
Should an agent handoff include the full conversation history?
Usually no. The receiver needs the minimum sufficient context plus access to inspect supporting history when necessary. Full transcripts mix active requirements with stale plans, failed approaches, and untrusted content. A structured package should identify authoritative decisions while preserving references to the underlying trace for audit and recovery.
How should a harness handle a rejected handoff?
The existing owner should remain authoritative until the transfer can be corrected or escalated. The harness should record the rejection reason, preserve the checkpoint, and avoid granting mutation authority to the receiver. A retry should create a new, inspectable transfer attempt rather than silently modifying the rejected record.
How can duplicate work be prevented during a handoff?
Use an explicit ownership commit, a single authoritative state writer, durable operation identifiers, and idempotent mutations where possible. The receiver should reconcile actions marked complete or unknown before retrying them. Starting the receiver before retiring or restricting the sender creates an avoidable split-brain execution window.
How should agent handoffs be evaluated?
Evaluate both package quality and subsequent trajectory. Tests should check whether constraints, evidence provenance, unresolved risks, permissions, budgets, and stop conditions survive the transfer. Recovery tests should also inject missing fields, stale checkpoints, unavailable artifacts, and unknown operation outcomes to confirm that unsafe handoffs are rejected.