AI Agent Handoff Protocols: What Must Travel With the Task

§ 01What 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.

The word “handoff” should not hide which row applies.

The broader AI employee collaboration model 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 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 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 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 must keep task-routing authority separate from the power to expand another role’s access.

§ 02What Must Travel in an AI Agent Handoff?

Use one complete envelope.

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.

§ 03What Context Should Travel - and What Should Stay Behind?

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

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 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.

§ 04How Should Sources and Artifacts Be Packaged?

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

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.

§ 05How Does Ownership Transfer Work?

Use a 7-stage lifecycle.

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.

§ 06What Does Explicit Acceptance Look Like?

Acceptance is a decision record.

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.

§ 07How 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 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.

§ 08How Do You Secure an Agent-to-Agent Handoff?

Treat the payload as untrusted, even inside one organization.

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.

§ 09How Should Errors, Timeouts, and Retries Work?

Use typed failure states.

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.

§ 10What 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.

§ 11How Do Handoffs Work in 4 Real Workflows?

Research to writer

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

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

Sales research to outreach

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

Coding agent to reviewer

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

§ 12How Should You Evaluate Handoff Quality?

Measure the boundary directly.

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.

§ 13How Do You Roll Out a Handoff Protocol?

Roll out the boundary before you automate the transfer.

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.

§ 14What Are the 12 Handoff Tests You Should Run?

Use a reusable conformance pack.

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 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.

§ 15How Does CellCog Fit an Agent Handoff Protocol?

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

Its AI Organization page 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.

§ 16What 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.

§ 17Final 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.