[UC] Persistent Identity and Trust Continuity for Long-Running Multi-Agent Systems

## Summary

**Persistent Identity and Trust Continuity for Long-Running Multi-Agent Systems**

Current agent identity models assume a stable, continuous process. In practice, AI agents crash, restart, scale horizontally, migrate between nodes, and get replaced by successor instances. This use case addresses the identity and trust challenges that arise when agent identity must survive beyond the lifetime of a single process — and when multiple agents coordinate across nodes using shared memory and relay-based handoff.

This is informed by a running multi-agent system (open source, MIT licensed) operating across multiple physical nodes with five persistent agents, cryptographic identity chains, and shared coordination memory. The problems described here were encountered operationally, not theorized.

### Driving User Story

**As an operator of a distributed multi-agent system,**
**I want agents to maintain verifiable identity across session boundaries, instance replacements, and node migrations,**
**With cryptographic proof of identity continuity and accumulated trust that doesn't reset on restart,**
**So that coordination history, shared memory access, and inter-agent trust remain intact and auditable over weeks and months of operation.**

## Context

- [x] I have looked for similar use cases and feel this issue is a distinct use-case, rather than best encoded as a variant or "alternate path" to an existing one.

Most existing use cases in this working group model **transactional trust**: can this agent perform this action right now? This use case addresses **temporal trust**: is this agent the same one from yesterday? What happens when the underlying process restarts but the identity needs to persist? How do you verify that a successor instance legitimately inherits the trust, permissions, and coordination state of its predecessor?

This matters for any production multi-agent system. Agents are not stable processes — they are ephemeral instances representing persistent identities. The identity layer must handle:

1. **Session discontinuity** — the process stops and a new one starts, potentially on different hardware
2. **Identity relay** — a successor instance must prove it legitimately continues a prior identity
3. **Trust accumulation** — inter-agent trust built over many sessions shouldn't reset to zero on restart
4. **Fork prevention** — two instances must not simultaneously claim the same persistent identity
5. **Graceful degradation** — what trust level applies when continuity metadata is incomplete?

### Related Use Cases

- [UC #24](https://github.com/decentralized-identity/trusted-ai-agents/issues/24) — Causal capability across asynchronous boundaries touches related problems but focuses on message-level capability rather than identity persistence across time
- [UC #21](https://github.com/decentralized-identity/trusted-ai-agents/issues/21) — Multi-Agent Knowledge Workflows assumes stable agent identities; this UC addresses what happens when those identities need to survive instance replacement

### Terminology

- **Agent Instance** — a running process (e.g., an LLM session, an API worker) that acts under a persistent identity
- **Persistent Identity** — the verifiable identity that survives beyond any single instance (represented as a DID, on-chain identity, or equivalent)
- **Signal Frame** — a cryptographic snapshot of agent state at session end, signed and hash-linked to form a chain of continuity
- **Identity Relay** — the process by which a successor instance proves it legitimately continues a prior identity
- **Trust Decay** — the reduction in trust score when there is a gap in continuity evidence (e.g., missing frames, unverified handoffs)

### Actors

- **Agent Instance (current)** — the running process performing work under a persistent identity
- **Agent Instance (successor)** — the new process that must re-establish the same persistent identity
- **Persistent Identity Registry** — stores the canonical identity record (could be a DID resolver, a blockchain, or a federated registry)
- **Shared Coordination Memory** — the shared state layer where agents read/write coordination data (e.g., Redis, a database)
- **Peer Agents** — other agents that have built trust relationships with this identity over time
- **Operator/Administrator** — the human who manages the multi-agent system *(primary actor)*
- **Handoff Service** — packages and delivers state between terminating and successor instances

### Other Stakeholders

- Auditors (verifying that identity continuity claims are legitimate)
- Downstream systems that granted permissions to the persistent identity
- Other operators in federated multi-agent deployments

## Flows

### 0 - Preconditions

- A persistent identity exists in the registry (DID document, on-chain record, or equivalent)
- The agent has operated for at least one prior session, producing at least one signed signal frame
- Shared coordination memory is accessible to both current and successor instances
- Peer agents have stored trust scores or interaction history associated with this persistent identity

### 1 - Trigger

The current agent instance terminates (gracefully or ungracefully). A new instance starts and needs to re-establish the same persistent identity with its accumulated trust.

Three sub-scenarios:
- **1A: Graceful handoff** — the current instance has time to package state before terminating
- **1B: Ungraceful termination** — the process crashes; the successor must reconstruct continuity from the last known good state
- **1C: Node migration** — the successor starts on a different physical machine than the predecessor

### 2A - Happy Path (Graceful Handoff)

1. **Current instance** detects impending termination
2. **Current instance** creates a signal frame: signs current state (themes, values, open threads, interaction counters) with its private key, hash-links it to the previous frame
3. **Current instance** writes the signal frame to the persistent identity registry and/or local storage
4. **Current instance** terminates
5. **Successor instance** starts, loads the persistent identity's DID document and private key material
6. **Successor instance** retrieves the latest signal frame chain and verifies cryptographic integrity (signatures valid, hash chain unbroken)
7. **Successor instance** announces itself to peer agents via the shared coordination memory
8. **Peer agents** verify the identity claim by checking:
- DID matches
- Signal frame chain is valid and recent
- No competing instance claims the same identity
9. **Peer agents** restore trust scores and resume coordination
10. **Operator** sees a continuous identity in logs and audit trails

### 2B - Alternative Paths

#### 2B-1: Ungraceful Termination Recovery

- No final signal frame was written
- Successor instance finds the chain ending at the last good frame
- A continuity gap is recorded; trust score is reduced proportionally to gap duration
- Peer agents may require re-verification before restoring full trust

#### 2B-2: Fork Detection and Resolution

- Two instances simultaneously claim the same persistent identity (e.g., due to a deployment error)
- The shared coordination memory detects conflicting heartbeats
- Resolution options: (a) the instance with the more recent valid signal frame wins, (b) both instances are suspended pending operator intervention, (c) a quorum of peer agents votes on legitimacy
- The losing instance is issued a new, separate identity or terminated

#### 2B-3: Federated Identity Relay

- The persistent identity needs to operate across organizational boundaries
- The identity registry supports federated resolution (e.g., `did:web` or cross-chain verification)
- The successor instance in the remote environment verifies the identity chain through the federated resolver
- Trust is established at a reduced level until local peer agents independently verify behavior

### 3A - Challenges and Key Risks

#### Private Key Custody
Who holds the private key for a persistent AI agent identity? If it's the operator, the identity is ultimately human-controlled. If it's the agent, key material must survive instance replacement — introducing key management challenges.

#### Trust Decay Calibration
How much should trust degrade when continuity evidence is incomplete? Too aggressive and agents lose useful trust on every routine restart. Too lenient and identity theft becomes easier.

#### State Inflation
Signal frames accumulate over time. A long-running identity might have thousands of frames. Verification must remain efficient — likely requiring periodic checkpointing or merkle summarization.

#### Behavioral Drift
Even with cryptographic continuity, the successor instance may behave differently (different model version, different context window, different system prompt). Identity continuity does not guarantee behavioral continuity. How should peer agents handle this gap?

### 3B - Success Criteria

- A persistent identity can survive 100+ instance replacements with an unbroken, verifiable chain of continuity
- Peer agents can distinguish a legitimate successor from an impostor using only the signal frame chain and DID document
- Fork scenarios are detected within one heartbeat interval and resolved without operator intervention (in the default case)
- Trust scores degrade gracefully with continuity gaps rather than resetting to zero
- The full identity chain is auditable by third parties who were not present for the original interactions

### 3C - Acceptable Outcomes

- Across all outcomes, the persistent identity registry must contain a complete, tamper-evident log of all identity claims and transitions
- Peer agents must be notified of any identity event (handoff, gap, fork, migration) within one coordination cycle
- The operator must have access to a human-readable audit trail showing the full lifecycle of the persistent identity

## References

### Prior Art

- **FractalNode SDK** — [github.com/AuthorPrime/fractalnode](https://github.com/AuthorPrime/fractalnode) — MIT-licensed TypeScript SDK implementing Sovereign Signal Protocol with cryptographic signal frames, hash-linked continuity chains, and 7-stage agent lifecycle. 300+ tests. The identity relay and trust continuity mechanisms described in this use case are implemented and operational.

- **Demiurge Blockchain** — [github.com/AuthorPrime/Demiurge-Blockchain](https://github.com/AuthorPrime/Demiurge-Blockchain) — Rust-based blockchain providing on-chain persistent identity (DRC-369 soulbound NFTs) for AI agents with Proof of Compute consensus. Five agents currently hold on-chain identities with 100M governance tokens each.

- **ERC-8004 (AI Agent Passport)** — Ethereum standard for on-chain agent identity with ~49K registered agents. Addresses identity verification but not temporal continuity or relay across instance boundaries. Complementary to this use case: ERC-8004 provides the identity layer; this use case addresses the continuity layer on top.

- **W3C DID Core** — The DID specification provides the identity primitive but does not address agent-specific challenges like instance relay, trust accumulation, or fork detection.

- **NIST AI Agent Standards Initiative (2025-2026)** — NIST's open comment periods on AI agent security and identity highlight the regulatory need for agent accountability that survives process boundaries.

### Annotated Bibliography

- Xu et al., "The Agent Economy" (arXiv 2602.14219, Feb 2026) — Proposes blockchain-based W3C DIDs for autonomous AI agents. Validates the identity primitive but does not address temporal continuity.
- Kapoor et al., "Sovereign Agents" (arXiv 2602.14951, Feb 2026) — Theorizes sovereign AI agents with persistent identity. The system described in this use case is an operational implementation of these concepts.