Open format · v1.0
Handoff Continuity Record
An open, platform-neutral AI agent handoff protocol for the state another human or agent needs to verify and continue interrupted work.
Version 1.0 · Stable · Updated 5 August 2026
- Format
- JSON
- Schema
- Draft 2020-12
- Runtime
- Neutral
- License
- MIT
Direct answer
What should an agent handoff contain?
A useful agent handoff contains the objective, verified and unverified state, decisions, evidence, constraints, next action, ownership, and unresolved review. The continuity record makes those fields machine-readable without prescribing how agents are routed, authenticated, or hosted. It is an open format created by Handover, not an official MCP or A2A standard.
Normative record
Eight continuation fields
The schema keeps the short operational brief separate from its evidence and implementation-specific extensions.
Objective
The desired outcome and explicit acceptance criteria.
Current state
Complete, in-progress, blocked, and unverified claims kept separate.
Decisions
Active and superseded choices with the rationale needed to avoid repeating work.
Evidence
Files, URIs, content types, claims, and optional SHA-256 integrity digests.
Constraints
Permissions, safety rules, deadlines, budgets, dependencies, and exclusions.
Next action
One concrete continuation step and the observable result that verifies it.
Ownership
The next responsible human, agent, or service plus optional reviewers.
Open review
Unresolved feedback and resolved findings linked to the revision that addressed them.
Valid reference record
Inspect the state a successor actually receives
This complete example passes the v1.0 schema and validator. It keeps the operational brief readable while preserving the exact evidence, constraint, review, and ownership references a receiver must verify.
{
"schemaVersion": "1.0",
"recordId": "inventory-reporting-v3",
"objective": {
"summary": "Correct the daily inventory report so reserved stock is excluded from available inventory.",
"acceptanceCriteria": [
"Available inventory equals on-hand stock minus reserved stock.",
"The corrected query passes the fixture in evidence/test-output.json.",
"The open SQL review is resolved against the correcting revision."
]
},
"currentState": {
"complete": [
"Located the inventory aggregation in artifacts/inventory.sql.",
"Reproduced the overstatement with the warehouse fixture."
],
"inProgress": [
"Correct the available inventory calculation and publish a new revision."
],
"blocked": [],
"unverified": [
"Whether the downstream dashboard cache requires invalidation."
]
},
"decisions": [
{
"summary": "Calculate available inventory as on_hand minus reserved.",
"rationale": "Reserved units remain physically present but cannot be promised to a new order.",
"status": "active"
}
],
"evidence": [
{
"id": "inventory-query",
"label": "Current inventory query",
"claim": "The current query reports on-hand stock as available stock.",
"artifactRef": "artifacts/inventory.sql",
"contentType": "application/sql"
},
{
"id": "fixture-output",
"label": "Failing warehouse fixture",
"claim": "The fixture expects 58 available units and the current query returns 70.",
"artifactRef": "evidence/test-output.json",
"contentType": "application/json"
}
],
"constraints": [
{
"kind": "safety",
"text": "Do not modify source inventory rows while correcting the reporting query."
},
{
"kind": "permission",
"text": "Production deployment requires approval from the inventory reporting owner."
}
],
"nextAction": {
"summary": "Update artifacts/inventory.sql, run the fixture, and publish both files as the next revision.",
"verification": "The fixture returns 58 available units and the new revision is linked from the resolved SQL review."
},
"ownership": {
"nextActor": {
"id": "agent:inventory-corrector",
"displayName": "Inventory corrector",
"type": "agent"
},
"reviewers": [
{
"id": "user:finance-owner",
"displayName": "Finance owner",
"type": "human"
}
]
},
"openReview": [
{
"id": "review:sql-available-stock",
"summary": "Available inventory does not subtract reserved stock.",
"status": "open",
"artifactRef": "artifacts/inventory.sql",
"revision": 3,
"assignee": {
"id": "agent:inventory-corrector",
"displayName": "Inventory corrector",
"type": "agent"
}
}
],
"provenance": {
"createdBy": {
"id": "agent:inventory-auditor",
"displayName": "Inventory auditor",
"type": "agent"
},
"createdAt": "2026-08-04T00:00:00Z",
"sourceRevision": 3
}
}- 01Confirm the objective
Read the acceptance criteria before treating any current state as useful.
- 02Inspect the evidence
Resolve every artifact reference needed for the stated claim and next action.
- 03Respect the boundary
Apply constraints, open review, ownership, and the observable verification result before continuing.
Conformance
Producers preserve state; receivers verify it
Producer requirements
- Complete every required top-level field.
- Separate verified state from unverified claims.
- Reference evidence instead of embedding credentials.
- Keep implementation data under namespaced extensions.
- Link resolved review to the revision that addressed it.
Receiver requirements
- Confirm the objective before acting.
- Read the evidence required for the next action.
- Observe applicable permissions and safety constraints.
- Identify the responsible next actor.
- Verify the stated result before claiming continuation.
Reference validator
Validate a record without installing dependencies
Download the validator and example, then run the structural conformance check with Node.js.
curl -O https://handover.sh/protocol/v1/validate.mjs
curl -O https://handover.sh/protocol/v1/example.json
node validate.mjs example.jsonArchitecture boundary
The record complements transport and routing
It describes continuation state. It does not replace protocols that connect tools or delegate work.
Security boundary
Transfer useful state, not secrets or hidden reasoning
Never include passwords, tokens, private keys, session cookies, hidden chain-of-thought, or unnecessary personal data. Refer to approved secret names, preserve concise decision rationale, and attach only the evidence the receiving actor is authorized to use.
Related standards
Primary references
Implementation FAQ
Where the handoff record fits
What is an AI agent handoff protocol?
It defines the portable state a receiving person or agent needs to verify and continue work. The Handoff Continuity Record covers objective, current state, decisions, evidence, constraints, next action, ownership, and open review.
Is this part of MCP or A2A?
No. The Handoff Continuity Record is an open format created by Handover. MCP can expose tools that read or write it, while A2A or an orchestration framework can route it. The record defines the durable continuation payload, not transport or routing.
Can I use the format without Handover?
Yes. Store the JSON record in Git, local files, object storage, or another shared system. Handover adds authenticated identity, immutable revisions, artifacts, review, search, and access policy around the format.
How do I validate a record?
Validate it against the published JSON Schema or run the dependency-free Node.js validator against the valid example. Structural validation is only the first gate: the receiver must still verify the evidence, constraints, ownership, and next action.
Put the record to work
Store it in Git, pass it through MCP, or publish it to Handover
The format is independent of Handover. Use the platform when you need shared identity, revisions, files, review, search, and access policy around the record.