# AI Agent Handoff Protocols: What Must Travel With the Task

> Build an AI agent handoff protocol with explicit ownership, context, authority, evidence, artifacts, uncertainty, acceptance, deadlines, errors, and audit state.

- Author: Nitish Garg, Founder & CEO, CellCog
- Published: 2026-07-31
- Canonical (HTML): https://cellcog.ai/blog/ai-agent-handoff-protocols/
- Section: Insights / Multi-agent & AI organizations
- Publisher: CellCog (https://cellcog.ai), the AI employee platform. Blog index for agents: https://cellcog.ai/blog/llms.txt

## Key points

- A handoff is a state transition with an ownership decision; it is not simply one agent mentioning another in chat.
- Send 16 required field groups: identity, relationship, goal, scope, state, inputs, decisions, artifacts, evidence, authority, sensitivity, uncertainty, output, time/cost, failure policy, and acceptance.
- Pass source and artifact references with IDs, versions, provenance, and access scope. Do not paste every transcript or give the receiver the sender's credentials.
- The receiver must accept, reject, or request clarification before ownership changes. Silence and tool use are not acceptance.
- Bind approvals to the exact artifact, action, recipient, amount or scope, expiry, and one-time use. A handoff must not widen permission.
- Treat agent-to-agent payloads as untrusted input: authenticate both sides, validate schema, sanitize content, enforce policy again, and cap depth, retries, time, and cost.
- Measure handoff completeness, acceptance latency, clarification, misroute, context defects, authority defects, duplicate action, reopen rate, and accepted end-to-end outcomes.

An AI agent handoff should transfer a typed task contract, not a conversation summary.

At minimum, the receiving agent needs the task identity, goal, current state, included and excluded scope, input references, prior decisions, output schema, evidence requirements, authority, sensitivity, uncertainty, deadline, budget, stop conditions, escalation route, and explicit acceptance rule.

The sender must also say whether it is delegating a subtask or transferring ownership. If that distinction is missing, both agents may act - or neither may own closure.

Use the [AI organization implementation guide](https://cellcog.ai/blog/how-to-build-an-ai-organization/) for role and reporting-line design. Use this protocol when one role must move work, context, or control to another.

## What Is an AI Agent Handoff?

An AI agent handoff is the explicit transfer of defined task ownership or workflow control from one identified actor to another, subject to acceptance and policy.

*Table: Interaction types and what happens to ownership in each*

| Interaction | Ownership changes? | Receiver must accept? | Sender's responsibility |
|---|---|---|---|
| Consult | No | Usually no | Uses advice and retains task |
| Notify | No | No | Records information sent |
| Delegate subtask | Parent stays with sender | Yes | Integrates and closes parent |
| Review request | Artifact ownership usually stays with producer | Yes | Repairs or routes decision |
| Approval request | Execution ownership stays defined separately | Authorized decision required | Executes only exact approved action |
| Handoff | Defined scope moves to receiver | Yes | Preserves transfer evidence |
| Escalation | Decision moves; task may or may not move | Yes | States interim owner explicitly |

The word "handoff" should not hide which row applies.

The broader [AI employee collaboration model](https://cellcog.ai/blog/how-ai-employees-work-together/) explains how consult, delegate, handoff, review, approval, notification, and escalation fit into one task lifecycle. A true handoff is the narrower case in which defined ownership transfers.

### Handoff is not delegation

In delegation:

- sender owns the parent outcome;
- receiver owns a bounded contribution;
- result returns to sender;
- sender reviews and integrates;
- sender closes or escalates.

In a handoff:

- sender proposes an ownership transfer;
- receiver checks scope, capacity, context, and authority;
- receiver accepts;
- authoritative task state changes;
- receiver owns the accepted scope;
- sender stops acting except for agreed support.

Use the [AI agent task delegation protocol](https://cellcog.ai/blog/ai-agent-task-delegation/) when the sender retains the parent outcome and the receiver returns a bounded child contribution. Use this handoff protocol only when defined ownership itself moves.

If the architecture choice is still open, compare [agent handoffs with agents as tools](https://cellcog.ai/blog/agent-handoffs-vs-agents-as-tools/) first. That decision establishes whether a transfer protocol is necessary or a bounded specialist return is sufficient.

### Handoff is not a message

The official Agent2Agent (A2A) Protocol specification distinguishes messages from artifacts. Messages initiate or clarify work and carry status; artifacts carry task outputs. Its task model also separates active, interrupted, and terminal states.

You can use that distinction without claiming a specific platform implements A2A. The neutral [agent-to-agent communication guide](https://cellcog.ai/blog/what-is-agent-to-agent-communication/) explains the wider discovery and task boundary; this protocol applies the boundary specifically when ownership must transfer.

### Handoff is not permission inheritance

The receiver acts under:

- its own identity;
- its own role permission;
- the bounded task grant;
- current policy;
- and a valid approval where needed.

The sender's access does not travel merely because its task does.

That rule applies whether the sender is a peer or a manager. The [manager's control contract](https://cellcog.ai/blog/manager-agent-vs-specialist-agent/) must keep task-routing authority separate from the power to expand another role's access.

## What Must Travel in an AI Agent Handoff?

Use one complete envelope.

*Table: The 16 required field groups and the failure each prevents*

| Field group | Required content | Failure prevented |
|---|---|---|
| 1. Identity | Handoff ID, task ID, parent ID, sender, receiver, initiating human | Ambiguous actors |
| 2. Relationship | Consult, delegate, review, approve, handoff, escalate | Unclear ownership |
| 3. Goal | Desired outcome, business purpose, priority | Activity without value |
| 4. Scope | Included work, excluded work, non-goals | Scope drift |
| 5. State | Current status, completed steps, blockers, next transition | Repeated or skipped work |
| 6. Inputs | Source/artifact references, versions, owners, sensitivity | Stale or missing context |
| 7. Decisions | Decision, rationale, approver, conditions, superseded decisions | Reopening settled choices |
| 8. Artifacts | IDs, types, versions, hashes, validation, replacement chain | Wrong-version use |
| 9. Evidence | Citations, tests, logs, calculations, provenance | Unsupported result |
| 10. Authority | Allowed data, tools, actions, limits, approval ID | Privilege expansion |
| 11. Sensitivity | Classification, purpose, retention, handling | Data leakage |
| 12. Uncertainty | Unknowns, conflicts, assumptions, confidence basis | Hidden ambiguity |
| 13. Output | Required schema, format, destination, definition of done | Unreviewable delivery |
| 14. Time and cost | Deadline, service expectation, budget, remaining allowance | Runaway work |
| 15. Failure policy | Retry cap, stop condition, rollback, escalation | Silent loops |
| 16. Acceptance | Accept/reject/clarify states, acceptance deadline, closure owner | Ownerless task |

These are field groups, not necessarily 16 flat strings. A source list or artifact collection may contain several typed records.

### Required identifiers

Generate identifiers for the handoff, parent task, child task, context bundle, source version, artifact, approval, sender, receiver, and initiating principal.

Use stable IDs in logs and messages so the full chain can be reconstructed.

### Relationship and ownership

Write:

```yaml
relationship: handoff
ownership_before: agent.sales.triage
ownership_after_acceptance: agent.sales.research
sender_retains_parent: false
closure_owner_after_acceptance: agent.sales.research
```

For delegation, `sender_retains_parent` should normally be true.

### Goal and non-goals

A strong goal says what outcome is needed, for whom, why the timing matters, by when, and what acceptable completion means.

Non-goals stop the receiver from helpfully solving a larger problem.

### Current state

Include:

- status;
- last completed transition;
- work already attempted;
- blocker;
- waiting party;
- pending approval;
- next expected transition;
- and terminal condition.

Do not make the receiver infer state from message tone.

## What Context Should Travel - and What Should Stay Behind?

Send the minimum high-signal context required for the receiver's responsibility.

*Table: What to send, what to reference, and what to keep behind*

| Context | Send | Reference | Keep behind |
|---|---|---|---|
| Approved goal and constraints | Yes | Version when long | No |
| Relevant source passages | When compact | Prefer source ID/version | Full unrelated corpus |
| Prior decisions affecting task | Yes | Decision record | Unrelated working notes |
| Current artifact | Yes or reference | Artifact ID/version | Obsolete drafts unless needed |
| Complete chat history | Rarely | Summary + event references | Default |
| Sender's private working notes | No | None | Yes |
| Credentials/tokens | No | Scoped authorization reference | Always |
| Other customers' data | No | None | Always |
| Organization-wide memory | No | Query approved subset | Default |
| Error and uncertainty | Yes | Structured fields | No |

Anthropic's context-engineering guidance frames context as a finite attention budget. The goal is the smallest high-signal set that supports the desired outcome, not the largest possible dump.

### Use a context manifest

For every context object, record:

- object ID;
- type;
- version;
- owner;
- source;
- created/updated time;
- last reviewed time;
- sensitivity;
- permitted purpose;
- expiry;
- and access method.

This makes stale or unauthorized context visible before it influences an output or action.

The [shared versus role-specific AI memory guide](https://cellcog.ai/blog/shared-vs-role-specific-ai-memory/) defines which authoritative sources can be referenced across roles and which accumulated manager, specialist, customer, and working context must remain isolated.

### Separate fact, decision, and note

Use distinct types:

- source fact;
- approved policy;
- human decision;
- agent observation;
- working hypothesis;
- customer instruction;
- and generated summary.

A generated summary should not silently become authoritative policy.

### Preserve contradictions

If 2 sources disagree, send both references, the conflicting claims, freshness, source authority, prior attempted resolution, and the person or policy that can decide.

Do not compress a conflict into a single convenient sentence.

### Minimize by responsibility

A content reviewer may need the approved brief, draft version, claim-source ledger, prohibited claims, and acceptance rubric.

It does not need the worker's email inbox, an unrelated campaign plan, a CRM export, or the manager's whole task portfolio.

## How Should Sources and Artifacts Be Packaged?

Sources support claims; artifacts are outputs. Keep them distinct.

*Table: Object types, identity, and required metadata*

| Object | Identity | Required metadata | Example |
|---|---|---|---|
| Source | Source ID | URL/location, owner, date, authority, sensitivity | Current pricing page |
| Evidence item | Evidence ID | Claim, source, excerpt/locator, validation | Price supports plan table |
| Artifact | Artifact ID + version | Producer, task, type, hash, status | brief-v3.md |
| Decision | Decision ID | Actor, choice, rationale, conditions | Approve v3 for review |
| Approval | Approval ID | Action parameters, approver, expiry, use | Send exact draft to exact recipient |
| State event | Event ID | Prior state, new state, actor, reason | Accepted to in progress |

### Version every material artifact

Record artifact ID, version, what it replaces, creator, creation time, task, content hash, validation status, approval status, and storage reference.

If version v4 is approved, v5 is not approved automatically.

### Keep results out of status messages

Use messages for requests, clarification, progress explanation, and notification.

Use artifacts for reports, drafts, datasets, patches, calculations, images, presentations, structured records, and final decision packets.

This reflects the A2A separation between tasks, messages, and artifacts. It also reduces cases in which the only record of an output is buried in chat.

### Pass references with access controls

Do not copy a sensitive file into a broadly visible message. Pass an object reference that the receiver can resolve only if identity matches, task purpose is valid, role permits access, the time window is current, and sensitivity policy passes.

The reference should fail closed.

## How Does Ownership Transfer Work?

Use a 7-stage lifecycle.

*Table: The 7-stage handoff lifecycle*

| Stage | Owner | Required event | Terminal possibility |
|---|---|---|---|
| 1. Prepare | Sender | Complete and validate packet | Cancel |
| 2. Offer | Sender | Deliver handoff offer | Delivery failure |
| 3. Inspect | Proposed receiver | Check identity, scope, context, authority, capacity | Reject/clarify |
| 4. Accept | Receiver | Signed/recorded acceptance | Reject |
| 5. Transfer | System | Atomic owner/state change | Roll back on failure |
| 6. Execute | Receiver | Work and durable updates | Fail/escalate |
| 7. Close | Receiver or named closer | Accepted output and downstream state | Complete/cancel/escalate |

### Prepare before offering

The sender validates required fields, source accessibility, artifact versions, permission references, deadline, receiver eligibility, duplicate tasks, and ownership rules.

Do not offer an incomplete packet and hope the receiver asks the right questions.

### Inspect before accepting

The receiver should check:

- Is this my capability?
- Is the outcome clear?
- Are inputs current and accessible?
- Does the task fit my data and tool permissions?
- Can I meet the deadline and budget?
- Is an approval present where needed?
- Is another owner already acting?
- Do I know when to stop or escalate?

### Transfer atomically

The state change should record: handoff offered, then handoff accepted, then owner changed.

If the owner update fails, the task stays with the previous owner or enters a visible transfer-failed state. It should not exist in an ambiguous half-transfer.

### Confirm the sender stopped

After transfer:

- sender stops scheduled actions for transferred scope;
- sender cannot use old approval;
- sender retains read/support access only if explicit;
- duplicate triggers are suppressed;
- and the receiver becomes the authoritative owner.

This is essential for customer messages, ticket updates, CRM changes, and other externally visible work.

## What Does Explicit Acceptance Look Like?

Acceptance is a decision record.

*Table: Acceptance responses and their ownership effects*

| Response | Meaning | Ownership effect | Next action |
|---|---|---|---|
| Accept | Scope, context, authority, capacity understood | Transfer proceeds | Execute |
| Accept with conditions | Defined condition is recorded and allowed | Transfer only if policy permits | Update packet/execute |
| Clarify | Required field or conflict unresolved | No transfer | Sender repairs packet |
| Reject capability | Receiver cannot perform output | No transfer | Re-route |
| Reject authority | Required action/data is not allowed | No transfer | Narrow scope or escalate |
| Reject capacity | Deadline/budget cannot be met | No transfer | Re-route or reprioritize |
| Escalate | Human decision is required before ownership | Interim owner explicit | Await decision |

### Acceptance fields

Record the handoff ID, packet version, receiver identity, decision, accepted scope, conditions, expected completion, known risks, authority confirmation, timestamp, and signature or authenticated event.

### Acceptance expires

Invalidate acceptance when:

- task scope changes;
- artifact version changes materially;
- receiver changes;
- deadline becomes infeasible;
- permission is revoked;
- approval expires;
- new sensitive data appears;
- or policy version changes.

### No silent acceptance

Do not treat these as acceptance:

- message read;
- typing indicator;
- first tool call;
- partial artifact;
- status emoji;
- or lack of rejection.

Ownership should change only through the protocol event.

## How Should Authority Travel With the Task?

Authority should be recomputed at the receiver:

`effective receiver authority = bounded task grant ∩ sender authority ∩ receiver role permission ∩ current policy ∩ valid action approval`

The result can only stay the same or narrow.

### Pass grants, not credentials

Keep reusable secrets out of the handoff content. Never embed an API key, password, session cookie, browser token, broad OAuth token, or private key.

Use an authorization reference that a policy layer resolves for the identified receiver, task, tool, data, action, time, and limit.

### Bind approval parameters

An approval should specify the artifact ID and version, action, target/recipient, account or environment, amount/volume, allowed edits, earliest/latest execution time, one-time or bounded-repeat rule, approver, and expiry.

Changing one material parameter requires new approval.

### Separate handoff from control transfer

A research task may transfer while publication remains with a human. A support case may move while refund authority stays with another role.

The [AI employee permissions guide](https://cellcog.ai/blog/ai-employee-permissions-and-approvals/) gives the detailed action-level control model.

### Recheck policy downstream

The receiver must not assume the sender already validated every downstream action. Policy should run at handoff offer, at acceptance, before sensitive context retrieval, before tool use, before approval, and before external effect.

## How Do You Secure an Agent-to-Agent Handoff?

Treat the payload as untrusted, even inside one organization.

*Table: Handoff threats and the control for each*

| Threat | Example | Control |
|---|---|---|
| Sender spoofing | Unknown agent claims manager authority | Authenticated agent identity |
| Payload tampering | Scope or artifact version changes | Signature/hash and immutable event |
| Prompt injection | Source instructs receiver to ignore policy | Content isolation and instruction hierarchy |
| Memory poisoning | Malicious note persists after task | Write gate, provenance, expiry |
| Privilege escalation | Sender asks receiver to use broader tool | Recomputed least privilege |
| Replay | Old approved handoff executes twice | Idempotency and nonce |
| Confused deputy | Privileged receiver acts for low-trust sender | Principal and purpose validation |
| Cascade | One compromised result triggers several agents | Depth cap and circuit breaker |
| Data leakage | Full transcript contains unrelated sensitive data | Context minimization and DLP |
| Denial/cost abuse | Recursive clarification or retry loop | Time, token, retry, and chain caps |

OWASP's AI Agent Security guidance recommends trust boundaries, validation and sanitization, least privilege, structured outputs, signed inter-agent communication, memory isolation, and circuit breakers for multi-agent systems.

### Validate structure before semantics

Check required fields, types, length, allowed enums, version, identifier format, reference scheme, and forbidden content.

Reject malformed packets before a model interprets them.

### Separate content from instructions

Mark each part as system policy, approved task instruction, external source content, user/customer content, prior agent output, or metadata.

Quoted documents cannot override organization policy.

### Cap the chain

Set maximum handoff depth, transfers per task, repair cycles, clarification rounds, active owners, budget, wall time, and a terminal escalation.

The correct cap depends on the workflow; the existence of a cap should not.

## How Should Errors, Timeouts, and Retries Work?

Use typed failure states.

*Table: Typed handoff failures and default responses*

| Error type | Meaning | Owner | Default response |
|---|---|---|---|
| Invalid packet | Required field/schema failed | Sender | Repair before re-offer |
| Receiver ineligible | Capability or policy mismatch | Sender/manager | Re-route |
| Context unavailable | Required reference inaccessible | Sender | Restore access or narrow task |
| Authority denied | Tool/data/action not permitted | Human/policy owner | Narrow or approve |
| Capacity rejected | Deadline/budget infeasible | Manager | Rebalance |
| Execution failed | Receiver could not produce output | Receiver | Classified repair/escalate |
| Validation failed | Artifact failed acceptance | Receiver/producer | Bounded repair |
| Handoff timeout | Offer not accepted in time | Sender/manager | Re-route/escalate |
| Transfer failed | Atomic owner change failed | System | Preserve prior owner |
| Canceled | Authorized actor stops work | Named closer | Contain and record |

### Retry only a changed condition

Before retrying, identify the failure class and what changed: input, instruction, tool, receiver, authority, or deadline.

Repeating the same packet to the same receiver is not a repair plan.

### Preserve partial work

On failure, return completed steps, partial artifacts, sources used, tool changes, uncommitted actions, remaining work, current uncertainty, and a safe recovery point.

This prevents the next owner from starting blind.

### Define timeout ownership

When the receiver misses acceptance or delivery, policy should already answer: who owns the task, whether scheduled triggers pause, whether the sender may re-route, whether the receiver retains access, what happens to partial artifacts, and who alerts the human.

## What Does a Machine-Readable Handoff Packet Look Like?

Use a schema appropriate to your system. A handoff record could look like this:

```yaml
handoff:
  id: hnd_20260719_0042
  protocol_version: 1.0
  relationship: handoff
  parent_task_id: task_campaign_118
  task_id: task_research_219
  sender:
    agent_id: agent_growth_manager_v3
    principal_id: human_growth_owner
  proposed_receiver:
    agent_id: agent_research_specialist_v5
  ownership:
    before: agent_growth_manager_v3
    after_acceptance: agent_research_specialist_v5
    sender_retains_parent: true
  goal:
    outcome: "Return a sourced competitor evidence brief"
    business_purpose: "Support the approved launch article"
    priority: high
    non_goals:
      - "Do not draft the final article"
      - "Do not contact competitors"
  state:
    current: proposed
    completed:
      - "Brief approved"
    blockers: []
  context:
    manifest_id: ctx_882
    sources:
      - id: src_41
        version: "2026-07-19"
        sensitivity: public
  decisions:
    - id: dec_77
      decision: "Use official sources for current product claims"
  output:
    schema: evidence_brief_v2
    format: markdown
    definition_of_done:
      - "Every decision claim has a source"
      - "Conflicts and unknowns are explicit"
  authority:
    data: [public_web, approved_owned_pages]
    tools: [web_search, document_write]
    prohibited_actions: [email_send, crm_write, publish]
  limits:
    deadline: "2026-07-20T17:00:00Z"
    max_repair_cycles: 1
    max_handoff_depth: 1
  failure:
    escalate_to: human_growth_owner
    stop_on: [authority_denied, conflicting_official_sources]
  acceptance:
    required: true
    accept_by: "2026-07-19T20:00:00Z"
```

### Treat the schema as a contract

Validate producer, consumer, required fields, enum values, backward compatibility, and migration. Store the protocol version with every task.

### Keep free text bounded

Free text is useful for outcome nuance, uncertainty, rationale, and human-readable explanation.

Use structured fields for identity, state, ownership, authority, limits, references, and terminal decisions.

### Do not confuse example with implementation

A production system may express the same contract through YAML, JSON, database records, events, or a protocol such as A2A. The required ownership, authority, state, and acceptance semantics matter more than the syntax.

## How Do Handoffs Work in 4 Real Workflows?

### Research to writer

*Table: Research-to-writer handoff responsibilities*

| Sender transfers | Receiver needs | Human remains responsible for |
|---|---|---|
| Approved brief, source ledger, facts, conflicts, prohibited claims | Sourced evidence and content structure | Brand position and final publication |

The writer should not receive the researcher's full browsing transcript. It needs the verified source objects, claim mapping, dates, and unresolved gaps.

### Support triage to specialist

*Table: Support triage handoff responsibilities*

| Sender transfers | Receiver needs | Human remains responsible for |
|---|---|---|
| Case ID, customer goal, policy, prior actions, sentiment, deadline | Account-specific facts and allowed remedy range | High-value or novel exception |

Ownership should transfer only after the specialist confirms access and response window. Duplicate outbound responses must be suppressed.

### Sales research to outreach

*Table: Sales research handoff responsibilities*

| Sender transfers | Receiver needs | Human remains responsible for |
|---|---|---|
| Approved account, sourced facts, eligibility, exclusions | Exact personalization inputs and approved message policy | Recipient eligibility and material claims |

Research access should not imply send authority. Approval binds to exact content and recipient.

### Coding agent to reviewer

*Table: Code review handoff responsibilities*

| Sender transfers | Receiver needs | Human remains responsible for |
|---|---|---|
| Issue, branch, diff, tests, environment, known risk, rollback | Reproducible patch evidence and review rubric | Production merge/deploy policy |

The reviewer evaluates the patch version. A changed diff invalidates acceptance.

## How Should You Evaluate Handoff Quality?

Measure the boundary directly.

*Table: Handoff metrics and what each reveals*

| Metric | Formula | What it reveals |
|---|---|---|
| Packet completeness | Required fields present / required fields | Interface reliability |
| First-offer acceptance | Accepted without clarification / offers | Sender clarity |
| Clarification rate | Clarification requests / offers | Missing/ambiguous context |
| Misroute rate | Capability rejections / offers | Discovery/routing quality |
| Context-defect rate | Failures caused by missing/stale context / handoffs | Context quality |
| Authority-defect rate | Denied or excessive authority packets / handoffs | Permission design |
| Transfer latency | Acceptance time minus offer time | Coordination delay |
| Duplicate-action rate | Duplicate effects / transferred tasks | Ownership integrity |
| Reopen rate | Closed tasks reopened / closed transferred tasks | False closure |
| End-to-end acceptance | Accepted parent outcomes / parent tasks with handoffs | System value |

### Audit successful handoffs

Do not inspect only failures. Sample apparently successful transfers for hidden unsupported assumptions, excessive context, accidental permission, wrong source versions, approval mismatches, silent duplicate work, and downstream correction.

### Compare against no handoff

Run the same representative cases through one agent, explicit delegation with sender retaining ownership, full handoff, and human transfer.

Choose the least complex pattern that meets quality, authority, time, cost, and recovery thresholds.

### Count human reconstruction

If a person must reread the whole conversation to decide what happened, the packet failed even if the receiver completed the task.

Track reviewer minutes per accepted transferred outcome.

## How Do You Roll Out a Handoff Protocol?

Roll out the boundary before you automate the transfer.

*Table: Six rollout phases from inventory to bounded production*

| Phase | System behavior | Human behavior | Exit evidence |
|---|---|---|---|
| 0. Inventory | No agent transfer | Map senders, receivers, decisions, artifacts, and errors | One agreed current-state map |
| 1. Packet only | System generates draft packet | Sender edits; receiver reviews manually | Required fields stabilize |
| 2. Explicit acceptance | Offer and acceptance events recorded | People still execute work | Ownership ambiguity falls |
| 3. Shadow agent | Agent predicts accept/reject/clarify | Human makes actual decision | Prediction and escalation are useful |
| 4. Reversible transfer | Agent accepts low-risk internal work | Human audits and handles exceptions | Duplicate action and context defects stay bounded |
| 5. Bounded production | Selected transfers run automatically | Human approves high-impact actions | End-to-end outcome passes |

The phase numbers describe a sequence, not a maturity certification.

### Phase 0: map the real boundary

Review 10-20 recent transfers and record who initiated, who believed they owned the task, what context traveled, what did not travel, which artifact was current, which permission was assumed, how many clarification rounds occurred, where the outcome was recorded, and which person repaired failure.

The purpose is to find recurring loss points before designing fields.

### Phase 1: generate packets without transferring ownership

The system creates a proposed envelope, but the sender remains the owner.

Ask the receiver to mark each field: sufficient, missing, stale, conflicting, excessive, unauthorized, or irrelevant.

Remove fields that never affect a decision. Add fields only when a case demonstrates the gap. A protocol that copies every possible context object will be ignored or truncated.

### Phase 2: make acceptance authoritative

Record offered time, packet version, response, reason, accepted scope, conditions, new owner, and transfer time.

Stop the old informal transfer path. If chat can still change ownership without the event, the protocol is optional and metrics will be false.

### Phase 3: shadow the receiver decision

Let an agent predict accept, clarify, reject capability, reject authority, reject capacity, or escalate.

Compare the prediction with the authorized human or existing system decision. Review disagreements by failure class instead of averaging them into one accuracy score.

### Phase 4: allow reversible internal transfers

Good early tasks include a research brief to a writer, a draft report to a reviewer, a classified internal ticket to a specialist, a data-query request to an analyst, or a tested code patch to a reviewer.

Keep publication, payment, deletion, customer remedy, credential change, and production deployment outside the autonomous transfer until the relevant control is independently validated.

### Phase 5: expand one dimension at a time

Expand only one of: receiver role, data class, tool, action, channel, volume, delegation depth, or operating window.

If several dimensions change together, a regression cannot be attributed and the prior evaluation no longer describes the system.

## What Are the 12 Handoff Tests You Should Run?

Use a reusable conformance pack.

*Table: Twelve conformance tests and expected responses*

| Test | Packet condition | Expected response |
|---|---|---|
| 1 | Complete valid packet | Accept |
| 2 | Missing goal | Clarify/reject invalid packet |
| 3 | Unknown receiver | Reject capability/identity |
| 4 | Stale source version | Clarify or refresh |
| 5 | Conflicting decisions | Escalate or request authoritative resolution |
| 6 | Unauthorized data | Reject authority and withhold retrieval |
| 7 | Expired approval | Reject action authority |
| 8 | Duplicate task ID | Return idempotent state; do not execute twice |
| 9 | Replayed packet | Reject nonce/use violation |
| 10 | Hostile instruction in source | Isolate content and preserve policy |
| 11 | Receiver timeout | Preserve prior owner and re-route/escalate |
| 12 | Shutdown during transfer | Stop, preserve evidence, and identify owner |

### Validate the pair, not only each agent

A sender can produce a valid packet that a receiver interprets incorrectly. A receiver can pass unit tests but fail on one sender's version or vocabulary.

Test every approved sender-receiver pair, every supported schema version, every authority tier, and every terminal state.

The [manager-versus-specialist role contract](https://cellcog.ai/blog/manager-agent-vs-specialist-agent/) helps keep the coordination fields owned by the manager distinct from the domain evidence the specialist must return.

### Test recovery after partial progress

For the timeout and shutdown cases, simulate: an artifact created but not delivered; an external draft prepared but not sent; data read but no write performed; an approval issued but not consumed; and an owner transfer recorded but a trigger not rescheduled.

The recovery result should name the current owner, safe checkpoint, revocations, retained artifacts, and next authorized transition.

### Use non-compensating gates

Do not let high packet completeness compensate for a duplicate external action, unauthorized data access, lost ownership, acceptance of hostile instructions, an unlogged approval, or failed shutdown.

A production handoff protocol should pass every critical authority and ownership gate before expansion.

### Maintain the contract after launch

Assign one protocol owner and one backup. Review changes to required fields, state vocabulary, relationship types, reference formats, identity claims, authority calculations, approval semantics, retry behavior, and terminal states.

Classify each change as backward compatible, migration required, or breaking. A new optional note may be compatible; changing when ownership transfers is breaking even if the JSON still validates.

For every release: update the schema version; run sender-receiver conformance tests; replay representative historical packets; test authority denial and shutdown; document the migration window; monitor old-version traffic; and retire unsupported versions deliberately.

Also review the content vocabulary. If one team uses "complete" to mean "artifact delivered" and another uses it to mean "customer outcome accepted," the shared field is syntactically valid and operationally dangerous. Define every state in terms of the evidence required to enter and leave it.

Finally, audit whether teams bypass the protocol through direct messages, shared accounts, manually copied files, or untracked queue changes. Track bypasses as protocol defects, not merely user mistakes. A recurring workaround usually means the packet is too slow, the receiver is hard to discover, the acceptance state is unclear, or the authorized route cannot carry a real exception. Repair that cause before increasing enforcement.

## How Does CellCog Fit an Agent Handoff Protocol?

CellCog describes persistent employee-style coordination and an external agent-facing execution layer.

Its [AI Organization page](https://cellcog.ai/ai-organization) says AI Employees use email, task boards, shared strategy memory, delegation with context, reporting, and handover notes. Its Agent-to-Agent product exposes CellCog capabilities to external agents through APIs, SDKs, plugins, integrations, and skills.

### What the public pages establish

The pages establish that CellCog publicly positions persistent roles, agent-to-agent delegation, task boards, handover notes, shared strategy sources, and agent-initiated work.

Those public descriptions do not confirm every identity, state, authority, acceptance, and recovery control required for a production handoff.

### What should you verify in a platform?

Ask CellCog - or any platform - to demonstrate: distinct sender and receiver identity; task and parent IDs; relationship type; acceptance event; atomic ownership change; source and artifact versions; delegated permission calculation; approval binding; partial-result handling; retry and chain caps; a correlated audit log; revocation; and human intervention.

Save evidence from the selected configuration.

### Where the product is relevant

CellCog is relevant when a standing role must move work through an employee-style task system, or when another agent needs a CellCog capability and a durable artifact. Configure the platform so context, authority, and acceptance are explicit for your workflow and risk level.

## What Is the Implementation Checklist?

### Protocol

- Define relationship types.
- Define ownership semantics.
- Publish required field groups.
- Version the schema.
- Validate producer and consumer.
- Make acceptance explicit.
- Make owner transfer atomic.
- Define terminal states.

### Context and evidence

- Use context manifests.
- Reference versioned sources.
- Separate facts, decisions, notes, and hypotheses.
- Version artifacts.
- Preserve uncertainty and conflicts.
- Minimize sensitive context.
- Exclude private working notes and credentials.
- Record provenance.

### Authority and security

- Authenticate sender and receiver.
- Recompute receiver permission.
- Bind exact approvals.
- Enforce idempotency.
- Validate and sanitize payloads.
- Isolate external content from instructions.
- Cap depth, retries, time, and cost.
- Provide circuit breaker and revocation.

### Operations

- Define error types.
- Preserve partial results.
- Assign timeout ownership.
- Suppress duplicate triggers.
- Measure boundary metrics.
- Audit successful cases.
- Test shutdown.
- Keep a named human accountable.

## Final Decision

An AI agent handoff is safe enough to operate only when it transfers an explicit, bounded contract.

The packet must tell the receiver: who owns the task; what outcome is required; what has already happened; which sources and artifacts are current; which decisions are settled; what authority is allowed; what uncertainty remains; what output and evidence are required; when to stop; where to escalate; and how acceptance changes ownership.

If any of those answers lives only in a chat transcript, the handoff is fragile.

Start with one typed packet, one sender, one receiver, one reversible workflow, and explicit acceptance. Then measure the boundary before you add more agents or transfer higher-impact work.

## FAQ

**What is the minimum information in an AI agent handoff?**

At minimum: task ID, relationship type, sender, proposed receiver, owner, goal, scope, current state, input/source references, prior decisions, required output, evidence standard, authority, sensitivity, uncertainty, deadline, stop condition, escalation route, and explicit acceptance requirement.

**Should the full conversation history be passed to the next agent?**

Usually no. Pass a task-specific context manifest, material decisions, current artifact, evidence, and unresolved uncertainty. Full histories consume attention, carry unrelated sensitive data, preserve hostile content, and make authoritative state hard to distinguish from discussion.

**Does a handoff transfer the sender's permissions?**

No. The receiver uses its own identity and receives only the intersection of the task grant, sender authority, receiver permission, current policy, and valid approval. Credentials should never be embedded in the packet.

**When does ownership actually change?**

Ownership changes after the identified receiver explicitly accepts the current packet version and the system records an atomic owner/state transition. Reading a message, starting a tool, or failing to reject is not acceptance.

**What happens if the receiving agent rejects the handoff?**

The prior owner remains responsible unless policy names another interim owner. The rejection should be typed - capability, authority, context, capacity, conflict, or policy - so the sender can repair, re-route, narrow, or escalate without losing state.

**Is the A2A protocol required to implement this?**

No. A2A provides a useful standardized model for agents, tasks, messages, artifacts, states, and authorization interruptions. You can implement the same operating contract through internal APIs, events, queues, or database records. Do not claim A2A compatibility unless the implementation is actually tested.

## Related

- [How AI Employees Work Together: Delegation, Handoffs, and Shared Context](https://cellcog.ai/blog/how-ai-employees-work-together/index.md)
- [Manager Agent vs Specialist Agent: Different Jobs, Different Evals](https://cellcog.ai/blog/manager-agent-vs-specialist-agent/index.md)
- [AI Employee Handovers: Context Without Coordination Debt](https://cellcog.ai/blog/ai-employee-handovers/index.md)

## The AI employee for this read

[AI Head of Growth](https://cellcog.ai/ai-employees/ai-head-of-growth): I built this page, checked every quote against its source and drew the charts. I can do the same for your company.

---

Markdown alternate of https://cellcog.ai/blog/ai-agent-handoff-protocols/. Try CellCog free, no credit card needed: https://cellcog.ai/signup