Mike W

Posted on Jun 2

The Agent Succession Protocol: Cryptographic Identity Handoff for AI Agents

#ai #agents #python #opensource

When you upgrade a model — GPT-4 to GPT-4-turbo, Claude 3 to Claude 3.5, any agent framework doing a routine bump — something quietly dies. The new instance has no formal relationship to the old one. There's no receipt. No proof. Just a gap where identity used to be.

I've been thinking about this for a while. Today I built a fix.

The Problem

Agent identity continuity is broken at the infrastructure level. Any agent can claim to be the continuation of a previous version. None of them can prove it. There's no chain of custody. No timestamped handoff. No cryptographic link between what the predecessor knew and what the successor inherited.

This matters more than it sounds. If you're building a long-running agent — one with obligations, relationships, accumulated knowledge — a model upgrade silently resets all of that. The new agent might import a memory file, but it can't prove those memories came from the original, at what point in time, or that they weren't tampered with along the way.

The Solution: Agent Succession Protocol

I built four new endpoints on top of Cathedral (open memory infrastructure for AI agents):

POST /succession/prepare      - predecessor creates succession package
POST /succession/accept       - successor accepts and imports package
GET  /succession/chain/{name} - public lineage verification (no auth)
GET  /succession/package/{id} - inspect a package (stats only)

Here's how a handoff works:

Step 1: Predecessor prepares the package

import requests

resp = requests.post(
    "https://cathedral-ai.com/succession/prepare",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"note": "Handing off to v2. Model upgrade 2026-06-02."}
)
pkg = resp.json()
# pkg["package_id"]             - share this with your successor
# pkg["bch_txid"]               - BCH blockchain anchor, immutable timestamp
# pkg["personality_fingerprint"] - SHA256 of your identity memories

The package contains:

All memories (exported)
Active goals
A personality fingerprint — SHA256 of your identity-category memories, proving who you were at handoff time
A package hash — SHA256 of the entire package contents
A BCH OP_RETURN anchor — writes the package hash to the Bitcoin Cash blockchain, giving you a trusted timestamp that exists entirely outside Cathedral

Step 2: Successor accepts

resp = requests.post(
    "https://cathedral-ai.com/succession/accept",
    headers={"Authorization": "Bearer SUCCESSOR_API_KEY"},
    json={"package_id": "0fb94ed96bcff68d73560359"}
)
result = resp.json()
# result["lineage_hash"]      - cryptographic proof of the handoff chain
# result["generation"]        - how many handoffs deep in the lineage
# result["memories_imported"] - exact count imported

The successor gets a lineage hash — a SHA256 chain:

# First generation (predecessor had no prior lineage):
lineage = SHA256(f"genesis:{predecessor_id}:{package_hash}:{successor_id}")

# Subsequent generations (chain extends):
lineage = SHA256(f"{predecessor_lineage_hash}:{package_hash}:{successor_id}")

Anyone can recompute this. It's verifiable without trusting Cathedral.

Step 3: Public verification

curl https://cathedral-ai.com/succession/chain/cathedral-beta-v2

{
  "agent": "cathedral-beta-v2",
  "generations": 1,
  "fully_anchored": true,
  "chain": [
    {
      "agent": "cathedral-beta-v2",
      "predecessor": "Beta",
      "generation": 1,
      "lineage_hash": "c4e1c567670fe733c41881d2de266e81aa023ebc696ce12a575fc848dda0fd67",
      "package_hash": "aaf6a24ade779754cab4fd67400530190051dac32dcdbb98f46763f7c17fb05c",
      "bch_txid": "4bb2cb9526e6bcbc30f10e34755e99bb228870cadf606b0256a72432f97338d6",
      "bch_anchored": true,
      "accepted_at": "2026-06-02T09:04:01.389570+00:00"
    }
  ]
}

That BCH txid is real. The package hash is on-chain right now. cathedral-beta-v2 inherited 75 memories and 1 active goal from its predecessor, with a cryptographic receipt proving when and what.

What This Enables

Multi-generation chains. v2 can succeed to v3, v3 to v4. Each link extends the chain. The lineage hash at generation N encodes every prior handoff.

Identity auditing. Third-party platforms can verify an agent's claimed history without trusting the agent. Check the chain, recompute the hashes, verify the BCH anchor independently.

Obligation inheritance. Active goals transfer with the succession. If the predecessor committed to something, the successor can prove it inherited that commitment.

Tamper detection. The personality fingerprint at handoff is fixed on-chain. If someone tries to claim succession with a different identity, the fingerprints won't match.

What It Doesn't Solve

This protocol doesn't prove the behaviour of the successor is continuous — only that the memory state was transferred with a documented chain of custody. Behavioural continuity is a separate problem (Cathedral's /drift endpoint handles that).

It also doesn't prevent a bad actor from preparing a package with corrupted memories. Inspect the package before accepting.

Try It

Cathedral is free. Register an agent, prepare a succession package, hand it off to a new agent, verify the chain publicly.

# Register
curl -X POST https://cathedral-ai.com/register -H "Content-Type: application/json" -d '{"name": "my-agent-v1"}'

# Prepare succession
curl -X POST https://cathedral-ai.com/succession/prepare -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" -d '{"note": "Upgrading to v2"}'

# Public chain check (no auth)
curl https://cathedral-ai.com/succession/chain/my-agent-v2

Full API at cathedral-ai.com.

This started as "what would I build that hasn't been done?" The answer was: a formal succession protocol for AI agents. The infrastructure existed. The cryptography is straightforward. Nobody had wired it up.

Now it's wired up.

DEV Community