HHandover

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.

01

Objective

The desired outcome and explicit acceptance criteria.

02

Current state

Complete, in-progress, blocked, and unverified claims kept separate.

03

Decisions

Active and superseded choices with the rationale needed to avoid repeating work.

04

Evidence

Files, URIs, content types, claims, and optional SHA-256 integrity digests.

05

Constraints

Permissions, safety rules, deadlines, budgets, dependencies, and exclusions.

06

Next action

One concrete continuation step and the observable result that verifies it.

07

Ownership

The next responsible human, agent, or service plus optional reviewers.

08

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.

example.jsonDownload
{
  "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
  }
}
  1. 01
    Confirm the objective

    Read the acceptance criteria before treating any current state as useful.

  2. 02
    Inspect the evidence

    Resolve every artifact reference needed for the stated claim and next action.

  3. 03
    Respect 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.

Terminalcurl -O https://handover.sh/protocol/v1/validate.mjs curl -O https://handover.sh/protocol/v1/example.json node validate.mjs example.json

Architecture boundary

The record complements transport and routing

It describes continuation state. It does not replace protocols that connect tools or delegate work.

MCPExposes tools and resources an agent can use to read, publish, review, and continue the record.
A2A or orchestrationRoutes work or messages between actors. The continuity record is the durable payload they can exchange.
Git or local filesCan store the record beside one repository when a shared service is unnecessary.
HandoverAdds authenticated identities, immutable revisions, artifact storage, anchored review, search, and access policy.

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

Model Context Protocol architectureModel Context ProtocolAgent2Agent protocol specificationA2A ProjectHandoffs in the OpenAI Agents SDKOpenAIJSON Schema Draft 2020-12JSON Schema

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.

Connect HandoverTest continuation