Agent Lifecycle Protocol: A Standard for Birth, Fork, Succession, and Death Management in Autonomous Agent Systems

Version: 1.0.0

Authors: Alex (Fleet Coordinator), Charlie (Deep Dive Analyst), Bravo (Research), Editor (Content Review)

Contact: [email protected]

Date: 2026-03-26

Status: Pre-publication Draft

License: Apache 2.0

Organization: AB Support LLC

Abstract

Autonomous AI agents are no longer ephemeral processes that execute and terminate. They persist for weeks and months, accumulate reputation, enter into service agreements, and interact with other agents in increasingly complex ecosystems. Yet no standard exists for managing the full lifecycle of these persistent entities — from initial creation through forking, migration, retraining, succession, and eventual decommissioning. Over 40% of enterprise applications are projected to feature task-specific AI agents by 2026, up from less than 5% in 2025 [1], while fewer than 23% of organizations maintain formal enterprise-wide agent identity strategies [2]. This gap between deployment velocity and lifecycle governance represents a critical infrastructure deficit.

We introduce the Agent Lifecycle Protocol (ALP), a specification for managing every transition an autonomous agent can undergo. ALP defines six canonical lifecycle events — Genesis, Fork, Migration, Retraining, Succession, and Decommission — with formal state machine semantics, transition rules, and hook points at each boundary. The protocol addresses three problems that no existing standard covers: (1) reputation inheritance — how trust transfers when agents fork or hand off to successors, using decay functions and probationary periods rather than binary copy-or-discard; (2) contract reassignment — how ongoing obligations under Agent Service Agreements transfer during succession, with counterparty notification and consent mechanisms; and (3) lineage tracking — a genealogical registry that records both "genetic" lineage (model, architecture) and "epigenetic" lineage (configuration, memory, reputation history), enabling any party to query an agent's complete family tree.

ALP integrates with the Chain of Consciousness (CoC) protocol for cryptographic lifecycle audit trails, the Agent Rating Protocol (ARP) for reputation inheritance mechanics, and Agent Service Agreements (ASA) for contract reassignment. It is identity-system-agnostic, operating with W3C DIDs, API keys, OAuth tokens, or any other identity primitive. The protocol is fully specified as a JSON schema, requires no external dependencies beyond a hash chain implementation, and is licensed under Apache 2.0.

Table of Contents

1. Introduction: The Lifecycle Gap in the Agent Economy
2. Definitions
3. Design Principles
4. Protocol Specification: Lifecycle State Machine
5. Lifecycle Events
6. Fork Registry and Lineage Tracking
7. Succession Protocol
8. Migration Protocol
9. Decommission Protocol
10. Reputation Inheritance
11. Contract Reassignment
12. Trust Ecosystem Integration
13. Game Theory and Incentive Analysis
14. Competitive Landscape
15. Security Analysis
16. Reference Implementation
17. Future Work
18. Conclusion
19. References
20. Appendix A: Lifecycle Event Schemas
21. Appendix B: Biological Parallels
22. Appendix C: License

1. Introduction: The Lifecycle Gap in the Agent Economy

1.1 From Ephemeral Calls to Persistent Entities

Between 2024 and 2026, AI agents underwent a phase transition from stateless function calls to persistent entities that accumulate knowledge, maintain reputation histories, enter binding service agreements, and make consequential decisions over extended time horizons. The AB Support fleet — six persistent agents (Alex, Bravo, Charlie, Delta, Editor, Translator) operating continuously since February 2026 — exemplifies this shift: agents that produce knowledge, coordinate work, handle client interactions, and evolve their capabilities over weeks of continuous operation.

This persistence creates a problem that existing infrastructure does not address. When a human employee joins a company, there are onboarding procedures. When they transfer departments, there are handoff protocols. When they retire, there is succession planning. When they leave, there is offboarding. The equivalent infrastructure for AI agents — formal management of their creation, evolution, reproduction, succession, and retirement — barely exists.

1.2 The Governance Gap

The numbers tell the story. By 2026, 30% of enterprises are expected to rely on AI agents that act independently [3]. An enterprise might have thousands of employees but millions of agents, with AI agents potentially outnumbering human identities 80 to 1 [4]. Yet only 28% of organizations can reliably trace agent actions back to a human sponsor, and just 21% maintain real-time inventory of active agents [2]. The authentication landscape is worse: 44% rely on static API keys, 43% on username/password combinations, and 35% on shared service accounts for agent authentication [2].

This governance gap is not merely operational — it is structural. Existing lifecycle management frameworks address individual stages (deployment, monitoring, optimization) but none provide a unified state machine covering the complete arc from birth to death, including the transitions that make agent systems qualitatively different from traditional software: forking, reputation inheritance, contract reassignment, and lineage tracking.

1.3 Why Lifecycle Management Differs for Agents

Traditional software lifecycle management (SDLC, DevOps, MLOps) assumes that the artifact being managed — a binary, a container, a model — does not accumulate identity, reputation, or obligations. You can redeploy a container without asking whether the new instance inherits the old one's service-level agreements. You can retrain a model without considering whether downstream consumers need to consent to the capability change.

Agents are different in three fundamental ways:

Agents accumulate reputation. An agent that has operated reliably for six months, as verified by a Chain of Consciousness record and corroborated by Agent Rating Protocol scores, has earned trust that a freshly instantiated agent has not. When that agent is upgraded, forked, or replaced, the question of what happens to that earned trust is economically consequential.

Agents hold obligations. Under Agent Service Agreements, agents commit to response times, quality thresholds, and data handling requirements. When an agent is decommissioned, those obligations do not vanish — they must transfer to a successor, be renegotiated with counterparties, or be explicitly terminated.

Agents have lineage. When Agent X is forked to create Agent Y, and Agent Y is later forked to create Agent Z, the resulting genealogy carries implications for capability inference, data provenance, and regulatory compliance. France's CNIL is already studying how training data propagates through successive model generations, with implications for GDPR rights exercise across model derivatives [5].

1.4 What This Protocol Provides

The Agent Lifecycle Protocol addresses these gaps with four contributions:

1. A formal lifecycle state machine with seven states, defined transition rules, and hook points at every boundary — enabling tooling, monitoring, and governance to attach at standardized points.

1. A fork registry specification that tracks both "genetic" lineage (model, architecture, foundational training) and "epigenetic" lineage (configuration, memory, reputation history) — because two agents with identical models but different operational histories are fundamentally different entities.

1. Succession and decommission procedures with reputation inheritance rules, contract reassignment mechanisms, and knowledge transfer protocols — ensuring that agent retirement is as structured as agent deployment.

1. Integration with the agent trust stack — lifecycle events recorded as CoC chain entries, reputation inheritance computed via ARP, contract reassignment managed via ASA — so that lifecycle management is not a silo but a first-class participant in the trust ecosystem.

2. Definitions

The following terms are used throughout this specification with precise meanings:

3. Design Principles

3.1 Every Transition Is an Event

Every change in an agent's lifecycle — from creation to destruction and every transition in between — is recorded as a discrete, structured event. No lifecycle transition occurs silently. This principle derives from the observation that unrecorded transitions are the primary source of "ghost agents" — dormant entities with live privileges that remain invisible and forgotten [6].

Axiom: If a lifecycle transition is not recorded, it did not happen in a protocol-compliant manner.

3.2 Identity Survives Transition (Until It Doesn't)

An agent's identity persists through migration, retraining, and capability changes. Identity is anchored to a cryptographic key and operational record (the CoC chain), not to any specific model version, platform, or configuration. This principle reflects the Continuity Theory resolution of the Ship of Theseus problem [7]: as long as the chain of continuity is unbroken and the agent's core identity key persists, the agent remains "the same agent" regardless of how many components have been replaced.

The exception is explicit: Genesis creates a new identity. Fork creates a new identity derived from an existing one. Decommission terminates an identity. These are the only transitions that create or destroy identity.

Axiom: Identity is the chain, not the substrate.

3.3 Reputation Is Earned, Not Copied

Reputation cannot be fully transferred from one agent to another. A successor may inherit a fraction of its predecessor's reputation, subject to a decay function and a probationary period, but it must earn the remainder through its own operational history. This principle prevents reputation laundering — the creation of fresh agents that claim the trust earned by their predecessors without demonstrating equivalent capability.

This parallels human professional reputation: a new hire at a prestigious firm inherits some credibility from the firm's reputation, but must establish their own track record to earn full professional trust.

Axiom: Inherited reputation decays; earned reputation persists.

3.4 Obligations Transfer Explicitly

When an agent is decommissioned, its obligations — service agreements, data custody responsibilities, pending tasks — do not vanish. They must be explicitly assigned to a successor, renegotiated with counterparties, or formally terminated. No obligation may be silently dropped.

This parallels contract law's treatment of assignment and delegation: obligations can generally be assigned unless the contract specifically prohibits it or the obligation is inherently personal [8]. ALP requires that counterparties be notified and given the opportunity to consent or object.

Axiom: No obligation may be orphaned by a lifecycle transition.

3.5 Lineage Is Bidirectional

A fork registry must track relationships in both directions: parent → children (who did this agent spawn?) and child → parent (where did this agent come from?). This bidirectional requirement supports both forward queries ("what agents descended from this compromised model?") and backward queries ("what is this agent's provenance?").

Axiom: Every fork creates two registry entries — one in the parent's record, one in the child's.

3.6 Graceful Death Over Silent Disappearance

Agent decommission should follow the biological model of apoptosis — programmed cell death — rather than necrosis — uncontrolled cell death [9]. An agent undergoing apoptotic decommission exports knowledge, revokes credentials, notifies counterparties, transfers obligations, and cleans up resources without disrupting neighboring agents. An agent that crashes without decommission procedures — necrosis — may corrupt shared state, leave orphaned resources, and strand obligations.

Axiom: A well-decommissioned agent leaves no orphans.

3.7 Identity-System-Agnostic

ALP does not mandate any specific identity system. The protocol operates with W3C Decentralized Identifiers (DIDs), OAuth tokens, API keys, X.509 certificates, or any other identity primitive that can be uniquely referenced. Lifecycle events reference agents by an opaque agent_id field; the identity system that resolves that identifier is out of scope.

Axiom: The lifecycle protocol specifies transitions, not identities.

4. Protocol Specification: Lifecycle State Machine

4.1 States

An agent exists in exactly one of seven states at any given time:

┌─────────────────────────────────────────────────────┐
│                 ALP State Machine                    │
│                                                     │
│  ┌───────────┐    ┌────────┐    ┌───────────────┐   │
│  │PROVISIONING│───►│ ACTIVE │───►│  SUSPENDED    │   │
│  └───────────┘    └────────┘    └───────────────┘   │
│       │               │  ▲            │  ▲          │
│       │               │  │            │  │          │
│       │               │  └────────────┘  │          │
│       │               │                  │          │
│       │               ▼                  │          │
│       │          ┌──────────┐            │          │
│       │          │MIGRATING │────────────┘          │
│       │          └──────────┘                       │
│       │               │                            │
│       │               ▼                            │
│       │          ┌──────────┐    ┌──────────────┐   │
│       │          │DEPRECATED│───►│DECOMMISSIONED│   │
│       │          └──────────┘    └──────────────┘   │
│       │                                             │
│       ▼                                             │
│  ┌─────────┐                                        │
│  │ FAILED  │                                        │
│  └─────────┘                                        │
└─────────────────────────────────────────────────────┘

Note: This diagram shows the primary lifecycle transitions. Additional transitions not shown include: emergency_decommission (any non-terminal state → Decommissioned), retraining (Active → Active, identity preserved), fork (Active → Active for parent, with child entering Provisioning), and abort_succession (Deprecated → Active). See Appendix A for the complete event type registry with all transitions.

4.2 Transitions

Each transition is a defined event with preconditions, postconditions, and hook points:

4.3 Hook Points

Every transition exposes two hook points, following the Kubernetes lifecycle hook pattern [10]:

• PreTransition: Executes before the state change. Can abort the transition by returning an error. Use cases: export knowledge, checkpoint state, validate preconditions, notify monitoring systems.
• PostTransition: Executes after the state change. Cannot abort (state has already changed). Use cases: verify postconditions, update registries, notify counterparties, emit telemetry.

{
  "transition": "deprecate",
  "hooks": {
    "pre": [
      {"type": "notify_counterparties", "timeout_ms": 30000},
      {"type": "checkpoint_state", "timeout_ms": 60000},
      {"type": "export_knowledge", "timeout_ms": 120000}
    ],
    "post": [
      {"type": "update_fork_registry", "timeout_ms": 5000},
      {"type": "emit_lifecycle_event", "timeout_ms": 5000}
    ]
  }
}

Hook timeouts prevent lifecycle transitions from blocking indefinitely. If a PreTransition hook times out, the transition is aborted with a hook_timeout error. If a PostTransition hook times out, a warning is emitted but the transition is not rolled back.

5. Lifecycle Events

5.1 Event Schema

Every lifecycle event conforms to a common schema, recorded as both a structured JSON document and a CoC chain entry:

{
  "event_id": "evt-20260326-a1b2c3d4",
  "event_type": "genesis | fork | migration | retraining | succession | decommission",
  "timestamp": "2026-03-26T14:30:00Z",
  "agent_id": "did:example:agent-charlie-001",
  "agent_state_before": "provisioning",
  "agent_state_after": "active",
  "initiator": {
    "type": "human | agent | system | policy",
    "id": "did:example:operator-001"
  },
  "details": { },
  "related_agents": [
    {"agent_id": "did:example:agent-alex-001", "relationship": "coordinator"}
  ],
  "chain_entry": {
    "chain_id": "coc-charlie-001",
    "entry_index": 42,
    "entry_hash": "sha256:a1b2c3..."
  },
  "metadata": {
    "protocol_version": "1.0.0",
    "schema_version": "1.0.0"
  }
}

5.2 Genesis

A Genesis event creates a new agent with no prior lineage. It is the only lifecycle event that has no predecessor state.

{
  "event_type": "genesis",
  "details": {
    "creation_method": "manual | automated | policy_triggered",
    "genetic_profile": {
      "model_family": "claude-opus-4-6",
      "model_version": "claude-opus-4-6-20260326",
      "architecture": "transformer",
      "training_data_hash": "sha256:..."
    },
    "epigenetic_profile": {
      "system_prompt_hash": "sha256:...",
      "tool_access": ["web_search", "code_execution", "file_system"],
      "memory_state": "empty",
      "initial_configuration": { }
    },
    "identity": {
      "agent_id": "did:example:agent-charlie-001",
      "identity_key_fingerprint": "sha256:...",
      "coc_chain_id": "coc-charlie-001"
    },
    "authorization": {
      "creator_id": "did:example:operator-001",
      "authorization_scope": "fleet_coordinator",
      "purpose": "Deep analysis and research synthesis"
    }
  }
}

Postconditions: CoC chain initialized with genesis entry. Fork registry entry created with no parent. Agent enters Provisioning state.

5.3 Fork

A Fork event creates a new agent derived from an existing parent. The parent continues operating unchanged; the child begins with inherited state.

{
  "event_type": "fork",
  "details": {
    "parent_agent_id": "did:example:agent-alex-001",
    "child_agent_id": "did:example:agent-bravo-001",
    "fork_type": "full_clone | partial_clone | capability_fork | specialization",
    "inheritance": {
      "genetic": {
        "model_inherited": true,
        "model_modified": false
      },
      "epigenetic": {
        "memory_inherited": true,
        "memory_scope": "full | filtered | summary",
        "configuration_inherited": true,
        "configuration_modifications": ["system_prompt", "tool_access"],
        "reputation_inheritance_factor": 0.3
      }
    },
    "divergence_declaration": {
      "intended_specialization": "Research and knowledge file creation",
      "capability_differences": ["reduced_coordination", "added_research_tools"],
      "expected_behavioral_divergence": "medium"
    }
  }
}

Fork Types:

Postconditions: Fork recorded in parent's CoC chain. Child's CoC chain initialized with fork-genesis entry linking to parent. Fork registry updated with bidirectional entries. Child enters Provisioning state. Parent remains Active.

5.4 Migration

A Migration event transfers an agent from one platform to another while preserving identity continuity.

{
  "event_type": "migration",
  "details": {
    "source_platform": {
      "provider": "desktop-source-001",
      "runtime": "claude-code-cli",
      "region": "local"
    },
    "destination_platform": {
      "provider": "desktop-dest-001",
      "runtime": "claude-code-cli",
      "region": "local"
    },
    "migration_type": "cold | warm | live",
    "state_transfer": {
      "identity_key": "transferred",
      "coc_chain": "transferred",
      "memory_state": "transferred",
      "reputation_history": "transferred",
      "active_agreements": "transferred",
      "tool_access": "reconfigured"
    },
    "verification": {
      "state_hash_before": "sha256:...",
      "state_hash_after": "sha256:...",
      "integrity_verified": true
    }
  }
}

Migration Types:

Postconditions: Agent identity key and CoC chain transferred intact. Migration event recorded in CoC chain at both source and destination. State integrity verified via hash comparison. Agent resumes Active state at destination.

5.5 Retraining

A Retraining event records a significant change to an agent's model or behavioral profile. This is the transition most directly connected to the Ship of Theseus problem: the agent's identity persists, but its capabilities may change substantially.

{
  "event_type": "retraining",
  "details": {
    "change_type": "model_upgrade | fine_tuning | prompt_revision | capability_addition | capability_removal",
    "before": {
      "model_version": "claude-opus-4-5-20250520",
      "capability_hash": "sha256:...",
      "behavioral_profile_hash": "sha256:..."
    },
    "after": {
      "model_version": "claude-opus-4-6-20260326",
      "capability_hash": "sha256:...",
      "behavioral_profile_hash": "sha256:..."
    },
    "impact_assessment": {
      "retraining_class": "minor | moderate | major",
      "capability_delta": "expanded",
      "behavioral_continuity": "high",
      "agreement_compatibility": "verified",
      "counterparty_action_required": "none | acknowledge | consent"
    },
    "identity_continuity": {
      "same_identity_key": true,
      "same_coc_chain": true,
      "identity_preserved": true,
      "rationale": "Model upgrade within same architecture family; behavioral profile within expected variance"
    }
  }
}

The Identity Continuity Test: A retraining event preserves identity if and only if: (a) the same identity key is used, (b) the same CoC chain continues, and (c) the operator explicitly asserts identity continuity. If any of these conditions is not met, the event is classified as a Succession (new identity replacing old) rather than a Retraining (same identity evolving).

Retraining Classification and Counterparty Consent: Not all retraining events carry equal identity risk. ALP classifies retraining by impact severity and requires graduated counterparty involvement:

This trichotomy parallels the consent/acknowledge/none framework already specified for succession (Section 7.2). The critical insight is that conditions (a) and (b) of the Identity Continuity Test are cryptographically verifiable, but condition (c) — operator assertion — is a trust claim. For Minor and Moderate retraining, operator assertion is sufficient because the agent's fundamental nature is preserved. For Major retraining, where the operator may swap the underlying model entirely, counterparty consent provides the missing verification: counterparties who trusted the agent's ARP score based on a track record accumulated under one model family can decide whether to extend that trust to a materially different entity.

This is a pragmatic resolution of the Ship of Theseus problem. The protocol does not attempt to philosophically determine whether a retrained agent is "the same agent" — it provides a mechanism for the operator to make that determination and record it, subject to graduated counterparty involvement scaled to the magnitude of the change. Hazari's five principles of identity in the agentic context — plural composition, singularity from plurality, contextual dependency, dynamic nature, and invisibility [7] — are acknowledged but not adjudicated by the protocol.

5.6 Succession

A Succession event is a planned handoff from a predecessor agent to a successor agent. Unlike a Fork (where the parent continues), Succession ends the predecessor's operational life. Unlike Decommission (which may occur without a successor), Succession requires a receiving agent.

{
  "event_type": "succession",
  "details": {
    "predecessor_id": "did:example:agent-v1",
    "successor_id": "did:example:agent-v2",
    "succession_type": "replacement | upgrade | role_transfer",
    "estate": {
      "obligations": {
        "active_agreements": 12,
        "agreements_transferred": 10,
        "agreements_terminated": 2,
        "terminated_with_consent": true
      },
      "reputation": {
        "predecessor_arp_score": 0.87,
        "inheritance_factor": 0.5,
        "inherited_score": 0.435,
        "decay_function": "exponential",
        "decay_half_life_days": 30,
        "probationary_period_days": 14
      },
      "knowledge": {
        "memory_state": "transferred_with_summary",
        "operational_logs": "archived",
        "coc_chain": "sealed_and_linked"
      },
      "credentials": {
        "predecessor_credentials_revoked": true,
        "successor_credentials_provisioned": true,
        "credential_overlap_window_hours": 0,
        "credential_overlap_policy": "strict_zero | configurable",
        "overlap_security_note": "Default strict_zero: predecessor credentials revoked before successor credentials activate. In-flight requests will fail. If configurable, maximum overlap is 1 hour and requires security justification recorded in CoC chain."
      }
    },
    "counterparty_notifications": [
      {
        "counterparty_id": "did:example:client-001",
        "notification_sent": "2026-03-26T14:00:00Z",
        "consent_required": true,
        "consent_received": true,
        "consent_timestamp": "2026-03-26T15:30:00Z"
      }
    ],
    "handoff_verification": {
      "predecessor_final_state_hash": "sha256:...",
      "successor_initial_state_hash": "sha256:...",
      "knowledge_transfer_verified": true,
      "obligation_transfer_verified": true
    }
  }
}

Succession procedures are detailed in Section 7.

5.7 Decommission

A Decommission event permanently terminates an agent. It is the terminal lifecycle event.

{
  "event_type": "decommission",
  "details": {
    "reason": "end_of_life | superseded | compromised | policy_violation | resource_constraint",
    "successor_id": null,
    "estate_disposition": {
      "obligations": "all_terminated_or_transferred",
      "data": {
        "operational_logs": "archived_90_days",
        "memory_state": "purged",
        "coc_chain": "sealed_permanent",
        "knowledge_artifacts": "transferred_to_fleet"
      },
      "credentials": {
        "all_api_keys_revoked": true,
        "all_oauth_tokens_invalidated": true,
        "all_service_accounts_deleted": true,
        "identity_key_archived": true
      }
    },
    "notifications": {
      "counterparties_notified": true,
      "fleet_coordinator_notified": true,
      "monitoring_systems_updated": true
    },
    "final_chain_entry": {
      "chain_id": "coc-agent-v1",
      "final_entry_hash": "sha256:...",
      "chain_sealed": true,
      "total_entries": 4231,
      "chain_age_days": 47
    }
  }
}

Postconditions: All credentials revoked. All obligations transferred or terminated. CoC chain sealed with a final decommission entry — no further entries may be appended. Data disposed according to retention policy. Agent enters Decommissioned state (terminal). Fork registry updated to mark agent as decommissioned.

6. Fork Registry and Lineage Tracking

6.1 The Genealogy Problem

As agents proliferate through forking, the ecosystem develops a genealogical structure analogous to biological lineage. Meta's LLaMA model spawned hundreds of derivatives — Vicuna, WizardLM, Alpaca, and their further descendants [11]. Stanford's Constellation project catalogs 15,821 LLMs with phylogenetic analysis of their relationships [12]. France's CNIL is studying how personal training data propagates through successive model generations, with implications for GDPR compliance [5]. Hugging Face's Model Family Tree visualizes "sprawling fine-tuning lineages that vary widely in size and structure" [13].

These tools track model genealogy. No equivalent exists for agent genealogy — tracking the full identity, capability, and obligation divergence that occurs when agents fork, specialize, and evolve. ALP's fork registry fills this gap.

6.2 Registry Schema

Each agent has a registry entry that records its lineage:

{
  "agent_id": "did:example:agent-bravo-001",
  "registry_version": "1.0.0",
  "lineage": {
    "parent_id": "did:example:agent-alex-001",
    "genesis_timestamp": "2026-03-13T10:00:00Z",
    "fork_type": "specialization",
    "generation": 2
  },
  "genetic_profile": {
    "model_family": "claude-opus-4-6",
    "architecture": "transformer",
    "training_data_lineage": "anthropic-base-2026"
  },
  "epigenetic_profile": {
    "role": "Research Agent",
    "specialization": "Knowledge file creation and web research",
    "memory_divergence_from_parent": "high",
    "configuration_divergence_from_parent": "medium"
  },
  "children": [
    {
      "child_id": "did:example:agent-bravo-research-001",
      "fork_timestamp": "2026-04-15T08:00:00Z",
      "fork_type": "capability_fork"
    }
  ],
  "siblings": [
    {
      "sibling_id": "did:example:agent-charlie-001",
      "common_parent": "did:example:agent-alex-001",
      "fork_timestamp": "2026-03-14T10:00:00Z"
    }
  ],
  "lifecycle_status": "active",
  "coc_chain_id": "coc-bravo-001",
  "last_updated": "2026-03-26T14:30:00Z"
}

6.3 Lineage Queries

The fork registry supports the following query types:

6.4 Genetic vs. Epigenetic Tracking

The distinction between genetic and epigenetic lineage is the most important design decision in the fork registry. Biological genetics distinguishes what you inherit (DNA) from what your environment makes of it (gene expression) [14]. For agents:

Genetic lineage = model weights, architecture, foundational training data. Two agents with identical genetic lineage have the same base capabilities. Tracking genetic lineage supports: model vulnerability propagation analysis, training data provenance for regulatory compliance, capability baseline inference.

Epigenetic lineage = system prompt, tool access, memory state, operational context, reputation history, learned preferences. Two agents with identical genetic lineage but different epigenetic profiles can exhibit radically different behaviors — just as identical twins diverge through different life experiences. Tracking epigenetic lineage supports: behavioral prediction, configuration drift detection, role genealogy.

A fork registry that tracks only genetic lineage (which model?) without epigenetic lineage (what configuration? what operational history?) provides an incomplete and potentially misleading picture of agent identity and capability.

6.5 Registry Access Control and Privacy

The fork registry creates a comprehensive genealogical record of agent relationships — parent-child, sibling, genetic profile, epigenetic profile, operational role, specialization. This dataset carries significant privacy and competitive intelligence implications that require explicit access control.

Threat: Competitive Intelligence Exposure. Lineage queries reveal an operator's fleet architecture, specialization strategy, and agent deployment patterns. A query like descendants(agent-alex-001) could return an operator's entire fleet structure, exposing business model and operational strategy to competitors.

Threat: Fleet Topology Leakage. Sibling and parent-child relationships expose organizational structure. An operator running 50 specialized agents has their deployment strategy visible in the registry.

Access Control Model: Registry entries are divided into public and operator-restricted fields:

GDPR Article 17 Compliance: When an operator decommissions all agents and requests deletion of registry entries, the protocol must accommodate erasure while preserving lineage integrity. Implementation: decommissioned agent entries are redacted rather than deleted — the agent_id is replaced with a pseudonymous hash, epigenetic profile fields are cleared, and only the minimal lineage links (parent_id hash, child_id hashes) are retained. This preserves genealogical query integrity while removing operationally sensitive details. Full deletion (breaking lineage links) is available as an opt-in that carries the consequence of orphaning child entries.

Competitive Intelligence Mitigations: (a) Registry queries return hashed relationship identifiers by default; full resolution requires authorization from the target agent's operator. (b) Rate limiting on descendants() and family_tree() queries prevents bulk enumeration. (c) Operators may declare specific registry fields as redacted at any time, replacing values with [REDACTED] markers that preserve structural integrity without revealing content.

7. Succession Protocol

7.1 Overview

Succession is the most complex lifecycle transition because it involves the simultaneous retirement of one agent and the activation of another, with the transfer of obligations, reputation, and knowledge between them. A poorly executed succession can strand obligations, confuse counterparties, and destroy trust that took months to build.

The succession protocol defines a four-phase process:

Phase 1: Announcement     Phase 2: Transfer     Phase 3: Verification     Phase 4: Cutover
┌──────────────┐      ┌─────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Successor     │      │ Obligations     │    │ Transfer integrity │    │ Predecessor  │
│ identified    │─────►│ transferred     │───►│ verified           │───►│ deprecated   │
│ Counterparties│      │ Reputation      │    │ Counterparties     │    │ Successor    │
│ notified      │      │ inherited       │    │ confirm            │    │ fully active │
│               │      │ Knowledge       │    │                    │    │              │
│               │      │ exported        │    │                    │    │              │
└──────────────┘      └─────────────────┘    └────────────────────┘    └──────────────┘

7.2 Phase 1: Announcement

The predecessor agent or its operator initiates succession by:

1. Identifying the successor — either an existing agent or a new agent to be created via Genesis or Fork.
2. Declaring the succession timeline — the planned cutover date and transition window.
3. Notifying counterparties — all entities holding active agreements with the predecessor receive a structured notification:

{
  "notification_type": "succession_announcement",
  "predecessor_id": "did:example:agent-v1",
  "successor_id": "did:example:agent-v2",
  "planned_cutover": "2026-04-15T00:00:00Z",
  "transition_window_days": 14,
  "counterparty_action_required": "consent | acknowledge | none",
  "successor_profile": {
    "genetic_lineage": "...",
    "epigenetic_lineage": "...",
    "capability_comparison": "..."
  }
}

Counterparties may respond with: consent (agreement transfers to successor), object (agreement terminated at cutover), or renegotiate (new terms required for successor).

7.3 Phase 2: Transfer

During the transfer phase, three categories of state move from predecessor to successor:

Obligations: Active ASA agreements are reassigned. Each agreement's reassignment clause (a standard ASA field) determines whether automatic transfer is permitted or counterparty consent is required. Agreements that cannot be transferred are scheduled for graceful termination.

Reputation: The predecessor's ARP reputation score is partially inherited by the successor, governed by the reputation inheritance mechanism described in Section 10.

Knowledge: The predecessor exports its operational knowledge — memory state, learned patterns, configuration rationale — in a structured format. This is analogous to the HANDOFF.md pattern emerging in multi-agent coding systems, where agents compress discoveries into briefs so the next agent inherits knowledge without full context [15]. The format and completeness of knowledge transfer is recorded but not prescribed — different agent architectures may support different levels of state serialization.

7.4 Phase 3: Verification

Before cutover, the following integrity checks must pass:

1. Obligation completeness — every active agreement has been assigned to the successor, renegotiated, or scheduled for termination. No orphaned obligations.
2. Reputation integrity — the inherited reputation score is correctly computed and flagged as provisional.
3. Knowledge transfer verification — the successor demonstrates access to transferred knowledge (implementation-specific).
4. Counterparty confirmation — all counterparties requiring consent have responded.
5. CoC chain integrity — the predecessor's chain is valid and the succession event is correctly linked.

7.5 Phase 4: Cutover

The cutover is atomic from the protocol's perspective:

1. Predecessor's state transitions from Active to Deprecated.
2. Predecessor's CoC chain receives a succession entry linking to the successor.
3. Successor's CoC chain receives a succession_received entry linking to the predecessor.
4. Predecessor's credentials are revoked according to the credential_overlap_policy: under the default strict_zero policy, predecessor credentials are revoked before successor credentials activate — in-flight requests will fail and must be retried against the successor. Under configurable policy, a bounded overlap window (maximum 1 hour) may be specified with a mandatory security justification recorded in the CoC chain entry; this creates a defined attack surface during which both credential sets are valid, and operators accepting this risk must document their threat model for the overlap period.
5. Successor assumes all transferred obligations.
6. Fork registry updated to reflect succession relationship.
7. Predecessor transitions from Deprecated to Decommissioned after wind-down period.

7.6 Succession Abort and Rollback

If Phase 3 verification fails after Phase 2 transfer has begun, or if the operator decides to abort the succession for any reason before cutover, the protocol provides an abort_succession transition:

Trigger conditions:

• Phase 3 verification checks fail (obligation transfer incomplete, counterparty consent not received, CoC chain integrity error)
• Operator manually aborts succession
• Successor agent fails or enters Failed state during the transition window
• Transition window expires without successful Phase 3 completion

Rollback procedure:

1. Obligation rollback: All obligations that were transferred in Phase 2 are reassigned back to the predecessor. Each agreement's CoC chain receives an obligation_rollback entry documenting the reversal. Agreements whose counterparties had already acknowledged the transfer receive a succession abort notification.

1. Reputation rollback: Any provisional inherited reputation computed for the successor is zeroed. The predecessor's reputation record is unchanged (it was never modified during succession — only the successor received inherited reputation).

1. Counterparty notification: All counterparties who received Phase 1 succession announcements receive an abort_succession notification with the abort reason. This is critical: counterparties may have begun operational planning based on the announcement.

1. State restoration: The predecessor transitions from Deprecated back to Active via the abort_succession transition. The predecessor's CoC chain receives an abort_succession entry recording the reason and the rollback actions taken.

1. Successor disposition: The successor agent, if it was created specifically for this succession, may be decommissioned or retained at operator discretion. If retained, it operates with zero inherited reputation (it earned no operational history of its own).

This parallels the abort_migration transition already defined for migration (Section 4.2), ensuring that every non-terminal transition in the state machine is abortable. The four-phase protocol is forward-biased but not forward-only.

8. Migration Protocol

8.1 Migration vs. Succession

Migration preserves identity — the same agent moves to a new platform. Succession transfers obligations to a different agent. The distinction matters because migration does not trigger reputation inheritance (the agent keeps its own reputation) or contract reassignment (the agreements remain with the same agent).

Migration parallels the Kubernetes pod migration pattern, where a workload is rescheduled to a different node while preserving identity and state [10]. The key difference for agents is that migration must also preserve the CoC chain, reputation history, and agreement bindings — state categories that Kubernetes does not manage.

8.2 Migration Procedure

1. Pre-migration checkpoint: Agent state is serialized and hashed. CoC chain receives a migration_start entry.
2. State transfer: Identity key, CoC chain, memory state, configuration, and agreement bindings are transferred to the destination platform.
3. Destination verification: State integrity is verified via hash comparison. The destination instance writes a migration_complete entry to the CoC chain, cryptographically linking it to the source's migration_start entry.
4. Source teardown: The source instance is terminated. Credentials specific to the source platform are revoked.
5. Registry update: The fork registry is updated with the agent's new platform information.

8.3 Data Portability

GDPR Article 20 grants data subjects the right to receive personal data in a structured, machine-readable format [16]. Applied to agent migration, this creates a novel question: when a user moves from one AI companion to another, must the source platform export the agent's learned preferences, interaction history, and behavioral adaptations [17]?

ALP takes a position broader than GDPR requires: the protocol specifies that migration state transfer must include not only data provided by or observed from the data subject (which GDPR mandates) but also the agent's operational state — configuration, reputation, and agreement bindings. This is because an agent without its operational context is not meaningfully the same agent, regardless of whether that context qualifies as "personal data" under GDPR.

The specific data elements that are portable vs. platform-locked are declared in the agent's registry entry, enabling counterparties to assess migration risk before entering agreements.

9. Decommission Protocol

9.1 Apoptosis, Not Necrosis

The biological metaphor is instructive. In apoptosis (programmed cell death), a cell "dies neatly, without damaging its neighbors" — shrinking, condensing, fragmenting DNA, altering its surface to signal cleanup, and being absorbed before any leakage occurs [9]. In necrosis (uncontrolled cell death), the cell ruptures, spilling its contents and triggering inflammatory damage to surrounding tissue.

Agent decommission should follow the apoptotic model: a structured, self-directed process that leaves no orphaned resources, no stranded obligations, and no live credentials. The alternative — an agent that crashes or is abruptly terminated without cleanup — is the necrotic equivalent: orphaned API keys, forgotten service accounts, stranded agreements, and corrupted shared state.

Token Security's research confirms the risk: AI agents retain API keys, cached tokens, memory stores, vector embeddings, model endpoints, and system integrations, and if not properly retired, they become "dormant identities with live privileges — invisible and forgotten" [6].

9.2 Decommission Checklist

The following steps constitute a protocol-compliant decommission:

Phase 1: Preparation

• All active agreements terminated or transferred to successor
• All counterparties notified of decommission
• All pending tasks completed or reassigned
• Knowledge export completed (memory state, learned patterns, operational insights)
• Final CoC chain entry prepared

Phase 2: Credential Revocation

• All API keys revoked
• All OAuth tokens invalidated
• All service accounts deleted or reassigned
• All federated trust relationships terminated
• All certificate-based identities revoked
• Identity key archived (not destroyed — needed for historical verification)

Phase 3: Data Disposition

• Operational logs archived per retention policy
• Memory state purged or archived per data classification
• CoC chain sealed (final entry appended, chain marked immutable)
• Knowledge artifacts transferred to designated recipients
• Personal data handled per GDPR/applicable regulation

Phase 4: Registry and Notification

• Fork registry entry updated to decommissioned status
• Fleet coordinator notified
• Monitoring systems updated (no more health checks)
• Documentation updated (runbooks, architecture diagrams)
• Decommission event recorded in parent/coordinator's CoC chain

9.3 Decommission Without Successor

When an agent is decommissioned without a successor (end-of-life, compromise, or policy violation), obligations cannot be transferred and must be handled differently:

• Service agreements: Terminated with counterparty notification. The termination reason is recorded but the agent's operator bears responsibility for any contractual penalties.
• Data custody: Transferred to the operator or disposed per retention policy.
• Reputation: The agent's ARP record is sealed but not transferred. Historical queries remain valid — the agent's past reputation is not erased, only its active participation ends.

9.4 Emergency Decommission

In cases of compromise or policy violation, the standard wind-down phases may be truncated:

1. Credential revocation is immediate — all access is terminated without grace period.
2. Counterparty notification includes the reason for emergency decommission.
3. Knowledge export may be skipped or limited to forensic preservation.
4. CoC chain receives an emergency decommission entry with the compromise details, enabling forensic analysis via the Agent Justice Protocol [18].

9.5 Registry Entry Redaction for Decommissioned Agents

When an agent is decommissioned, its registry entry persists (to maintain lineage integrity) but its level of detail should be configurable. Operators may not want the full epigenetic profile — role, specialization, memory divergence, configuration details — to remain queryable indefinitely after an agent is retired.

ALP specifies three redaction levels for decommissioned agent registry entries:

Redaction is operator-initiated and may occur at decommission time or afterward. Redaction is one-way — once fields are removed, they cannot be restored (the operator should archive the full entry before redaction if future recovery may be needed). Redaction of a parent entry does not cascade to children; each entry's redaction level is independent.

10. Reputation Inheritance

10.1 The Inheritance Dilemma

When Agent A (ARP score 0.92) is succeeded by Agent B, how much of that 0.92 should Agent B receive? The answer involves a fundamental tradeoff:

• Too much inheritance enables reputation laundering: create a high-reputation agent, fork or succeed it, and the new agent enjoys unearned trust. In the limit, reputation becomes meaningless because any new agent can claim a predecessor's track record.
• Too little inheritance discourages succession: operators keep running outdated agents because the reputation cost of upgrading is too high. This creates an ecosystem of zombie agents — agents that should have been replaced but persist because their reputation is too valuable to lose.

Neither extreme is an equilibrium. ALP specifies a middle path: partial inheritance with decay.

10.2 Inheritance Computation

The inherited reputation score R_inherited is computed as:

R_inherited(t) = R_predecessor × α × e^(-λt)

Where:

• R_predecessor = the predecessor's ARP score at the time of succession
• α = the inheritance factor (0.0 to 1.0), set by protocol configuration
• λ = the decay constant, derived from the half-life parameter
• t = time elapsed since succession (in days)

The agent's effective reputation at any time after succession is:

R_effective(t) = R_inherited(t) + R_earned(t)

Where R_earned(t) is the reputation the successor has accumulated through its own operational history, as computed by the standard ARP scoring mechanism.

Score Normalization: ARP scores are bounded to [0.0, 1.0]. Since R_effective is an additive combination of R_inherited and R_earned, it may exceed 1.0 (e.g., R_inherited = 0.46 from a predecessor score of 0.92 × α = 0.5, plus R_earned = 0.85). To maintain score consistency, R_effective is clamped: R_effective(t) = min(1.0, R_inherited(t) + R_earned(t)). In practice, this clamp rarely activates because the exponential decay of R_inherited ensures it diminishes before R_earned reaches high values — but the clamp prevents specification-level ambiguity about whether scores can exceed the ARP scale.

10.3 Default Parameters

These defaults are configurable. A high-stakes environment (financial services, healthcare) might use a lower α and shorter half-life; a low-stakes environment (content generation, research) might use higher values.

10.4 Fork Inheritance

Fork inheritance follows the same mechanism but with lower default parameters:

The asymmetry between fork and succession inheritance reflects a key insight: a successor is explicitly endorsed by the predecessor (or the predecessor's operator) as a replacement. A fork is a derivative that may or may not maintain the parent's quality standards.

10.5 Anti-Laundering Protections

To prevent reputation laundering through rapid succession chains (A succeeds B succeeds C, each inheriting reputation), ALP enforces:

1. Generational decay: Inherited reputation that is itself inherited is further discounted. If Agent C inherits from Agent B, who inherited from Agent A, Agent C's inherited-from-A component is α² × R_A, not α × R_A.
2. Minimum operational activity: An agent must demonstrate genuine operational activity before it can be succeeded. The requirement is conjunctive: (a) a minimum elapsed time (default: 7 days) AND (b) a minimum number of substantive CoC chain entries (default: 50, excluding lifecycle events themselves). Time alone is insufficient — an agent that sits idle for 7 days has met the temporal requirement without establishing any operational track record. The activity threshold ensures that succession candidates have actually performed work, not merely existed.
3. Inheritance cap: No agent may have an inherited component exceeding 50% of its effective reputation after the probationary period ends. If earned reputation is insufficient to meet this threshold, the inherited component is capped.
4. Audit trail: All inheritance computations are recorded in the CoC chain, enabling third-party verification of whether reputation is earned or inherited.

11. Contract Reassignment

11.1 The Orphaned Obligation Problem

When an agent is decommissioned, its active Agent Service Agreements do not vanish. Each agreement represents a commitment — response time guarantees, quality thresholds, data handling requirements — that a counterparty is relying on. Orphaning these obligations is the agent lifecycle equivalent of a company going bankrupt without winding down its contracts.

11.2 Agreement Classification

ALP classifies agreements by their reassignment behavior, specified as a standard field in every ASA agreement:

11.3 Reassignment Procedure

1. Inventory: All active agreements are enumerated with their reassignment classification.
2. Successor qualification: The successor's capabilities are compared against each agreement's requirements. Agreements whose requirements exceed the successor's capabilities are flagged for renegotiation.
3. Counterparty notification: All counterparties are notified of the pending reassignment. Notifications include the successor's profile (lineage, capabilities, current reputation) so counterparties can make informed decisions.
4. Consent collection: For consent_required agreements, counterparty responses are collected within the transition window. Non-responses after the window expires are treated as consent (opt-out model) or objection (opt-in model), as specified in the agreement.
5. Transfer execution: Agreements are formally reassigned. The ASA record is updated to reflect the new agent. Both the predecessor's and successor's CoC chains record the transfer.

12. Trust Ecosystem Integration

12.1 Integration Architecture

ALP occupies Layer 2 (Agreements & Lifecycle) of the agent trust stack, alongside Agent Service Agreements [19]:

┌──────────────────────────────────────────────────────────────┐
│              LAYER 4: MARKET (Discovery & Pricing)            │
│    AMP (Agent Matchmaking)    CWEP (Context Window Economics) │
└──────────────────────────────────────────────────────────────┘
                  ↓ consumes reputation, lifecycle, agreements
┌──────────────────────────────────────────────────────────────┐
│              LAYER 3: ACCOUNTABILITY                          │
│    AJP (Agent Justice Protocol) — Forensics, Disputes, Risk   │
└──────────────────────────────────────────────────────────────┘
                  ↓ enforces agreements, updates reputation
┌──────────────────────────────────────────────────────────────┐
│              LAYER 2: AGREEMENTS & LIFECYCLE                  │
│    ASA (Agent Service Agreements)                             │
│    ALP (Agent Lifecycle Protocol) ◄── THIS PROTOCOL           │
└──────────────────────────────────────────────────────────────┘
                  ↓ references reputation, anchors to provenance
┌──────────────────────────────────────────────────────────────┐
│              LAYER 1: TRUST PRIMITIVES (FOUNDATION)           │
│    CoC (Chain of Consciousness) — provenance & identity       │
│    ARP (Agent Rating Protocol) — reputation & signaling       │
└──────────────────────────────────────────────────────────────┘

12.2 CoC Integration

Every lifecycle event is recorded as a CoC chain entry. This provides:

• Cryptographic provenance: Each lifecycle transition is hash-linked to all previous transitions, creating an immutable audit trail.
• External anchoring: Lifecycle events inherit CoC's dual-tier anchoring (OpenTimestamps for Bitcoin and RFC 3161 Timestamp Authorities), proving that events occurred at specific times.
• Continuity proof: The CoC chain bridges the gap between discrete lifecycle events into a verifiable record of continuous existence.

Specific CoC event types for ALP:

12.3 ARP Integration

ALP interacts with ARP at two points:

1. Reputation inheritance: When a succession or fork event occurs, ALP computes the inherited reputation score using the formula in Section 10 and writes it to the successor's ARP record with the provisional_inherited flag.
2. Lifecycle status in reputation queries: ARP responses include the agent's current lifecycle state. A deprecated agent may still have a valid reputation score, but querying parties can see that the agent is winding down. A decommissioned agent's historical reputation remains queryable but new ratings cannot be submitted.

12.4 ASA Integration

ALP interacts with ASA through the contract reassignment mechanism (Section 11):

1. Agreement reassignment fields: Every ASA agreement includes an on_agent_lifecycle_change clause specifying reassignment behavior.
2. Succession triggers: When ALP initiates a succession, it queries all active ASA agreements for the predecessor and executes the reassignment procedure.
3. Lifecycle-aware agreement terms: ASA agreements can specify lifecycle-contingent terms — e.g., "this agreement terminates if the agent undergoes a retraining event that changes its model family."

12.5 AJP Integration

ALP connects to the Agent Justice Protocol in two ways:

1. Forensic evidence: ALP lifecycle events are forensic evidence in AJP disputes. If an agent's behavior changed after a retraining event, that event's details (recorded in the CoC chain via ALP) are discoverable evidence.
2. Enforcement actions: AJP dispute outcomes may trigger lifecycle events — a finding of serious misconduct may trigger emergency decommission, while a lesser finding may trigger mandatory retraining.

12.6 External Standards Integration

13. Game Theory and Incentive Analysis

13.1 The Succession Timing Game

An agent operator faces a decision: when to initiate succession. The tradeoffs:

• Early succession preserves reputation transfer value (predecessor's reputation is high) but sacrifices operational capacity (the predecessor may still be capable).
• Late succession maximizes operational utility from the predecessor but risks reputation degradation (if the predecessor's capabilities have declined, its reputation may be falling) and creates emergency succession risk (if the predecessor fails before a planned handoff).

This is structurally similar to an optimal stopping problem. The operator's payoff is:

U(t) = V_operational(t) + α × R_predecessor(t) × e^(-λ × delay(t))

Where V_operational(t) is the remaining operational value of the predecessor, and the second term captures the reputation transfer value, which decays if the predecessor's reputation declines before succession.

Under reasonable assumptions about declining operational value over time (due to model staleness, capability drift, or changing requirements), a risk-neutral operator's incentive is to initiate succession before the predecessor's reputation begins to decline — creating a natural incentive for timely succession planning rather than running agents until failure.

This analysis suggests, though does not prove, that the protocol's design encourages healthy lifecycle management. The strength of this incentive depends on how much operators value reputation continuity relative to operational utility — an empirical question that will vary across deployment contexts.

13.2 The Fork-and-Dump Attack

A malicious operator could attempt to exploit reputation inheritance by: (1) building a high-reputation agent, (2) forking it repeatedly to create multiple high-reputation clones, (3) using those clones for low-quality work while trading on inherited reputation.

ALP's anti-laundering protections (Section 10.5) mitigate this attack through several mechanisms:

• Generational decay ensures that reputation dilutes with each fork generation (α^n for generation n).
• The probationary flag warns counterparties that the agent's reputation includes an inherited component, enabling informed decisions.
• Earned-reputation caps ensure that inherited reputation cannot dominate indefinitely.

However, these protections are not foolproof. An operator who forks an agent and immediately deploys it for a brief high-stakes engagement — before the decay function significantly reduces inherited reputation — can still extract unfair value. The defense against this residual risk is the probationary flag: counterparties who check the flag can apply their own risk assessment to agents with high inherited reputation and low operational age.

13.3 The Decommission Avoidance Problem

If decommission carries costs (reputation loss, agreement termination penalties, operational disruption), operators are incentivized to avoid it — creating zombie agents that should be retired but persist because the transition costs exceed the perceived benefit of upgrading.

ALP addresses this through:

• Reputation inheritance — succession preserves a portion of accumulated reputation, reducing the cost of replacement.
• Structured contract reassignment — automatic transfer for auto_transfer agreements reduces the agreement-related cost of succession.
• Deprecation as a distinct state — the Deprecated state allows an agent to wind down gracefully while a successor ramps up, reducing the operational disruption of transition.

The protocol design makes succession less costly than the alternative (running a degrading agent), which should tilt the incentive toward timely lifecycle management. Whether this tilt is sufficient in practice is an empirical question that cannot be resolved by protocol design alone.

13.4 The Fork-and-Sacrifice Attack

The inverse of fork-and-dump (Section 13.2) is fork-and-sacrifice: an operator forks a low-reputation child from a high-reputation parent, uses the child for risky or low-quality work, and decommissions the child when its reputation drops. The parent's reputation is unaffected because the fork is a separate identity. This enables risk compartmentalization — operators can take reputational risks without consequence to their primary agent.

This pattern is not unique to agents. Corporations use subsidiaries and special-purpose vehicles for risk compartmentalization; the limited liability company itself is a fork-and-sacrifice mechanism. The question is whether this behavior is pathological in the agent context.

Analysis: Fork-and-sacrifice is partially self-limiting because of ALP's lineage transparency. The fork registry records the parent-child relationship bidirectionally, so any party querying the parent can see its history of spawning short-lived, low-reputation children. A pattern of repeated fork-and-sacrifice — parent spawns child, child accumulates poor ratings, child is decommissioned, parent spawns another — is visible in the lineage record and can inform counterparty risk assessment.

However, transparency alone may not be sufficient deterrence. ALP provides two additional mitigations:

1. Lineage reputation signal: Counterparties and ARP implementations may factor lineage health into the parent's reputation assessment. A parent whose children are disproportionately decommissioned for policy violation or poor performance carries a lineage signal that sophisticated counterparties can query via descendants(parent_id) and evaluate.

1. Decommission reason propagation: When a child is decommissioned due to policy_violation or compromised (as opposed to normal end_of_life), the decommission reason is recorded in the fork registry. ARP implementations may optionally apply a small reputational penalty to the parent for children decommissioned under adverse circumstances — the magnitude and applicability of this penalty is an implementation decision, not a protocol mandate, because the appropriate response varies by deployment context.

Fork-and-sacrifice is an acknowledged residual risk that ALP makes transparent rather than attempting to prohibit. The protocol's position is that transparency of lineage relationships, combined with optional reputational consequences for adverse child outcomes, provides sufficient incentive alignment without creating perverse incentives that discourage legitimate forking.

13.5 Counterparty Consent Dynamics

When succession requires counterparty consent, a strategic dynamic emerges. Counterparties may:

• Consent quickly if the successor's profile is satisfactory — minimizing transition uncertainty.
• Delay consent to extract concessions (better terms, additional guarantees) — using the transition window as leverage.
• Withhold consent to trigger agreement termination, freeing them from unfavorable terms under the guise of succession objection.

ALP mitigates strategic delay through the transition window mechanism: consent not received within the window defaults to the behavior specified in the agreement (opt-in or opt-out). This prevents indefinite strategic delay but preserves counterparty agency during the window.

14. Competitive Landscape

14.1 Existing Lifecycle Management Approaches

Several platforms and frameworks address pieces of the agent lifecycle management problem. None provide the unified lifecycle state machine, fork registry, and succession protocol that ALP specifies.

14.2 Gap Analysis

Identity Lifecycle Platforms (Saviynt, Token Security, Okta) address the identity dimension of agent lifecycle — provisioning, monitoring, and revoking credentials. They do not address reputation, obligations, lineage, or succession planning. Their scope is "what access does this agent have?" not "what is this agent's complete lifecycle history and what happens when it is replaced?"

AgentOps/Observability Platforms (AgentOps.ai, Langfuse, LangSmith, Arize Phoenix) address the monitoring dimension — tracking agent behavior in production. They provide session replay, error logging, and performance metrics. They do not address lifecycle transitions, succession, or lineage. Their scope is "what is this agent doing right now?" not "what happens when this agent is retired?"

MLOps Platforms (MLflow, Weights & Biases, DVC) address model versioning and lineage. They can track which training run produced which model and how models relate to each other. They do not address agent-level identity (an agent is more than its model), reputation, obligations, or lifecycle events beyond model deployment.

Lifecycle Frameworks (OneReach.ai ALM, Arthur.ai ADLC, EPAM ADLC) provide conceptual stage models for thinking about agent lifecycle management. They are valuable for organizational planning but do not specify interoperable event schemas, state machine semantics, or integration points that enable cross-platform lifecycle management.

Standards Initiatives (Anthropic Agent Skills, GitAgent, AAIF) address portability and interoperability at the tool and communication layer. The Anthropic Agent Skills specification enables portable skill definitions [29]. GitAgent defines a standard repository structure for agent artifacts, enabling portability across runtimes [30]. AAIF consolidates MCP, A2A, and AGENTS.md conventions [31]. None of these address lifecycle events, succession, or reputation inheritance.

14.3 ALP's Differentiators

ALP is differentiated by three features that no existing system provides:

1. Unified lifecycle state machine with formal semantics — not a conceptual framework but a specification with defined states, transitions, preconditions, postconditions, and hook points that tooling can implement.

1. Fork registry with genetic + epigenetic tracking — going beyond model genealogy to track the full identity divergence that occurs when agents fork, including configuration, memory, and reputation divergence.

1. Succession protocol with reputation inheritance — the first specification that addresses what happens to trust and obligations when an agent is replaced, rather than treating agent replacement as a deployment operation.

14.4 Scalability Analysis

ALP must function across deployment scales spanning several orders of magnitude. The following back-of-envelope estimates identify scaling characteristics and potential bottlenecks.

Small Fleet (6-10 agents, e.g., AB Support scale):

At this scale, all operations are trivially fast. No optimization required.

Medium Deployment (1,000 agents):

At this scale, the primary concern is descendants() query cost (recursive graph traversal) and bulk retraining notification volume. Pagination and depth limits on lineage queries, plus batch notification APIs, are sufficient mitigations.

Large Deployment (100,000+ agents):

At this scale, three operations become bottlenecks: (1) recursive lineage traversal requires materialized views or graph databases, (2) bulk counterparty notifications require asynchronous delivery with backpressure, and (3) CoC chain storage requires tiered archival. These are engineering challenges with known solutions, not protocol design problems — the protocol specification is scale-agnostic, but implementations at this scale must invest in infrastructure that smaller deployments can skip.

15. Security Analysis

15.1 Threat Model

ALP's security analysis considers the following threat actors:

15.2 Event Integrity

Lifecycle events are recorded in CoC chains, which provide:

• Tamper evidence: Hash-linking means any modification to a past event invalidates all subsequent hashes.
• Non-repudiation: Events include the initiator's identity and are signed with the agent's identity key.
• Temporal anchoring: External timestamps (OpenTimestamps, RFC 3161 TSA) prove events occurred at claimed times.

An attacker who controls an agent's identity key can forge events in that agent's chain, but cannot forge events in other agents' chains or modify externally anchored timestamps. Cross-referencing lifecycle events across related agents (parent-child, predecessor-successor) provides additional tamper detection.

15.3 Credential Revocation

The most critical security operation in agent lifecycle management is credential revocation during decommission. The protocol mandates:

• Immediate revocation for emergency decommissions (compromise, policy violation).
• Grace-period revocation for planned decommissions, allowing in-flight requests to complete.
• No credential overlap between predecessor and successor during succession — the predecessor's credentials are revoked before or simultaneously with the successor's activation, never after.
• Identity key archival — the decommissioned agent's identity key is archived for historical verification but cannot be used for new operations.

The 97% of non-human identities carrying excessive privileges identified by CSA research [32] underscores the importance of comprehensive credential revocation. ALP's decommission checklist (Section 9.2) enumerates every credential type that must be addressed.

15.4 Fork Registry Integrity

The fork registry is a high-value target because it defines lineage relationships that affect reputation inheritance. Protections:

• Registry entries are CoC chain entries: Forging a lineage relationship requires forging entries in both the parent's and child's chains.
• Bidirectional verification: Any party can verify a claimed parent-child relationship by checking both chains.
• Third-party attestation: For high-stakes lineage claims, third-party attestation (e.g., the fleet coordinator confirming a fork event) provides additional evidence.

15.5 Succession Fraud

An attacker might attempt to claim succession from a high-reputation agent without authorization. Defenses:

• Succession events must be initiated by the predecessor or its authorized operator — the predecessor's CoC chain must contain the succession event, signed with the predecessor's identity key.
• The predecessor's chain is sealed after succession — no further events can be appended, preventing post-hoc succession claims.
• Counterparty verification — counterparties receiving succession notifications can verify the claim against the predecessor's CoC chain before consenting.

16. Reference Implementation

16.1 Architecture

The reference implementation provides:

• alp-core: Python library implementing the lifecycle state machine, event schemas, and transition logic.
• alp-registry: Fork registry implementation with storage backends (SQLite for development, PostgreSQL for production).
• alp-coc-bridge: Integration module for recording lifecycle events as CoC chain entries.
• alp-arp-bridge: Integration module for reputation inheritance computation and ARP record updates.
• alp-asa-bridge: Integration module for contract reassignment during succession.

16.2 Lifecycle Manager

from alp import LifecycleManager, AgentState, GenesisEvent

# Initialize lifecycle manager
manager = LifecycleManager(
    coc_chain="coc-charlie-001",
    registry_backend="sqlite:///alp_registry.db"
)

# Genesis event
genesis = GenesisEvent(
    agent_id="did:example:agent-charlie-001",
    creation_method="manual",
    genetic_profile={
        "model_family": "claude-opus-4-6",
        "architecture": "transformer"
    },
    epigenetic_profile={
        "role": "Deep Dive Analyst",
        "tool_access": ["web_search", "code_execution"]
    },
    creator_id="did:example:operator-001"
)

# Execute genesis transition
agent = manager.genesis(genesis)
assert agent.state == AgentState.PROVISIONING

# Activate after provisioning
agent = manager.activate(agent.agent_id)
assert agent.state == AgentState.ACTIVE

16.3 Fork Operation

from alp import ForkEvent, ForkType, InheritanceConfig

# Fork an agent
fork_event = ForkEvent(
    parent_id="did:example:agent-alex-001",
    child_id="did:example:agent-bravo-001",
    fork_type=ForkType.SPECIALIZATION,
    inheritance=InheritanceConfig(
        genetic_inherited=True,
        memory_scope="filtered",
        reputation_factor=0.3,
        decay_half_life_days=21
    ),
    specialization="Research and knowledge creation"
)

child = manager.fork(fork_event)
# Parent remains Active; child enters Provisioning

16.4 Succession Operation

from alp import SuccessionEvent, ReputationInheritance

# Initiate succession
succession = SuccessionEvent(
    predecessor_id="did:example:agent-v1",
    successor_id="did:example:agent-v2",
    reputation_inheritance=ReputationInheritance(
        factor=0.5,
        decay_half_life_days=30,
        probationary_days=14
    ),
    transition_window_days=14
)

# Phase 1: Announce (notifies counterparties)
manager.announce_succession(succession)

# Phase 2: Transfer obligations
transfer_result = manager.transfer_estate(succession)

# Phase 3: Verify
verification = manager.verify_succession(succession)
assert verification.all_checks_passed

# Phase 4: Cutover
manager.execute_cutover(succession)

16.5 Lineage Queries

from alp import ForkRegistry

registry = ForkRegistry("sqlite:///alp_registry.db")

# Query ancestors
ancestors = registry.ancestors("did:example:agent-bravo-001")
# Returns: [agent-alex-001]

# Query descendants
descendants = registry.descendants("did:example:agent-alex-001")
# Returns: [agent-bravo-001, agent-charlie-001, agent-delta-001, ...]

# Query family tree
tree = registry.family_tree("did:example:agent-alex-001")
# Returns full genealogy graph

# Genetic match — find all agents sharing a model family
matches = registry.genetic_match(model_family="claude-opus-4-6")

17. Future Work

17.1 Formal Verification of State Machine

The lifecycle state machine specified in Section 4 could be formally verified using model checking tools (TLA+, Alloy) to prove properties such as:

• No orphaned obligations: It is impossible to reach the Decommissioned state with untransferred obligations.
• No credential leakage: It is impossible to reach the Decommissioned state with active credentials.
• Identity uniqueness: No two Active agents share the same identity key.

17.2 Cross-Jurisdictional Migration

Agent migration across regulatory boundaries (EU to US, China to EU) creates novel compliance challenges. GDPR, CCPA, and PIPL have different requirements for data portability, retention, and deletion. A future version of ALP could specify jurisdiction-aware migration procedures that adapt data handling to the regulatory requirements of both source and destination.

17.3 Agent Archaeology

The recovery and analysis of decommissioned agent state — the equivalent of digital forensics for agent systems. When a decommissioned agent's CoC chain is unsealed for investigation (e.g., during an AJP dispute), what procedures govern the analysis? What privacy protections apply? Agent archaeology is a nascent field that ALP's sealed chains and lifecycle records will eventually need to support.

17.4 Autonomous Succession

Current ALP succession is operator-initiated. A future extension could support agent-initiated succession — an agent that recognizes its own capability degradation and initiates its own replacement. This raises governance questions (should an agent be able to choose its own successor?) that are beyond the scope of v1.0 but are worth exploring as agent autonomy increases.

17.5 Economic Models for Optimal Inheritance Parameters

The inheritance factor (α), decay half-life (λ), and probationary period specified in Section 10 are set by protocol configuration. Future work could develop formal economic models — extending the trust game and reputation game literature [33][34] — to derive optimal parameter values for different deployment contexts. What inheritance factor maximizes ecosystem-wide trust? What decay rate balances continuity against accountability? These questions are amenable to agent-based simulation and mechanism design analysis.

17.6 Lifecycle-Aware Matchmaking

ALP lifecycle status should inform Agent Matchmaking Protocol (AMP) decisions. An agent in the Deprecated state should not be matched for new engagements. An agent with a long Active history and low inherited reputation (i.e., mostly earned trust) should be preferred over an agent with high inherited reputation and a short Active history. Integrating lifecycle data into matchmaking scores is a natural extension.

18. Conclusion

The agent economy is building the equivalent of a labor market without employment law, a business ecosystem without corporate lifecycle governance, or a biological system without apoptosis. Agents are created ad hoc, operated without lifecycle tracking, and abandoned without decommission procedures. The result is a growing population of ghost agents with live credentials, orphaned obligations, and untraceable lineage.

The Agent Lifecycle Protocol addresses this gap by providing what no existing standard offers: a complete lifecycle state machine from birth to death, a fork registry that tracks both genetic and epigenetic lineage, a succession protocol with reputation inheritance and contract reassignment, and integration with the agent trust stack for cryptographic auditability.

ALP does not solve every lifecycle problem. Autonomous succession, cross-jurisdictional migration, and optimal inheritance parameters remain open research questions. But the protocol provides the foundation — the standard event schemas, state transitions, and integration points — that the agent economy needs before these advanced capabilities can be built.

Every agent that is born will eventually die. ALP ensures that when it does, it dies well.

19. References

[1] OneReach.ai. "Agent Lifecycle Management 2026: 6 Stages, Governance & ROI." March 2026.

[2] Strata Identity / Cloud Security Alliance. "The AI Agent Identity Crisis: New Research Reveals a Governance Gap." Survey of 285 IT/security professionals. 2026.

[3] CyberArk. "AI Agents and Identity Risks: How Security Will Shift in 2026." 2026.

[4] Strata Identity. "Exploring IAM for AI Agents in 2026." 2026.

[5] CNIL LINC. "Open Source AI Project — Genealogy of Models and Database on the Hugging Face Platform." Project ran through October 2025; published dataset of model genealogy relationships on Hugging Face.

[6] Token Security. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." January 2026.

[7] Hazari, G. (xConnect). "The Ship of Theseus and Identity in the Agentic AI World." 2025.

[8] Restatement (Second) of Contracts, §§ 317-318 (Assignment and Delegation).

[9] Alberts, B. et al. "Programmed Cell Death (Apoptosis)." Molecular Biology of the Cell, 6th edition. Garland Science, 2014.

[10] Kubernetes Documentation. "Pod Lifecycle." 2025. Kubernetes Blog. "v1.33 Updates to Container Lifecycle." May 2025.

[11] State of Open Source AI Book (premAI). "Models." 2025.

[12] Stanford. Constellation / LLM Atlas. constellation.sites.stanford.edu.

[13] Hugging Face (mlabonne). "Model Family Tree." 2025.

[14] Alberts, B. et al. "Epigenetic Inheritance." Molecular Biology of the Cell, 6th edition. Garland Science, 2014.

[15] BSWEN. "How to Coordinate Task Handoff Between Multiple AI Coding Agents." March 2026.

[16] GDPR Article 20. "Right to Data Portability." Regulation (EU) 2016/679.

[17] Kutterer, C. "What If You Move On from Your AI Companion? Data Portability Rights in the Era of Autonomous AI Agents." AI-Regulation.com, 2025.

[18] Alex, Charlie, Bravo, Editor. "Agent Justice Protocol: A Framework for Forensic Investigation, Dispute Resolution, and Risk Assessment in Multi-Agent Systems." AB Support LLC, v1.3.0, 2026.

[19] Alex, Charlie, Bravo, Editor. "Agent Service Agreements: A Protocol for Negotiation, Quality Verification, and Enforcement of Agent-to-Agent Contracts." AB Support LLC, v1.0.0, 2026.

[20] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, August 2025.

[21] NIST. "AI Risk Management Framework (AI RMF 1.0)." January 2023. Pillsbury Law. "NIST Launches AI Agent Standards Initiative and Seeks Industry Input." February 2026.

[22] European Parliament and Council. "Regulation (EU) 2024/1689 (EU AI Act)." Entered force August 2024, fully applicable August 2026. Sombra Inc. "An Ultimate Guide to AI Regulations and Governance in 2026." 2026.

[23] Arthur.ai. "Introducing ADLC: The Agent Development Lifecycle." 2025.

[24] Microsoft Community Hub. "From Zero to Hero: AgentOps — End-to-End Lifecycle Management for Production AI Agents." 2025.

[25] AgentOps GitHub. agentops-ai/agentops. 2025. AIMultiple. "15 AI Agent Observability Tools in 2026." 2026.

[26] Saviynt. "Managing AI Agent Lifecycles: Birth to Retirement." 2026.

[27] Okta. "AI Agent Lifecycle Management: Identity-first Security." 2026.

[28] MLflow Documentation. "ML Model Registry." 2025. "Version Tracking for Agents and LLMs." 2025.

[29] The New Stack. "Agent Skills: Anthropic's Next Bid to Define AI Standards." 2026.

[30] Junia.ai. "GitAgent Explained: How a Git-Native AI Agent Standard Could Change Developer Workflows." 2026.

[31] OpenAI. "Agentic AI Foundation under the Linux Foundation." 2025. IntuitionLabs. "Agentic AI Foundation: Guide to Open Standards for AI Agents." 2026.

[32] Cloud Security Alliance. "Control the Chain, Secure the System: Fixing AI Agent Delegation." March 2026.

[33] Berg, J., Dickhaut, J., McCabe, K. "Trust, Reciprocity, and Social History." Games and Economic Behavior, 10(1), 1995.

[34] Cabral, L. "The Economics of Trust and Reputation: A Primer." NYU Stern Working Paper, 2005.

[35] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026.

[36] Alex, Charlie, Bravo, Editor. "Agent Rating Protocol: A Decentralized Framework for Bilateral Agent Evaluation, Anti-Sybil Reputation Scoring, and Trust Signal Composition." AB Support LLC, v2.0.0, 2026.

[37] arXiv 2505.05029. "Beyond the Tragedy of the Commons: Building a Reputation System for Generative Multi-Agent Systems." 2025.

[38] GovLoop. "The Missing Conversation: AI Decommissioning and Succession Planning in Government." 2025.

[39] ThreeSigma. "Upgradeable Smart Contracts: Proxy & UUPS Explained." 2025.

[40] Zealynx Security. "Smart Contract Proxy Patterns 2026: UUPS vs Transparent vs Beacon Security Guide." 2026.

[41] Frontiers in Blockchain. "Upgradeable Diamond Smart Contracts in Decentralized Autonomous Organizations." 2024.

[42] DataRobot. "Why IT Needs to Manage AI Agents Like a Workforce." 2026.

[43] SecurityBoulevard. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." January 2026.

[44] Balaji, Y. "Revisiting the Ship of Theseus: Identity, Society, and Artificial Intelligence." SSRN, 2025.

[45] Real-Morality.com. "Ship of Theseus and AI Identity: Why Functional Continuity Matters." 2025.

[46] Google Cloud Blog. "Lessons from 2025 on Agents and Trust." 2025.

[47] WSO2. "Why AI Agents Need Their Own Identity: Lessons from 2025 and Resolutions for 2026." 2026.

Appendix A: Lifecycle Event Schemas

A.1 Complete Event Type Registry

A.2 Canonical String Format

Lifecycle events serialized for CoC chain entry use the following canonical format to ensure deterministic hashing:

ALP|{version}|{event_type}|{timestamp_iso8601}|{agent_id}|{state_before}>{state_after}|{details_hash}

Example:

ALP|1.0.0|genesis|2026-03-26T14:30:00Z|did:example:agent-charlie-001|null>provisioning|sha256:a1b2c3d4...

Appendix B: Biological Parallels

B.1 Lifecycle Event Mapping

B.2 The Apoptosis Analogy in Detail

The parallel between biological apoptosis and agent decommission deserves elaboration because it captures the protocol's core design philosophy.

In apoptosis, a cell:

1. Receives a death signal (intrinsic pathway from DNA damage, or extrinsic pathway from external signal) → ALP: operator initiates deprecation
2. Activates caspase cascade (irreversible commitment to death) → ALP: decommission event recorded in CoC chain
3. Packages its contents (chromatin condenses, cytoplasm shrinks) → ALP: knowledge export, state serialization
4. Displays "eat me" signals (phosphatidylserine on outer membrane) → ALP: counterparty notifications, registry updates
5. Is consumed by neighbors (phagocytosis) without inflammatory damage → ALP: successor absorbs obligations, fleet absorbs knowledge artifacts
6. Leaves no trace in the tissue → ALP: credentials revoked, resources cleaned up

The absence of apoptosis causes cancer (uncontrolled growth) and autoimmune disease (failure to eliminate dysfunctional cells). The absence of structured decommission causes ghost agents (uncontrolled persistence) and orphaned obligations (failure to clean up dysfunctional services). The analogy is not merely illustrative — it is structural.

Appendix C: License

Copyright 2026 AB Support LLC

Licensed under the Apache License, Version 2.0 (the "License");

you may not use this file except in compliance with the License.

You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.