MCP and orchestration

Agent Handoff Evidence Contract

Transfer work between agents or people with explicit ownership, minimized context, verified state, acceptance evidence, and safe continuation rules.

Core conceptAnthropicOpenAIGoogle
CurrentNext review due 2026-08-24Content version 0.30.0
Format
Template
Level
Intermediate
Audience
Practitioner, Developer, Operator
Owner
Project42 Editorial
Review cadence
Every 30 days
Prerequisites
A workflow boundary with a named source and destination owner
01

Transfer control, not transcript bulk

Name the sending owner, receiving owner, exact outcome, current state, completed actions, unresolved risks, permission boundary, and next bounded action. Pass only the context required for the receiver's role. Treat prior model claims and tool output as untrusted until tied to source or test evidence.

State whether the receiver becomes the user-facing owner or remains a bounded specialist. A handoff description should explain when to route there, but runtime policy must enforce who may access data, invoke tools, approve mutations, and return the final result. Guardrails at one agent boundary do not automatically protect every downstream tool or handoff.

02

Record the handoff package

Reconcile external side effects before transfer. Preserve operation identifiers, idempotency keys, pending approvals, failed attempts, and the system-of-record state so a receiver does not repeat an action after an ambiguous response.

Agent handoff evidence package
text
Handoff ID and time: [ID, ISO TIMESTAMP]
Sender / receiver: [ROLE -> ROLE]
Control mode: [TRANSFER OWNERSHIP | SPECIALIST RETURNS RESULT]
Outcome and done condition: [RESULT, ACCEPTANCE]
Authority and permissions: [ALLOWED, MUST ASK, DENIED]
Verified current state: [SYSTEM OF RECORD -> STATE, AS OF]
Completed actions: [ACTION, OPERATION ID, POSTCONDITION]
Artifacts and evidence: [REF -> WHAT IT PROVES]
Context passed: [MINIMUM DATA]
Context withheld/redacted: [DATA -> REASON]
Assumptions and unknowns: [ITEM -> VALIDATION]
Rejected/failed attempts: [ATTEMPT -> RESULT]
Pending approvals or side effects: [ITEM -> OWNER]
Next bounded action: [ONE ACTION]
Verification after next action: [CHECK]
Timeout/escalation: [CONDITION -> OWNER]
Rollback/recovery: [METHOD]
Receiver acknowledgement: [ACCEPTED | REJECTED WITH REASON]
03

Expected evidence and verification

The expected evidence is an acknowledged handoff package that lets the receiver reconstruct the authorized current state, trace material claims, avoid duplicate effects, and know exactly when work is complete or must be escalated.

Test the package with a receiver that has no hidden session history. Confirm evidence links resolve, restricted data is absent, permissions match enforcement, external state is current, and the next action cannot silently exceed scope. Exercise rejection, timeout, cancellation, and return-to-sender paths. Preserve the final acknowledgement and disposition in the system of record.