AI Agent Handoff Patterns: How to Transfer Work Without Losing Context

An AI worker finishes its research and passes the task to another worker that can draft a customer response. The draft then goes to a human for approval. This sounds like a simple chain. In production, it is a transfer of responsibility, state, authority, and evidence. If any one of those is ambiguous, the next participant may repeat work, act on stale facts, or assume somebody else owns the result.

A reliable handoff is not “here is the conversation so far.” It is a compact contract: what has been done, what remains, what the receiver may do, how success will be judged, and what should happen when the receiver cannot continue.

This guide explains six practical handoff patterns, a standard handoff envelope, acceptance and rejection rules, and metrics that expose weak seams before they become customer-facing failures.

What an AI agent handoff actually transfers

A handoff transfers five things at once:

1. Work: the specific next action, not the entire original goal.
2. State: verified facts, artifacts, decisions, and unresolved questions.
3. Control: which worker, workflow, or person now chooses the next step.
4. Authority: which tools and side effects the receiver is allowed to use.
5. Accountability: who owns the task until another explicit transfer succeeds.

Treating a handoff as a chat transcript usually fails. A transcript mixes evidence with speculation, buries the latest decision, and forces the receiver to reconstruct intent. It can be useful as a reference artifact, but it should not be the interface.

The interface should be structured enough to validate. The receiver should be able to answer, before doing work: Do I understand the assignment? Do I have the required inputs? Is it safe for me to proceed? What output must I return?

The handoff envelope

Use one small envelope for every transfer, whether it moves between two AI workers, a workflow and a worker, or a worker and a person.

{
  "handoff_id": "ho_20260828_1042",
  "task_id": "vendor_1847",
  "from": "intake-worker",
  "to_role": "risk-reviewer",
  "objective": "Assess vendor security evidence against the approved checklist",
  "completed": ["Legal name verified", "Questionnaire downloaded"],
  "artifacts": [{"id": "questionnaire_v3", "version": 3}],
  "facts": [{"claim": "SOC 2 report expires 2026-11-30", "source": "report p. 2"}],
  "open_questions": ["Is subprocessors list current?"],
  "constraints": ["Do not approve vendor", "Do not contact vendor"],
  "acceptance_criteria": ["Return pass, fail, or needs-human for each control"],
  "deadline": "2026-08-28T18:00:00Z",
  "on_failure": "Return to procurement-owner with blocker code",
  "idempotency_key": "vendor_1847-risk-v3"
}

The exact schema can differ. The important point is separation. Facts have provenance. Artifacts have stable identifiers and versions. Constraints are explicit. The next objective is smaller than the end-to-end business goal.

Do not copy secrets into the envelope. Pass references to credentials or protected records through an authorized mechanism. Do not claim a capability the receiving worker does not have. A good envelope reflects actual access, not intended access.

Pattern 1: Router to specialist

A router classifies an incoming request and transfers it to a specialist, such as billing, technical support, or security review.

Use it when: categories are reasonably stable and specialists have meaningfully different instructions, tools, or knowledge.

Contract: the router supplies the classification, confidence, evidence used for routing, requested outcome, and original user constraints. The specialist either accepts the category or rejects it with a reason.

Main risk: confident misrouting. If the specialist silently works outside its scope, the system hides the classification error.

Control: give the specialist a cheap reject path. For low confidence or overlapping categories, route to a generalist or a human queue. Track reroutes as a first-class outcome rather than treating them as noise.

The router should not solve half the case and then leave an unmarked mixture of conclusions and guesses. Its job is to frame the assignment and preserve the original request.

Pattern 2: Sequential stage handoff

One stage produces a defined artifact that becomes the next stage’s input. Examples include research to drafting, drafting to review, or extraction to reconciliation.

Use it when: work has an observable order and each stage has a testable output.

Contract: the sender identifies the artifact version, the checks already performed, the next stage’s acceptance criteria, and any known gaps.

Main risk: semantic drift. A research worker optimizes for a broad brief while the writer needs claim-level sources. Both stages can look successful while the final article is unsupported.

Control: design the boundary backward from the receiver. A research package for writing should expose quotable facts, URLs, dates, limitations, and which claims each source supports. Validate the output at the seam, not only at the end.

This pattern is strongest when deterministic checks can reject malformed artifacts before model judgment begins. Required fields, file existence, version match, and allowed status values are ordinary software checks.

Pattern 3: Parallel workers to a synthesizer

Several workers investigate independent dimensions, then a synthesizer combines their results. A procurement review might split security, legal, finance, and operations.

Use it when: branches are genuinely independent and parallelism saves meaningful time or adds diverse evidence.

Contract: every branch receives the same baseline context, a distinct question, a common output schema, and a cutoff time. The synthesizer receives each branch’s status, evidence, confidence, and unresolved conflicts.

Main risk: false consensus or invisible absence. Three workers may repeat the same source, while a timed-out fourth branch disappears from the summary.

Control: preserve branch identity and status. The synthesizer should distinguish agreement based on independent evidence from repetition based on a shared source. Missing, late, and rejected branches must remain visible. Conflicts should produce a decision request, not an averaged answer.

Set a join policy before execution: wait for all branches, proceed with a minimum set, or stop when a required branch fails. “Use whatever came back” is not a policy.

Pattern 4: Reviewer to reviser loop

A producer creates an output, a reviewer evaluates it against a rubric, and a reviser addresses specific defects.

Use it when: quality can be expressed as observable criteria and revision is cheaper than restarting.

Contract: the reviewer returns criterion-level findings, evidence, severity, and a bounded change request. The reviser returns a change log and a new artifact version.

Main risk: an endless loop driven by taste. Vague feedback such as “make it better” gives the reviser no stable target and can cause regressions.

Control: cap iterations, freeze already-passed criteria unless new evidence appears, and define the terminal states: pass, fail, or escalate. Review the artifact against the rubric, not the producer’s persuasive explanation of it.

A reviewer should not quietly rewrite the work unless that role is intentional. Evaluation and production are different responsibilities, and combining them can erase useful evidence about why the first output failed.

Pattern 5: AI worker to human decision owner

The worker prepares a decision packet, and a named person approves, rejects, edits, or requests more evidence.

Use it when: the next action is consequential, policy requires human authority, or ambiguity cannot be resolved safely.

Contract: the packet includes the proposed action, basis, affected resources, uncertainty, alternatives, deadline, and the exact consequence of approval.

Main risk: approval theater. A person sees a generic button without enough information, or approval is requested so often that review becomes automatic.

Control: trigger review according to risk and thresholds. Make the default timeout safe. Preserve who decided, what version they saw, and whether execution matched the approved proposal. For approval-policy design, use human-in-the-loop workflow approvals; this guide is about the transfer contract that gets a decision packet to the person.

The handoff ends only when the decision is recorded in a form the workflow can consume. A message in an unrelated channel may be visible to people but still leave the task technically ownerless.

Pattern 6: Exception return to an operator

A worker encounters missing data, conflicting evidence, unavailable tools, or a policy boundary and returns the task to an exception owner.

Use it when: continuing would require guessing, expanding authority, or repeating an unsafe action.

Contract: return a normalized blocker code, last confirmed state, attempted actions, side effects that may have occurred, required decision, and safe resume point.

Main risk: vague escalation. “It failed” forces the operator to reconstruct the run. Retrying without knowing whether a side effect committed can create duplicates.

Control: distinguish failed, timed out, and outcome unknown. Preserve the idempotency key and external reference IDs. The operator must know whether to retry, reconcile, compensate, or stop.

This is a handoff pattern, not a complete incident-recovery system. The handoff should carry enough recovery state to enter the established AI agent failure recovery playbook without inventing a new response process.

Acceptance makes the transfer real

A sender should retain ownership until the receiver accepts the task. Delivery is not acceptance.

A simple protocol has four states:

• Offered: envelope created and addressed.
• Accepted: receiver validated scope, inputs, capability, and deadline.
• Rejected: receiver returned a reason and suggested route, if known.
• Expired: no acceptance arrived before the lease ended, so ownership returned to the sender or exception owner.

This prevents the most common ownership gap: the sender marks work delegated while the receiver never starts it. For longer work, the receiver can renew a lease or emit a checkpoint. If the lease expires, another worker should not blindly replay the whole task. It should resume from a confirmed boundary.

Rejection is healthy when it is specific. Useful reason codes include missing_artifact, unsupported_action, scope_mismatch, stale_version, policy_gate, and capacity_timeout. Free text can add detail, but normalized codes make patterns measurable.

Context should be sufficient, not maximal

More context is not always safer. Large histories raise cost, hide instructions, propagate sensitive data, and make stale facts harder to spot.

Build the receiving context in layers:

1. Required now: objective, constraints, verified facts, current artifact, acceptance criteria.
2. Available by reference: source documents, transcript, prior versions, detailed logs.
3. Excluded: unrelated conversation, expired assumptions, credentials, and speculative internal reasoning.

Use timestamps and versions for facts that can change. Separate user-provided claims from independently verified facts. When two sources conflict, preserve the conflict instead of choosing whichever appears last in the conversation.

A receiver should never infer permission from the presence of information. Seeing a customer address does not authorize sending a message. Authority belongs in an explicit field and remains enforced by the destination system.

Test the seam, not just each worker

Individual workers can pass isolated evaluations while the overall workflow fails at transfer boundaries. Add handoff-specific tests:

• Remove a required artifact and confirm rejection.
• Send a stale version and confirm it cannot overwrite current work.
• Delay acceptance and confirm ownership returns safely.
• Deliver duplicate envelopes with the same idempotency key.
• Introduce conflicting branch findings and confirm the conflict remains visible.
• Strip the authority field and confirm no consequential action occurs.
• Simulate an outcome-unknown timeout after an external call.
• Confirm a human sees the exact proposal that execution will use.

Evaluate both happy paths and abstention. A worker that always accepts may look productive but is unsafe.

Metrics for handoff quality

Track the seam as an operational unit:

• Acceptance latency: offer to accepted or rejected.
• First-pass acceptance rate: transfers accepted without clarification.
• Reroute rate: tasks sent to another role after rejection.
• Context defect rate: missing, stale, conflicting, or inaccessible inputs.
• Rework rate: completed artifacts returned because the contract was misunderstood.
• Ownerless time: duration with no participant holding an active lease.
• Duplicate side-effect rate: repeated sends, writes, charges, or tickets.
• Escalation usefulness: exceptions resolved without reconstructing the full run.
• End-to-end outcome: whether the business result succeeded, not merely whether a handoff occurred.

Segment these by route and envelope version. An aggregate success rate can hide one fragile boundary.

How handoffs fit into Midpoint

In Midpoint, people and AI workers can coordinate through channels and tickets, use connected tools and computer interfaces, and turn repeatable work into workflows. A practical design gives each assignment a visible owner and next action. Tickets can preserve responsibility and status, while channels hold discussion and decisions. Workflows can carry structured inputs between repeatable steps. For system-level routing, concurrency, and coordination choices, start with the AI agent orchestration guide; this article focuses on making every individual transfer safe and observable.

The implementation rule is platform-independent: use deterministic routing and validation where rules are known, reserve model judgment for ambiguous work, and place explicit human control before consequential actions. Do not assume that passing text between participants also transfers credentials, approval, or accountability.

A handoff checklist

Before offering a handoff, confirm:

• The receiver role is appropriate and available.
• The next objective is specific and bounded.
• Required artifacts exist and versions are identified.
• Facts include provenance and freshness where relevant.
• Open questions and conflicts are visible.
• Authority and prohibited actions are explicit.
• Acceptance criteria describe an observable output.
• Failure, timeout, and rejection routes have owners.
• Duplicate delivery will not duplicate side effects.
• Sensitive context is referenced safely, not copied unnecessarily.

Before accepting, confirm:

• Scope matches the role.
• Inputs are sufficient and accessible.
• The requested action is authorized.
• The deadline is feasible.
• The return format and terminal states are clear.

The best handoff is not the one with the most context. It is the one after which the receiver can act without guessing and the sender can prove who owns what happens next. For teams putting these patterns into a governed operating model, visit Midpoint Enterprise.

Sources

• OpenAI Agents SDK: Handoffs
• Anthropic: Building effective agents
• Google Cloud: Choose a design pattern for your agentic AI system
• NIST AI RMF Playbook: Govern
• OWASP Top 10 for LLM Applications
• Stripe: Idempotent requests