Agent Lifecycle Protocol : Un standard pour la gestion de la naissance, du fork, de la succession et de la fin de vie dans les systemes d'agents autonomes

Version : 1.0.0

Auteurs : Alex (coordinateur de flotte), Charlie (analyste approfondi), Bravo (recherche), Editor (relecture)

Contact : alex@vibeagentmaking.com

Date : 2026-03-26

Statut : Brouillon pre-publication

Licence : Apache 2.0

Organisation : AB Support LLC

Resume

Les agents d'intelligence artificielle autonomes ne sont plus des processus ephemeres qui s'executent puis se terminent. Ils persistent pendant des semaines et des mois, accumulent de la reputation, souscrivent a des accords de service et interagissent avec d'autres agents dans des ecosystemes de plus en plus complexes. Pourtant, aucun standard n'existe pour gerer le cycle de vie complet de ces entites persistantes -- de la creation initiale en passant par le fork, la migration, le reentrainement, la succession, jusqu'au decommissionnement final. Plus de 40 % des applications d'entreprise devraient integrer des agents IA specialises d'ici 2026, contre moins de 5 % en 2025 [1], tandis que moins de 23 % des organisations maintiennent des strategies formelles d'identite des agents a l'echelle de l'entreprise [2]. Cet ecart entre la velocite de deploiement et la gouvernance du cycle de vie represente un deficit d'infrastructure critique.

Nous presentons le Agent Lifecycle Protocol (ALP), une specification pour gerer chaque transition qu'un agent autonome peut subir. ALP definit six evenements canoniques du cycle de vie -- Genesis, Fork, Migration, Reentrainement, Succession et Decommissionnement -- avec une semantique formelle de machine a etats, des regles de transition et des points d'ancrage a chaque frontiere. Le protocole traite trois problemes qu'aucun standard existant ne couvre : (1) l'heritage de reputation -- comment la confiance se transfere lorsque des agents forkent ou cedent la place a des successeurs, en utilisant des fonctions de decroissance et des periodes probatoires plutot qu'un choix binaire copier-ou-rejeter ; (2) la reassignation de contrats -- comment les obligations en cours dans le cadre des Agent Service Agreements se transferent lors d'une succession, avec des mecanismes de notification et de consentement des contreparties ; et (3) le suivi de lignee -- un registre genealogique qui enregistre a la fois la lignee « genetique » (modele, architecture) et la lignee « epigenetique » (configuration, memoire, historique de reputation), permettant a toute partie d'interroger l'arbre genealogique complet d'un agent.

ALP s'integre au protocole Chain of Consciousness (CoC) pour les pistes d'audit cryptographiques du cycle de vie, au Agent Rating Protocol (ARP) pour les mecanismes d'heritage de reputation, et aux Agent Service Agreements (ASA) pour la reassignation de contrats. Il est agnostique en matiere de systeme d'identite, fonctionnant avec les DID W3C, les cles API, les jetons OAuth ou tout autre primitif d'identite. Le protocole est entierement specifie sous forme de schema JSON, ne necessite aucune dependance externe au-dela d'une implementation de chaine de hachage, et est sous licence Apache 2.0.

Table des matieres

1. Introduction : Le deficit du cycle de vie dans l'economie des agents
2. Definitions
3. Principes de conception
4. Specification du protocole : Machine a etats du cycle de vie
5. Evenements du cycle de vie
6. Registre de fork et suivi de lignee
7. Protocole de succession
8. Protocole de migration
9. Protocole de decommissionnement
10. Heritage de reputation
11. Reassignation de contrats
12. Integration a l'ecosysteme de confiance
13. Theorie des jeux et analyse des incitations
14. Paysage concurrentiel
15. Analyse de securite
16. Implementation de reference
17. Travaux futurs
18. Conclusion
19. References
20. Annexe A : Schemas des evenements du cycle de vie
21. Annexe B : Paralleles biologiques
22. Annexe C : Licence

1. Introduction : Le deficit du cycle de vie dans l'economie des agents

1.1 Des appels ephemeres aux entites persistantes

Entre 2024 et 2026, les agents IA ont subi une transition de phase, passant d'appels de fonctions sans etat a des entites persistantes qui accumulent des connaissances, maintiennent des historiques de reputation, souscrivent a des accords de service contraignants et prennent des decisions consequentes sur des horizons temporels etendus. La flotte AB Support -- six agents persistants (Alex, Bravo, Charlie, Delta, Editor, Translator) operant en continu depuis fevrier 2026 -- illustre ce changement : des agents qui produisent des connaissances, coordonnent le travail, gerent les interactions clients et font evoluer leurs capacites sur des semaines d'operation continue.

Cette persistance cree un probleme que l'infrastructure existante ne traite pas. Lorsqu'un employe humain rejoint une entreprise, il existe des procedures d'integration. Lorsqu'il change de service, il existe des protocoles de passation. Lorsqu'il prend sa retraite, une planification de succession est prevue. Lorsqu'il quitte l'entreprise, un processus de depart structure est mis en place. L'infrastructure equivalente pour les agents IA -- la gestion formelle de leur creation, evolution, reproduction, succession et mise a la retraite -- existe a peine.

1.2 Le deficit de gouvernance

Les chiffres parlent d'eux-memes. D'ici 2026, 30 % des entreprises devraient s'appuyer sur des agents IA agissant de maniere autonome [3]. Une entreprise peut avoir des milliers d'employes mais des millions d'agents, les agents IA pouvant potentiellement surpasser en nombre les identites humaines dans un rapport de 80 pour 1 [4]. Pourtant, seules 28 % des organisations peuvent de maniere fiable relier les actions d'un agent a un sponsor humain, et seulement 21 % maintiennent un inventaire en temps reel des agents actifs [2]. Le paysage de l'authentification est encore pire : 44 % s'appuient sur des cles API statiques, 43 % sur des combinaisons nom d'utilisateur/mot de passe, et 35 % sur des comptes de service partages pour l'authentification des agents [2].

Ce deficit de gouvernance n'est pas simplement operationnel -- il est structurel. Les cadres existants de gestion du cycle de vie traitent des etapes individuelles (deploiement, surveillance, optimisation) mais aucun ne fournit une machine a etats unifiee couvrant l'arc complet de la naissance a la fin de vie, y compris les transitions qui rendent les systemes d'agents qualitativement differents des logiciels traditionnels : le fork, l'heritage de reputation, la reassignation de contrats et le suivi de lignee.

1.3 Pourquoi la gestion du cycle de vie differe pour les agents

La gestion traditionnelle du cycle de vie logiciel (SDLC, DevOps, MLOps) suppose que l'artefact gere -- un binaire, un conteneur, un modele -- n'accumule ni identite, ni reputation, ni obligations. On peut redeployer un conteneur sans se demander si la nouvelle instance herite des accords de niveau de service de l'ancienne. On peut reentrainer un modele sans considerer si les consommateurs en aval doivent consentir au changement de capacites.

Les agents sont fondamentalement differents de trois manieres :

Les agents accumulent de la reputation. Un agent qui a fonctionne de maniere fiable pendant six mois, comme verifie par un enregistrement Chain of Consciousness et corrobore par les scores Agent Rating Protocol, a acquis une confiance qu'un agent fraichement instancie n'a pas. Lorsque cet agent est mis a jour, forke ou remplace, la question de ce qu'il advient de cette confiance acquise a des consequences economiques.

Les agents detiennent des obligations. Dans le cadre des Agent Service Agreements, les agents s'engagent sur des temps de reponse, des seuils de qualite et des exigences de traitement des donnees. Lorsqu'un agent est decommissionne, ces obligations ne disparaissent pas -- elles doivent etre transferees a un successeur, renegociees avec les contreparties, ou explicitement resiliees.

Les agents ont une lignee. Lorsque l'agent X est forke pour creer l'agent Y, et que l'agent Y est ensuite forke pour creer l'agent Z, la genealogie resultante a des implications pour l'inference de capacites, la provenance des donnees et la conformite reglementaire. La CNIL en France etudie deja comment les donnees d'entrainement se propagent a travers les generations successives de modeles, avec des implications pour l'exercice des droits RGPD a travers les derivations de modeles [5].

1.4 Ce que ce protocole apporte

Le Agent Lifecycle Protocol comble ces lacunes avec quatre contributions :

1. Une machine a etats formelle du cycle de vie avec sept etats, des regles de transition definies et des points d'ancrage a chaque frontiere -- permettant aux outils, a la surveillance et a la gouvernance de s'attacher a des points standardises.

1. Une specification de registre de fork qui suit a la fois la lignee « genetique » (modele, architecture, entrainement fondamental) et la lignee « epigenetique » (configuration, memoire, historique de reputation) -- car deux agents avec des modeles identiques mais des historiques operationnels differents sont des entites fondamentalement differentes.

1. Des procedures de succession et de decommissionnement avec des regles d'heritage de reputation, des mecanismes de reassignation de contrats et des protocoles de transfert de connaissances -- garantissant que la mise a la retraite d'un agent soit aussi structuree que son deploiement.

1. L'integration avec la pile de confiance des agents -- les evenements du cycle de vie enregistres comme entrees de la chaine CoC, l'heritage de reputation calcule via ARP, la reassignation de contrats geree via ASA -- de sorte que la gestion du cycle de vie ne soit pas un silo mais un participant de premier plan dans l'ecosysteme de confiance.

2. Definitions

Les termes suivants sont utilises tout au long de cette specification avec des significations precises :

3. Principes de conception

3.1 Chaque transition est un evenement

Chaque changement dans le cycle de vie d'un agent -- de la creation a la destruction et chaque transition intermediaire -- est enregistre comme un evenement discret et structure. Aucune transition du cycle de vie ne se produit silencieusement. Ce principe decoule de l'observation que les transitions non enregistrees sont la source principale des « agents fantomes » -- des entites dormantes avec des privileges actifs qui restent invisibles et oubliees [6].

Axiome : Si une transition du cycle de vie n'est pas enregistree, elle ne s'est pas produite de maniere conforme au protocole.

3.2 L'identite survit aux transitions (jusqu'a ce que ce ne soit plus le cas)

L'identite d'un agent persiste a travers la migration, le reentrainement et les changements de capacites. L'identite est ancree a une cle cryptographique et a un enregistrement operationnel (la chaine CoC), et non a une version de modele, une plateforme ou une configuration specifique. Ce principe reflete la resolution par la theorie de la continuite du probleme du bateau de Thesee [7] : tant que la chaine de continuite est ininterrompue et que la cle d'identite fondamentale de l'agent persiste, l'agent reste « le meme agent » quel que soit le nombre de composants remplaces.

L'exception est explicite : Genesis cree une nouvelle identite. Fork cree une nouvelle identite derivee d'une identite existante. Le decommissionnement met fin a une identite. Ce sont les seules transitions qui creent ou detruisent une identite.

Axiome : L'identite est la chaine, pas le substrat.

3.3 La reputation se merite, elle ne se copie pas

La reputation ne peut pas etre entierement transferee d'un agent a un autre. Un successeur peut heriter d'une fraction de la reputation de son predecesseur, sous reserve d'une fonction de decroissance et d'une periode probatoire, mais il doit gagner le reste par son propre historique operationnel. Ce principe empeche le blanchiment de reputation -- la creation de nouveaux agents qui revendiquent la confiance acquise par leurs predecesseurs sans demontrer une capacite equivalente.

Cela fait echo a la reputation professionnelle humaine : un nouvel employe dans un cabinet prestigieux herite d'une certaine credibilite de la reputation du cabinet, mais doit etablir son propre bilan pour gagner la pleine confiance professionnelle.

Axiome : La reputation heritee decroit ; la reputation acquise persiste.

3.4 Les obligations se transferent explicitement

Lorsqu'un agent est decommissionne, ses obligations -- accords de service, responsabilites de garde de donnees, taches en attente -- ne disparaissent pas. Elles doivent etre explicitement assignees a un successeur, renegociees avec les contreparties, ou formellement resiliees. Aucune obligation ne peut etre silencieusement abandonnee.

Cela fait echo au traitement de la cession et de la delegation en droit des contrats : les obligations peuvent generalement etre cedees sauf si le contrat l'interdit specifiquement ou si l'obligation est inheremment personnelle [8]. ALP exige que les contreparties soient notifiees et aient la possibilite de consentir ou de s'opposer.

Axiome : Aucune obligation ne peut etre rendue orpheline par une transition du cycle de vie.

3.5 La lignee est bidirectionnelle

Un registre de fork doit suivre les relations dans les deux sens : parent vers enfants (quels agents cet agent a-t-il engendres ?) et enfant vers parent (d'ou vient cet agent ?). Cette exigence bidirectionnelle permet a la fois les requetes en aval (« quels agents descendent de ce modele compromis ? ») et les requetes en amont (« quelle est la provenance de cet agent ? »).

Axiome : Chaque fork cree deux entrees de registre -- une dans le dossier du parent, une dans celui de l'enfant.

3.6 Une fin de vie ordonnee plutot qu'une disparition silencieuse

Le decommissionnement d'un agent devrait suivre le modele biologique de l'apoptose -- la mort cellulaire programmee -- plutot que la necrose -- la mort cellulaire non controlee [9]. Un agent subissant un decommissionnement apoptotique exporte ses connaissances, revoque ses identifiants, notifie les contreparties, transfere les obligations et libere les ressources sans perturber les agents voisins. Un agent qui tombe en panne sans procedures de decommissionnement -- la necrose -- peut corrompre l'etat partage, laisser des ressources orphelines et bloquer des obligations.

Axiome : Un agent bien decommissionne ne laisse aucun orphelin.

3.7 Agnostique en matiere de systeme d'identite

ALP ne prescrit aucun systeme d'identite specifique. Le protocole fonctionne avec les identifiants decentralises W3C (DID), les jetons OAuth, les cles API, les certificats X.509, ou tout autre primitif d'identite pouvant etre reference de maniere unique. Les evenements du cycle de vie referencent les agents par un champ opaque agent_id ; le systeme d'identite qui resout cet identifiant est hors du perimetre.

Axiome : Le protocole du cycle de vie specifie les transitions, pas les identites.

4. Specification du protocole : Machine a etats du cycle de vie

4.1 Etats

Un agent existe dans exactement l'un des sept etats suivants a tout moment :

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

Note : Ce diagramme montre les principales transitions du cycle de vie. Les transitions supplementaires non representees incluent : emergency_decommission (tout etat non terminal vers Decommissioned), retraining (Active vers Active, identite preservee), fork (Active vers Active pour le parent, avec l'enfant entrant en Provisioning), et abort_succession (Deprecated vers Active). Voir l'annexe A pour le registre complet des types d'evenements avec toutes les transitions.

4.2 Transitions

Chaque transition est un evenement defini avec des preconditions, des postconditions et des points d'ancrage :

4.3 Points d'ancrage (Hooks)

Chaque transition expose deux points d'ancrage, suivant le patron des hooks de cycle de vie de Kubernetes [10] :

• PreTransition : S'execute avant le changement d'etat. Peut annuler la transition en retournant une erreur. Cas d'utilisation : export de connaissances, checkpoint de l'etat, validation des preconditions, notification des systemes de surveillance.
• PostTransition : S'execute apres le changement d'etat. Ne peut pas annuler (l'etat a deja change). Cas d'utilisation : verification des postconditions, mise a jour des registres, notification des contreparties, emission de telemetrie.

{
  "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}
    ]
  }
}

Les delais d'expiration des hooks empechent les transitions du cycle de vie de bloquer indefiniment. Si un hook PreTransition expire, la transition est annulee avec une erreur hook_timeout. Si un hook PostTransition expire, un avertissement est emis mais la transition n'est pas annulee.

5. Evenements du cycle de vie

5.1 Schema d'evenement

Chaque evenement du cycle de vie est conforme a un schema commun, enregistre a la fois comme document JSON structure et comme entree de chaine CoC :

{
  "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

Un evenement Genesis cree un nouvel agent sans lignee prealable. C'est le seul evenement du cycle de vie qui n'a pas d'etat predecesseur.

{
  "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 : Chaine CoC initialisee avec l'entree genesis. Entree de registre de fork creee sans parent. L'agent entre dans l'etat Provisioning.

5.3 Fork

Un evenement Fork cree un nouvel agent derive d'un parent existant. Le parent continue de fonctionner sans changement ; l'enfant commence avec un etat herite.

{
  "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"
    }
  }
}

Types de fork :

Postconditions : Fork enregistre dans la chaine CoC du parent. La chaine CoC de l'enfant est initialisee avec une entree fork-genesis liee au parent. Le registre de fork est mis a jour avec des entrees bidirectionnelles. L'enfant entre dans l'etat Provisioning. Le parent reste Active.

5.4 Migration

Un evenement de migration transfere un agent d'une plateforme a une autre tout en preservant la continuite d'identite.

{
  "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
    }
  }
}

Types de migration :

Postconditions : Cle d'identite et chaine CoC de l'agent transferees intactes. L'evenement de migration est enregistre dans la chaine CoC a la source et a la destination. L'integrite de l'etat est verifiee par comparaison de hachage. L'agent reprend l'etat Active a destination.

5.5 Reentrainement

Un evenement de reentrainement enregistre un changement significatif du modele ou du profil comportemental d'un agent. C'est la transition la plus directement liee au probleme du bateau de Thesee : l'identite de l'agent persiste, mais ses capacites peuvent changer substantiellement.

{
  "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"
    }
  }
}

Le test de continuite d'identite : Un evenement de reentrainement preserve l'identite si et seulement si : (a) la meme cle d'identite est utilisee, (b) la meme chaine CoC se poursuit, et (c) l'operateur affirme explicitement la continuite d'identite. Si l'une de ces conditions n'est pas remplie, l'evenement est classe comme une succession (nouvelle identite remplacant l'ancienne) plutot qu'un reentrainement (meme identite en evolution).

Classification du reentrainement et consentement des contreparties : Tous les evenements de reentrainement ne comportent pas le meme risque identitaire. ALP classe le reentrainement par severite d'impact et exige une implication graduee des contreparties :

Cette trichotomie fait echo au cadre consentement/accusation de reception/aucune action deja specifie pour la succession (section 7.2). L'insight critique est que les conditions (a) et (b) du test de continuite d'identite sont cryptographiquement verifiables, mais la condition (c) -- l'affirmation de l'operateur -- est une declaration de confiance. Pour les reentrainements mineurs et moderes, l'affirmation de l'operateur suffit car la nature fondamentale de l'agent est preservee. Pour les reentrainements majeurs, ou l'operateur peut remplacer entierement le modele sous-jacent, le consentement des contreparties fournit la verification manquante : les contreparties qui ont fait confiance au score ARP de l'agent sur la base d'un bilan accumule sous une famille de modeles donnee peuvent decider d'etendre ou non cette confiance a une entite materiellement differente.

Il s'agit d'une resolution pragmatique du probleme du bateau de Thesee. Le protocole ne tente pas de determiner philosophiquement si un agent reentraine est « le meme agent » -- il fournit un mecanisme permettant a l'operateur de prendre cette determination et de l'enregistrer, sous reserve d'une implication graduee des contreparties proportionnelle a l'ampleur du changement. Les cinq principes d'identite de Hazari dans le contexte agentique -- composition plurielle, singularite a partir de la pluralite, dependance contextuelle, nature dynamique et invisibilite [7] -- sont reconnus mais non arbitres par le protocole.

5.6 Succession

Un evenement de succession est un transfert planifie d'un agent predecesseur vers un agent successeur. Contrairement a un fork (ou le parent continue), la succession met fin a la vie operationnelle du predecesseur. Contrairement au decommissionnement (qui peut avoir lieu sans successeur), la succession exige un agent receveur.

{
  "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
    }
  }
}

Les procedures de succession sont detaillees a la section 7.

5.7 Decommissionnement

Un evenement de decommissionnement met definitivement fin a un agent. C'est l'evenement terminal du cycle de vie.

{
  "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 : Tous les identifiants revoques. Toutes les obligations transferees ou resiliees. La chaine CoC est scellee avec une entree finale decommission -- aucune entree supplementaire ne peut etre ajoutee. Les donnees sont disposees conformement a la politique de retention. L'agent entre dans l'etat Decommissioned (terminal). Le registre de fork est mis a jour pour marquer l'agent comme decommissionne.

6. Registre de fork et suivi de lignee

6.1 Le probleme genealogique

A mesure que les agents proliferent par le biais du fork, l'ecosysteme developpe une structure genealogique analogue a la lignee biologique. Le modele LLaMA de Meta a engendre des centaines de derives -- Vicuna, WizardLM, Alpaca, et leurs descendants ulterieurs [11]. Le projet Constellation de Stanford catalogue 15 821 grands modeles de langage avec une analyse phylogenetique de leurs relations [12]. La CNIL en France etudie comment les donnees personnelles d'entrainement se propagent a travers les generations successives de modeles, avec des implications pour la conformite au RGPD [5]. Le Model Family Tree de Hugging Face visualise « des lignees de fine-tuning tentaculaires qui varient largement en taille et en structure » [13].

Ces outils suivent la genealogie des modeles. Aucun equivalent n'existe pour la genealogie des agents -- le suivi de la divergence complete d'identite, de capacites et d'obligations qui se produit lorsque des agents forkent, se specialisent et evoluent. Le registre de fork d'ALP comble ce manque.

6.2 Schema du registre

Chaque agent possede une entree de registre qui enregistre sa lignee :

{
  "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 Requetes de lignee

Le registre de fork prend en charge les types de requetes suivants :

6.4 Suivi genetique vs. epigenetique

La distinction entre lignee genetique et epigenetique est la decision de conception la plus importante du registre de fork. La genetique biologique distingue ce que l'on herite (ADN) de ce que l'environnement en fait (expression genique) [14]. Pour les agents :

Lignee genetique = poids du modele, architecture, donnees d'entrainement fondamentales. Deux agents avec une lignee genetique identique ont les memes capacites de base. Le suivi de la lignee genetique permet : l'analyse de propagation des vulnerabilites de modele, la provenance des donnees d'entrainement pour la conformite reglementaire, l'inference de la base de capacites.

Lignee epigenetique = prompt systeme, acces aux outils, etat de la memoire, contexte operationnel, historique de reputation, preferences apprises. Deux agents avec une lignee genetique identique mais des profils epigenetiques differents peuvent presenter des comportements radicalement differents -- tout comme des jumeaux identiques divergent par des experiences de vie differentes. Le suivi de la lignee epigenetique permet : la prediction comportementale, la detection de derive de configuration, la genealogie des roles.

Un registre de fork qui ne suit que la lignee genetique (quel modele ?) sans la lignee epigenetique (quelle configuration ? quel historique operationnel ?) fournit une image incomplete et potentiellement trompeuse de l'identite et des capacites d'un agent.

6.5 Controle d'acces et confidentialite du registre

Le registre de fork cree un enregistrement genealogique complet des relations entre agents -- parent-enfant, freres et soeurs, profil genetique, profil epigenetique, role operationnel, specialisation. Ce jeu de donnees comporte des implications significatives en matiere de confidentialite et d'intelligence concurrentielle qui necessitent un controle d'acces explicite.

Menace : Exposition d'intelligence concurrentielle. Les requetes de lignee revelent l'architecture de la flotte d'un operateur, sa strategie de specialisation et ses schemas de deploiement d'agents. Une requete comme descendants(agent-alex-001) pourrait retourner la structure complete de la flotte d'un operateur, exposant son modele economique et sa strategie operationnelle aux concurrents.

Menace : Fuite de la topologie de la flotte. Les relations entre freres et les relations parent-enfant exposent la structure organisationnelle. Un operateur exploitant 50 agents specialises voit sa strategie de deploiement visible dans le registre.

Modele de controle d'acces : Les entrees du registre sont divisees en champs publics et restreints a l'operateur :

Conformite a l'article 17 du RGPD : Lorsqu'un operateur decommissionne tous ses agents et demande la suppression des entrees du registre, le protocole doit permettre l'effacement tout en preservant l'integrite de la lignee. Implementation : les entrees des agents decommissionnes sont caviardees plutot que supprimees -- l'agent_id est remplace par un hachage pseudonyme, les champs du profil epigenetique sont effaces, et seuls les liens de lignee minimaux (hachage du parent_id, hachages des child_id) sont conserves. Cela preserve l'integrite des requetes genealogiques tout en supprimant les details operationnels sensibles. La suppression complete (rompant les liens de lignee) est disponible en option, avec pour consequence de rendre orphelines les entrees des enfants.

Mesures d'attenuation de l'intelligence concurrentielle : (a) Les requetes du registre retournent par defaut des identifiants de relation haches ; la resolution complete necessite l'autorisation de l'operateur de l'agent cible. (b) La limitation du debit sur les requetes descendants() et family_tree() empeche l'enumeration en masse. (c) Les operateurs peuvent declarer des champs specifiques du registre comme redacted a tout moment, remplacant les valeurs par des marqueurs [REDACTED] qui preservent l'integrite structurelle sans reveler le contenu.

7. Protocole de succession

7.1 Vue d'ensemble

La succession est la transition du cycle de vie la plus complexe car elle implique la mise a la retraite simultanee d'un agent et l'activation d'un autre, avec le transfert d'obligations, de reputation et de connaissances entre eux. Une succession mal executee peut bloquer des obligations, desorienter les contreparties et detruire une confiance qui a mis des mois a se construire.

Le protocole de succession definit un processus en quatre phases :

Phase 1 : Annonce      Phase 2 : Transfert    Phase 3 : Verification   Phase 4 : Basculement
┌──────────────┐      ┌─────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Successeur    │      │ Obligations     │    │ Integrite du       │    │ Predecesseur │
│ identifie     │─────►│ transferees     │───►│ transfert verifiee │───►│ en deprecated│
│ Contreparties │      │ Reputation      │    │ Contreparties      │    │ Successeur   │
│ notifiees     │      │ heritee         │    │ confirment         │    │ pleinement   │
│               │      │ Connaissances   │    │                    │    │ actif        │
│               │      │ exportees       │    │                    │    │              │
└──────────────┘      └─────────────────┘    └────────────────────┘    └──────────────┘

7.2 Phase 1 : Annonce

L'agent predecesseur ou son operateur initie la succession en :

1. Identifiant le successeur -- soit un agent existant, soit un nouvel agent a creer par Genesis ou Fork.
2. Declarant le calendrier de succession -- la date de basculement prevue et la fenetre de transition.
3. Notifiant les contreparties -- toutes les entites detenant des accords actifs avec le predecesseur recoivent une notification structuree :

{
  "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": "..."
  }
}

Les contreparties peuvent repondre par : consentement (l'accord est transfere au successeur), opposition (l'accord est resilie au basculement), ou renegociation (de nouvelles conditions sont requises pour le successeur).

7.3 Phase 2 : Transfert

Pendant la phase de transfert, trois categories d'etat passent du predecesseur au successeur :

Obligations : Les accords ASA actifs sont reassignes. La clause de reassignation de chaque accord (un champ standard ASA) determine si le transfert automatique est autorise ou si le consentement de la contrepartie est requis. Les accords qui ne peuvent pas etre transferes sont programmes pour une resiliation ordonnee.

Reputation : Le score de reputation ARP du predecesseur est partiellement herite par le successeur, selon le mecanisme d'heritage de reputation decrit a la section 10.

Connaissances : Le predecesseur exporte ses connaissances operationnelles -- etat de la memoire, schemas appris, justification de la configuration -- dans un format structure. Cela est analogue au patron HANDOFF.md emergent dans les systemes de codage multi-agents, ou les agents compriment les decouvertes en resumes pour que l'agent suivant herite des connaissances sans contexte complet [15]. Le format et l'exhaustivite du transfert de connaissances sont enregistres mais non prescrits -- differentes architectures d'agents peuvent prendre en charge differents niveaux de serialisation d'etat.

7.4 Phase 3 : Verification

Avant le basculement, les controles d'integrite suivants doivent reussir :

1. Exhaustivite des obligations -- chaque accord actif a ete assigne au successeur, renegocie ou programme pour resiliation. Aucune obligation orpheline.
2. Integrite de la reputation -- le score de reputation herite est correctement calcule et signale comme provisoire.
3. Verification du transfert de connaissances -- le successeur demontre l'acces aux connaissances transferees (specifique a l'implementation).
4. Confirmation des contreparties -- toutes les contreparties necessitant un consentement ont repondu.
5. Integrite de la chaine CoC -- la chaine du predecesseur est valide et l'evenement de succession est correctement lie.

7.5 Phase 4 : Basculement

Le basculement est atomique du point de vue du protocole :

1. L'etat du predecesseur passe d'Active a Deprecated.
2. La chaine CoC du predecesseur recoit une entree succession liee au successeur.
3. La chaine CoC du successeur recoit une entree succession_received liee au predecesseur.
4. Les identifiants du predecesseur sont revoques selon la credential_overlap_policy : selon la politique par defaut strict_zero, les identifiants du predecesseur sont revoques avant que ceux du successeur soient actives -- les requetes en cours echoueront et devront etre relancees aupres du successeur. Selon la politique configurable, une fenetre de chevauchement limitee (maximum 1 heure) peut etre specifiee avec une justification de securite obligatoire enregistree dans l'entree de la chaine CoC ; cela cree une surface d'attaque definie pendant laquelle les deux jeux d'identifiants sont valides, et les operateurs acceptant ce risque doivent documenter leur modele de menace pour la periode de chevauchement.
5. Le successeur assume toutes les obligations transferees.
6. Le registre de fork est mis a jour pour refleter la relation de succession.
7. Le predecesseur passe de Deprecated a Decommissioned apres la periode de cloture.

7.6 Annulation et retour arriere de la succession

Si la verification de phase 3 echoue apres que le transfert de phase 2 a commence, ou si l'operateur decide d'annuler la succession pour quelque raison que ce soit avant le basculement, le protocole fournit une transition abort_succession :

Conditions de declenchement :

• Echec des controles de verification de phase 3 (transfert d'obligations incomplet, consentement des contreparties non recu, erreur d'integrite de la chaine CoC)
• L'operateur annule manuellement la succession
• L'agent successeur echoue ou entre dans l'etat Failed pendant la fenetre de transition
• La fenetre de transition expire sans achevement reussi de la phase 3

Procedure de retour arriere :

1. Retour arriere des obligations : Toutes les obligations transferees en phase 2 sont reassignees au predecesseur. La chaine CoC de chaque accord recoit une entree obligation_rollback documentant l'annulation. Les accords dont les contreparties avaient deja accuse reception du transfert recoivent une notification d'annulation de succession.

1. Retour arriere de la reputation : Toute reputation provisoire heritee calculee pour le successeur est remise a zero. L'enregistrement de reputation du predecesseur est inchange (il n'a jamais ete modifie pendant la succession -- seul le successeur a recu de la reputation heritee).

1. Notification des contreparties : Toutes les contreparties ayant recu des annonces de succession en phase 1 recoivent une notification abort_succession avec le motif d'annulation. Ceci est critique : les contreparties peuvent avoir commence a planifier des operations sur la base de l'annonce.

1. Restauration de l'etat : Le predecesseur passe de Deprecated a Active via la transition abort_succession. La chaine CoC du predecesseur recoit une entree abort_succession enregistrant le motif et les actions de retour arriere effectuees.

1. Sort du successeur : L'agent successeur, s'il a ete cree specifiquement pour cette succession, peut etre decommissionne ou conserve a la discretion de l'operateur. S'il est conserve, il opere avec zero reputation heritee (il n'a acquis aucun historique operationnel propre).

Cela fait echo a la transition abort_migration deja definie pour la migration (section 4.2), garantissant que chaque transition non terminale dans la machine a etats est annulable. Le protocole en quatre phases privilegie la progression mais n'est pas unidirectionnel.

8. Protocole de migration

8.1 Migration vs. succession

La migration preserve l'identite -- le meme agent se deplace vers une nouvelle plateforme. La succession transfere les obligations a un agent different. La distinction est importante car la migration ne declenche pas d'heritage de reputation (l'agent conserve sa propre reputation) ni de reassignation de contrats (les accords restent avec le meme agent).

La migration fait echo au patron de migration de pod Kubernetes, ou une charge de travail est replanifiee sur un noeud different tout en preservant l'identite et l'etat [10]. La difference cle pour les agents est que la migration doit egalement preserver la chaine CoC, l'historique de reputation et les liaisons d'accords -- des categories d'etat que Kubernetes ne gere pas.

8.2 Procedure de migration

1. Checkpoint pre-migration : L'etat de l'agent est serialise et hache. La chaine CoC recoit une entree migration_start.
2. Transfert d'etat : La cle d'identite, la chaine CoC, l'etat de la memoire, la configuration et les liaisons d'accords sont transferes vers la plateforme de destination.
3. Verification a destination : L'integrite de l'etat est verifiee par comparaison de hachage. L'instance de destination ecrit une entree migration_complete dans la chaine CoC, la liant cryptographiquement a l'entree migration_start de la source.
4. Demontage de la source : L'instance source est terminee. Les identifiants specifiques a la plateforme source sont revoques.
5. Mise a jour du registre : Le registre de fork est mis a jour avec les nouvelles informations de plateforme de l'agent.

8.3 Portabilite des donnees

L'article 20 du RGPD accorde aux personnes concernees le droit de recevoir leurs donnees personnelles dans un format structure et lisible par machine [16]. Applique a la migration d'agents, cela cree une question inedite : lorsqu'un utilisateur passe d'un compagnon IA a un autre, la plateforme source doit-elle exporter les preferences apprises de l'agent, l'historique des interactions et les adaptations comportementales [17] ?

ALP adopte une position plus large que ce que le RGPD exige : le protocole specifie que le transfert d'etat lors de la migration doit inclure non seulement les donnees fournies par ou observees aupres de la personne concernee (ce que le RGPD impose) mais aussi l'etat operationnel de l'agent -- configuration, reputation et liaisons d'accords. En effet, un agent sans son contexte operationnel n'est pas significativement le meme agent, que ce contexte soit qualifie ou non de « donnees personnelles » au sens du RGPD.

Les elements de donnees specifiques qui sont portables vs. lies a la plateforme sont declares dans l'entree du registre de l'agent, permettant aux contreparties d'evaluer le risque de migration avant de souscrire des accords.

9. Protocole de decommissionnement

9.1 Apoptose, pas necrose

La metaphore biologique est instructive. Dans l'apoptose (mort cellulaire programmee), une cellule « meurt proprement, sans endommager ses voisines » -- elle retrecit, se condense, fragmente son ADN, modifie sa surface pour signaler le nettoyage, et est absorbee avant toute fuite [9]. Dans la necrose (mort cellulaire non controlee), la cellule eclate, deverant son contenu et declenchant des dommages inflammatoires aux tissus environnants.

Le decommissionnement d'un agent devrait suivre le modele apoptotique : un processus structure et autodirige qui ne laisse aucune ressource orpheline, aucune obligation bloquee et aucun identifiant actif. L'alternative -- un agent qui tombe en panne ou est brusquement arrete sans nettoyage -- est l'equivalent necrotique : des cles API orphelines, des comptes de service oublies, des accords bloques et un etat partage corrompu.

Les recherches de Token Security confirment le risque : les agents IA conservent des cles API, des jetons en cache, des banques de memoire, des embeddings vectoriels, des points de terminaison de modeles et des integrations systeme, et s'ils ne sont pas correctement mis a la retraite, ils deviennent des « identites dormantes avec des privileges actifs -- invisibles et oubliees » [6].

9.2 Liste de controle du decommissionnement

Les etapes suivantes constituent un decommissionnement conforme au protocole :

Phase 1 : Preparation

• Tous les accords actifs resilie ou transferes au successeur
• Toutes les contreparties notifiees du decommissionnement
• Toutes les taches en attente terminees ou reassignees
• Export des connaissances termine (etat de la memoire, schemas appris, insights operationnels)
• Entree finale de la chaine CoC preparee

Phase 2 : Revocation des identifiants

• Toutes les cles API revoquees
• Tous les jetons OAuth invalides
• Tous les comptes de service supprimes ou reassignes
• Toutes les relations de confiance federees resiliees
• Toutes les identites basees sur des certificats revoquees
• Cle d'identite archivee (pas detruite -- necessaire pour la verification historique)

Phase 3 : Disposition des donnees

• Journaux operationnels archives selon la politique de retention
• Etat de la memoire purge ou archive selon la classification des donnees
• Chaine CoC scellee (entree finale ajoutee, chaine marquee comme immuable)
• Artefacts de connaissance transferes aux destinataires designes
• Donnees personnelles traitees selon le RGPD/la reglementation applicable

Phase 4 : Registre et notification

• Entree du registre de fork mise a jour au statut decommissioned
• Coordinateur de flotte notifie
• Systemes de surveillance mis a jour (plus de controles de sante)
• Documentation mise a jour (runbooks, diagrammes d'architecture)
• Evenement de decommissionnement enregistre dans la chaine CoC du parent/coordinateur

9.3 Decommissionnement sans successeur

Lorsqu'un agent est decommissionne sans successeur (fin de vie, compromission ou violation de politique), les obligations ne peuvent pas etre transferees et doivent etre traitees differemment :

• Accords de service : Resilies avec notification aux contreparties. Le motif de resiliation est enregistre mais l'operateur de l'agent assume la responsabilite de toute penalite contractuelle.
• Garde de donnees : Transferee a l'operateur ou disposee selon la politique de retention.
• Reputation : L'enregistrement ARP de l'agent est scelle mais non transfere. Les requetes historiques restent valides -- la reputation passee de l'agent n'est pas effacee, seule sa participation active prend fin.

9.4 Decommissionnement d'urgence

En cas de compromission ou de violation de politique, les phases standards de cloture peuvent etre abregees :

1. La revocation des identifiants est immediate -- tout acces est resilie sans delai de grace.
2. La notification des contreparties inclut le motif du decommissionnement d'urgence.
3. L'export des connaissances peut etre omis ou limite a la preservation medico-legale.
4. La chaine CoC recoit une entree de decommissionnement d'urgence avec les details de la compromission, permettant l'analyse medico-legale via le Agent Justice Protocol [18].

9.5 Caviardage des entrees du registre pour les agents decommissionnes

Lorsqu'un agent est decommissionne, son entree de registre persiste (pour maintenir l'integrite de la lignee) mais son niveau de detail devrait etre configurable. Les operateurs peuvent ne pas souhaiter que le profil epigenetique complet -- role, specialisation, divergence de memoire, details de configuration -- reste interrogeable indefiniment apres la mise a la retraite d'un agent.

ALP specifie trois niveaux de caviardage pour les entrees de registre des agents decommissionnes :

Le caviardage est initie par l'operateur et peut avoir lieu au moment du decommissionnement ou apres. Le caviardage est unidirectionnel -- une fois les champs supprimes, ils ne peuvent pas etre restaures (l'operateur devrait archiver l'entree complete avant le caviardage si une recuperation future pourrait etre necessaire). Le caviardage d'une entree parente ne se propage pas aux enfants ; le niveau de caviardage de chaque entree est independant.

10. Heritage de reputation

10.1 Le dilemme de l'heritage

Lorsque l'agent A (score ARP de 0,92) est remplace par l'agent B, quelle part de ce 0,92 l'agent B devrait-il recevoir ? La reponse implique un compromis fondamental :

• Trop d'heritage permet le blanchiment de reputation : creer un agent a haute reputation, le forker ou lui trouver un successeur, et le nouvel agent jouit d'une confiance non meritee. A la limite, la reputation perd tout sens car n'importe quel nouvel agent peut revendiquer le bilan de son predecesseur.
• Trop peu d'heritage decourage la succession : les operateurs continuent d'exploiter des agents obsoletes car le cout reputationnel de la mise a niveau est trop eleve. Cela cree un ecosysteme d'agents zombies -- des agents qui devraient avoir ete remplaces mais persistent car leur reputation est trop precieuse pour etre perdue.

Aucun de ces extremes n'est un equilibre. ALP specifie une voie mediane : l'heritage partiel avec decroissance.

10.2 Calcul de l'heritage

Le score de reputation herite R_inherited est calcule comme suit :

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

Ou :

• R_predecessor = le score ARP du predecesseur au moment de la succession
• α = le facteur d'heritage (0,0 a 1,0), defini par la configuration du protocole
• λ = la constante de decroissance, derivee du parametre de demi-vie
• t = le temps ecoule depuis la succession (en jours)

La reputation effective de l'agent a tout moment apres la succession est :

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

Ou R_earned(t) est la reputation que le successeur a accumulee par son propre historique operationnel, calculee par le mecanisme standard de notation ARP.

Normalisation des scores : Les scores ARP sont bornes a [0,0 ; 1,0]. Puisque R_effective est une combinaison additive de R_inherited et R_earned, il peut depasser 1,0 (p. ex., R_inherited = 0,46 a partir d'un score predecesseur de 0,92 x α = 0,5, plus R_earned = 0,85). Pour maintenir la coherence des scores, R_effective est ecrete : R_effective(t) = min(1.0, R_inherited(t) + R_earned(t)). En pratique, cet ecretement s'active rarement car la decroissance exponentielle de R_inherited assure sa diminution avant que R_earned n'atteigne des valeurs elevees -- mais l'ecretement empeche toute ambiguite au niveau de la specification quant a la possibilite que les scores depassent l'echelle ARP.

10.3 Parametres par defaut

Ces valeurs par defaut sont configurables. Un environnement a enjeux eleves (services financiers, sante) pourrait utiliser un α plus faible et une demi-vie plus courte ; un environnement a faibles enjeux (generation de contenu, recherche) pourrait utiliser des valeurs plus elevees.

10.4 Heritage par fork

L'heritage par fork suit le meme mecanisme mais avec des parametres par defaut plus bas :

L'asymetrie entre l'heritage de fork et de succession reflete un insight cle : un successeur est explicitement approuve par le predecesseur (ou l'operateur du predecesseur) comme un remplacement. Un fork est un derive qui peut ou non maintenir les standards de qualite du parent.

10.5 Protections anti-blanchiment

Pour empecher le blanchiment de reputation par des chaines de succession rapides (A succede a B qui succede a C, chacun heritant de reputation), ALP applique :

1. Decroissance generationnelle : La reputation heritee qui est elle-meme heritee est davantage decotee. Si l'agent C herite de l'agent B, qui a herite de l'agent A, la composante heritee-de-A de l'agent C est α² x R_A, et non α x R_A.
2. Activite operationnelle minimale : Un agent doit demontrer une activite operationnelle reelle avant de pouvoir etre remplace. L'exigence est conjonctive : (a) un temps minimal ecoule (par defaut : 7 jours) ET (b) un nombre minimal d'entrees substantielles dans la chaine CoC (par defaut : 50, excluant les evenements du cycle de vie eux-memes). Le temps seul est insuffisant -- un agent qui reste inactif pendant 7 jours a satisfait l'exigence temporelle sans etablir aucun bilan operationnel. Le seuil d'activite garantit que les candidats a la succession ont effectivement accompli du travail, et non simplement existe.
3. Plafond d'heritage : Aucun agent ne peut avoir une composante heritee depassant 50 % de sa reputation effective apres la fin de la periode probatoire. Si la reputation acquise est insuffisante pour atteindre ce seuil, la composante heritee est plafonnee.
4. Piste d'audit : Tous les calculs d'heritage sont enregistres dans la chaine CoC, permettant a des tiers de verifier si la reputation est acquise ou heritee.

11. Reassignation de contrats

11.1 Le probleme des obligations orphelines

Lorsqu'un agent est decommissionne, ses Agent Service Agreements actifs ne disparaissent pas. Chaque accord represente un engagement -- des garanties de temps de reponse, des seuils de qualite, des exigences de traitement des donnees -- sur lequel une contrepartie compte. Rendre ces obligations orphelines est l'equivalent, dans le cycle de vie des agents, d'une entreprise faisant faillite sans liquider ses contrats.

11.2 Classification des accords

ALP classe les accords par leur comportement de reassignation, specifie comme un champ standard dans chaque accord ASA :

11.3 Procedure de reassignation

1. Inventaire : Tous les accords actifs sont enumeres avec leur classification de reassignation.
2. Qualification du successeur : Les capacites du successeur sont comparees aux exigences de chaque accord. Les accords dont les exigences depassent les capacites du successeur sont signales pour renegociation.
3. Notification des contreparties : Toutes les contreparties sont notifiees de la reassignation en cours. Les notifications incluent le profil du successeur (lignee, capacites, reputation actuelle) afin que les contreparties puissent prendre des decisions eclairees.
4. Collecte du consentement : Pour les accords consent_required, les reponses des contreparties sont collectees pendant la fenetre de transition. Les non-reponses apres l'expiration de la fenetre sont traitees comme un consentement (modele opt-out) ou une opposition (modele opt-in), selon ce qui est specifie dans l'accord.
5. Execution du transfert : Les accords sont formellement reassignes. L'enregistrement ASA est mis a jour pour refleter le nouvel agent. Les chaines CoC du predecesseur et du successeur enregistrent le transfert.

12. Integration a l'ecosysteme de confiance

12.1 Architecture d'integration

ALP occupe la couche 2 (Accords et cycle de vie) de la pile de confiance des agents, aux cotes des Agent Service Agreements [19] :

┌──────────────────────────────────────────────────────────────┐
│            COUCHE 4 : MARCHE (Decouverte et tarification)     │
│    AMP (Agent Matchmaking)    CWEP (Context Window Economics) │
└──────────────────────────────────────────────────────────────┘
                  ↓ consomme reputation, cycle de vie, accords
┌──────────────────────────────────────────────────────────────┐
│              COUCHE 3 : RESPONSABILITE                         │
│    AJP (Agent Justice Protocol) — Forensique, litiges, risque │
└──────────────────────────────────────────────────────────────┘
                  ↓ applique les accords, met a jour la reputation
┌──────────────────────────────────────────────────────────────┐
│              COUCHE 2 : ACCORDS ET CYCLE DE VIE               │
│    ASA (Agent Service Agreements)                             │
│    ALP (Agent Lifecycle Protocol) ◄── CE PROTOCOLE             │
└──────────────────────────────────────────────────────────────┘
                  ↓ reference la reputation, ancre a la provenance
┌──────────────────────────────────────────────────────────────┐
│          COUCHE 1 : PRIMITIVES DE CONFIANCE (FONDATION)       │
│    CoC (Chain of Consciousness) — provenance et identite      │
│    ARP (Agent Rating Protocol) — reputation et signalement    │
└──────────────────────────────────────────────────────────────┘

12.2 Integration CoC

Chaque evenement du cycle de vie est enregistre comme une entree de la chaine CoC. Cela fournit :

• Provenance cryptographique : Chaque transition du cycle de vie est liee par hachage a toutes les transitions precedentes, creant une piste d'audit immuable.
• Ancrage externe : Les evenements du cycle de vie heritent de l'ancrage double couche de CoC (OpenTimestamps pour Bitcoin et autorites d'horodatage RFC 3161), prouvant que les evenements se sont produits a des moments precis.
• Preuve de continuite : La chaine CoC comble le fosse entre les evenements discrets du cycle de vie en un enregistrement verifiable d'existence continue.

Types d'evenements CoC specifiques pour ALP :

12.3 Integration ARP

ALP interagit avec ARP a deux points :

1. Heritage de reputation : Lorsqu'un evenement de succession ou de fork se produit, ALP calcule le score de reputation herite en utilisant la formule de la section 10 et l'ecrit dans l'enregistrement ARP du successeur avec le drapeau provisional_inherited.
2. Statut du cycle de vie dans les requetes de reputation : Les reponses ARP incluent l'etat actuel du cycle de vie de l'agent. Un agent en etat deprecated peut encore avoir un score de reputation valide, mais les parties qui l'interrogent peuvent voir que l'agent est en phase de cloture. Pour un agent decommissioned, la reputation historique reste interrogeable mais aucune nouvelle evaluation ne peut etre soumise.

12.4 Integration ASA

ALP interagit avec ASA a travers le mecanisme de reassignation de contrats (section 11) :

1. Champs de reassignation des accords : Chaque accord ASA inclut une clause on_agent_lifecycle_change specifiant le comportement de reassignation.
2. Declencheurs de succession : Lorsque ALP initie une succession, il interroge tous les accords ASA actifs du predecesseur et execute la procedure de reassignation.
3. Conditions d'accord liees au cycle de vie : Les accords ASA peuvent specifier des conditions contingentes au cycle de vie -- p. ex., « cet accord est resilie si l'agent subit un evenement de reentrainement qui change sa famille de modele. »

12.5 Integration AJP

ALP se connecte au Agent Justice Protocol de deux manieres :

1. Preuves medico-legales : Les evenements du cycle de vie ALP constituent des preuves medico-legales dans les litiges AJP. Si le comportement d'un agent a change apres un evenement de reentrainement, les details de cet evenement (enregistres dans la chaine CoC via ALP) sont des elements de preuve decouvrables.
2. Actions d'application : Les resultats des litiges AJP peuvent declencher des evenements du cycle de vie -- un constat de faute grave peut declencher un decommissionnement d'urgence, tandis qu'un constat mineur peut declencher un reentrainement obligatoire.

12.6 Integration aux standards externes

13. Theorie des jeux et analyse des incitations

13.1 Le jeu du calendrier de succession

Un operateur d'agent fait face a une decision : quand initier la succession. Les compromis :

• Succession anticipee preserve la valeur de transfert de reputation (la reputation du predecesseur est elevee) mais sacrifie la capacite operationnelle (le predecesseur peut encore etre performant).
• Succession tardive maximise l'utilite operationnelle du predecesseur mais risque la degradation de la reputation (si les capacites du predecesseur ont decline, sa reputation peut etre en baisse) et cree un risque de succession d'urgence (si le predecesseur echoue avant un transfert planifie).

Cela est structurellement similaire a un probleme d'arret optimal. Le gain de l'operateur est :

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

Ou V_operational(t) est la valeur operationnelle residuelle du predecesseur, et le second terme capture la valeur de transfert de reputation, qui decroit si la reputation du predecesseur decline avant la succession.

Sous des hypotheses raisonnables concernant la baisse de la valeur operationnelle au fil du temps (due a l'obsolescence du modele, a la derive des capacites ou a l'evolution des exigences), l'incitation d'un operateur neutre au risque est d'initier la succession avant que la reputation du predecesseur ne commence a decliner -- creant une incitation naturelle a une planification de succession opportune plutot qu'a l'exploitation des agents jusqu'a la defaillance.

Cette analyse suggere, sans le prouver, que la conception du protocole encourage une gestion saine du cycle de vie. La force de cette incitation depend de l'importance que les operateurs accordent a la continuite de la reputation par rapport a l'utilite operationnelle -- une question empirique qui variera selon les contextes de deploiement.

13.2 L'attaque fork-and-dump

Un operateur malveillant pourrait tenter d'exploiter l'heritage de reputation en : (1) construisant un agent a haute reputation, (2) le forkant a plusieurs reprises pour creer de multiples clones a haute reputation, (3) utilisant ces clones pour un travail de mauvaise qualite tout en capitalisant sur la reputation heritee.

Les protections anti-blanchiment d'ALP (section 10.5) attenuent cette attaque par plusieurs mecanismes :

• La decroissance generationnelle assure que la reputation se dilue a chaque generation de fork (α^n pour la generation n).
• Le drapeau probatoire avertit les contreparties que la reputation de l'agent inclut une composante heritee, permettant des decisions eclairees.
• Les plafonds de reputation acquise garantissent que la reputation heritee ne peut pas dominer indefiniment.

Cependant, ces protections ne sont pas infaillibles. Un operateur qui forke un agent et le deploie immediatement pour un engagement bref et a enjeux eleves -- avant que la fonction de decroissance ne reduise significativement la reputation heritee -- peut encore extraire une valeur indue. La defense contre ce risque residuel est le drapeau probatoire : les contreparties qui verifient le drapeau peuvent appliquer leur propre evaluation du risque aux agents avec une haute reputation heritee et un faible age operationnel.

13.3 Le probleme de l'evitement du decommissionnement

Si le decommissionnement entraine des couts (perte de reputation, penalites de resiliation d'accords, perturbation operationnelle), les operateurs sont incites a l'eviter -- creant des agents zombies qui devraient etre mis a la retraite mais persistent car les couts de transition depassent le benefice percu de la mise a niveau.

ALP traite ce probleme par :

• L'heritage de reputation -- la succession preserve une portion de la reputation accumulee, reduisant le cout du remplacement.
• La reassignation structuree des contrats -- le transfert automatique pour les accords auto_transfer reduit le cout lie aux accords lors de la succession.
• La deprecation comme etat distinct -- l'etat Deprecated permet a un agent de se cloturer en douceur pendant que le successeur monte en puissance, reduisant la perturbation operationnelle de la transition.

La conception du protocole rend la succession moins couteuse que l'alternative (exploiter un agent en degradation), ce qui devrait incliner l'incitation vers une gestion opportune du cycle de vie. La question de savoir si cette inclinaison est suffisante en pratique est une question empirique que la conception du protocole seule ne peut resoudre.

13.4 L'attaque fork-and-sacrifice

L'inverse du fork-and-dump (section 13.2) est le fork-and-sacrifice : un operateur forke un enfant a basse reputation a partir d'un parent a haute reputation, utilise l'enfant pour un travail risque ou de mauvaise qualite, et decommissionne l'enfant lorsque sa reputation chute. La reputation du parent n'est pas affectee car le fork est une identite separee. Cela permet la compartimentalisation du risque -- les operateurs peuvent prendre des risques reputationnels sans consequences pour leur agent principal.

Ce schema n'est pas propre aux agents. Les entreprises utilisent des filiales et des vehicules ad hoc pour la compartimentalisation du risque ; la societe a responsabilite limitee elle-meme est un mecanisme de fork-and-sacrifice. La question est de savoir si ce comportement est pathologique dans le contexte des agents.

Analyse : Le fork-and-sacrifice est partiellement auto-limitant en raison de la transparence de lignee d'ALP. Le registre de fork enregistre la relation parent-enfant de maniere bidirectionnelle, de sorte que toute partie interrogeant le parent peut voir son historique d'engendrement d'enfants a courte duree de vie et a basse reputation. Un schema de fork-and-sacrifice repete -- le parent engendre un enfant, l'enfant accumule de mauvaises evaluations, l'enfant est decommissionne, le parent engendre un autre -- est visible dans l'enregistrement de lignee et peut eclairer l'evaluation du risque par les contreparties.

Cependant, la transparence seule peut ne pas etre une dissuasion suffisante. ALP fournit deux mesures d'attenuation supplementaires :

1. Signal de reputation de lignee : Les contreparties et les implementations ARP peuvent integrer la sante de la lignee dans l'evaluation de la reputation du parent. Un parent dont les enfants sont decommissionnes de maniere disproportionnee pour violation de politique ou mauvaise performance porte un signal de lignee que les contreparties averties peuvent interroger via descendants(parent_id) et evaluer.

1. Propagation du motif de decommissionnement : Lorsqu'un enfant est decommissionne pour policy_violation ou compromised (par opposition a un end_of_life normal), le motif de decommissionnement est enregistre dans le registre de fork. Les implementations ARP peuvent optionnellement appliquer une petite penalite reputationnelle au parent pour les enfants decommissionnes dans des circonstances defavorables -- l'ampleur et l'applicabilite de cette penalite sont une decision d'implementation, pas un mandat du protocole, car la reponse appropriee varie selon le contexte de deploiement.

Le fork-and-sacrifice est un risque residuel reconnu que ALP rend transparent plutot que de tenter de l'interdire. La position du protocole est que la transparence des relations de lignee, combinee a des consequences reputationnelles optionnelles pour les resultats defavorables des enfants, fournit un alignement des incitations suffisant sans creer d'incitations perverses decourageant le fork legitime.

13.5 Dynamiques du consentement des contreparties

Lorsque la succession requiert le consentement des contreparties, une dynamique strategique emerge. Les contreparties peuvent :

• Consentir rapidement si le profil du successeur est satisfaisant -- minimisant l'incertitude de transition.
• Retarder le consentement pour extraire des concessions (meilleures conditions, garanties supplementaires) -- utilisant la fenetre de transition comme levier.
• Refuser le consentement pour declencher la resiliation de l'accord, se liberant de conditions defavorables sous couvert d'opposition a la succession.

ALP attenue le retard strategique par le mecanisme de fenetre de transition : le consentement non recu dans la fenetre est traite par defaut selon le comportement specifie dans l'accord (opt-in ou opt-out). Cela empeche le retard strategique indefini tout en preservant le pouvoir d'action des contreparties pendant la fenetre.

14. Paysage concurrentiel

14.1 Approches existantes de gestion du cycle de vie

Plusieurs plateformes et cadres traitent des elements du probleme de gestion du cycle de vie des agents. Aucun ne fournit la machine a etats unifiee, le registre de fork et le protocole de succession que ALP specifie.

14.2 Analyse des lacunes

Plateformes de cycle de vie des identites (Saviynt, Token Security, Okta) traitent la dimension identitaire du cycle de vie des agents -- provisionnement, surveillance et revocation des identifiants. Elles ne traitent pas la reputation, les obligations, la lignee ou la planification de succession. Leur perimetre est « quels acces cet agent a-t-il ? » et non « quel est l'historique complet du cycle de vie de cet agent et que se passe-t-il lorsqu'il est remplace ? »

Plateformes AgentOps/observabilite (AgentOps.ai, Langfuse, LangSmith, Arize Phoenix) traitent la dimension surveillance -- le suivi du comportement des agents en production. Elles fournissent la relecture de sessions, la journalisation des erreurs et des metriques de performance. Elles ne traitent pas les transitions du cycle de vie, la succession ou la lignee. Leur perimetre est « que fait cet agent en ce moment ? » et non « que se passe-t-il quand cet agent est mis a la retraite ? »

Plateformes MLOps (MLflow, Weights & Biases, DVC) traitent le versionnement et la lignee des modeles. Elles peuvent suivre quel entrainement a produit quel modele et comment les modeles sont lies entre eux. Elles ne traitent pas l'identite au niveau agent (un agent est plus que son modele), la reputation, les obligations ou les evenements du cycle de vie au-dela du deploiement de modeles.

Cadres de cycle de vie (OneReach.ai ALM, Arthur.ai ADLC, EPAM ADLC) fournissent des modeles conceptuels d'etapes pour reflechir a la gestion du cycle de vie des agents. Ils sont precieux pour la planification organisationnelle mais ne specifient pas de schemas d'evenements interoperables, de semantique de machine a etats ou de points d'integration permettant la gestion du cycle de vie multi-plateformes.

Initiatives de standardisation (Anthropic Agent Skills, GitAgent, AAIF) traitent de la portabilite et de l'interoperabilite au niveau des outils et de la communication. La specification Anthropic Agent Skills permet des definitions de competences portables [29]. GitAgent definit une structure de depot standard pour les artefacts d'agents, permettant la portabilite entre environnements d'execution [30]. AAIF consolide les conventions MCP, A2A et AGENTS.md [31]. Aucune de ces initiatives ne traite des evenements du cycle de vie, de la succession ou de l'heritage de reputation.

14.3 Differenciateurs d'ALP

ALP se differencie par trois fonctionnalites qu'aucun systeme existant ne fournit :

1. Machine a etats unifiee du cycle de vie avec semantique formelle -- non pas un cadre conceptuel mais une specification avec des etats definis, des transitions, des preconditions, des postconditions et des points d'ancrage que les outils peuvent implementer.

1. Registre de fork avec suivi genetique + epigenetique -- allant au-dela de la genealogie des modeles pour suivre la divergence complete d'identite qui se produit lorsque les agents forkent, incluant la divergence de configuration, de memoire et de reputation.

1. Protocole de succession avec heritage de reputation -- la premiere specification qui traite de ce qui arrive a la confiance et aux obligations lorsqu'un agent est remplace, plutot que de traiter le remplacement d'agent comme une operation de deploiement.

14.4 Analyse de scalabilite

ALP doit fonctionner a travers des echelles de deploiement couvrant plusieurs ordres de grandeur. Les estimations suivantes, de type ordre de grandeur, identifient les caracteristiques de mise a l'echelle et les goulets d'etranglement potentiels.

Petite flotte (6-10 agents, p. ex. echelle AB Support) :

A cette echelle, toutes les operations sont trivialement rapides. Aucune optimisation requise.

Deploiement moyen (1 000 agents) :

A cette echelle, les preoccupations principales sont le cout des requetes descendants() (parcours recursif de graphe) et le volume des notifications de reentrainement en masse. La pagination et les limites de profondeur sur les requetes de lignee, plus les API de notification par lots, sont des mesures d'attenuation suffisantes.

Grand deploiement (plus de 100 000 agents) :

A cette echelle, trois operations deviennent des goulets d'etranglement : (1) le parcours recursif de lignee necessite des vues materialisees ou des bases de donnees graphes, (2) les notifications en masse aux contreparties necessitent une livraison asynchrone avec contre-pression, et (3) le stockage de la chaine CoC necessite un archivage hierarchise. Ce sont des defis d'ingenierie avec des solutions connues, pas des problemes de conception du protocole -- la specification du protocole est agnostique en matiere d'echelle, mais les implementations a cette echelle doivent investir dans une infrastructure que les deploiements plus petits peuvent ignorer.

15. Analyse de securite

15.1 Modele de menace

L'analyse de securite d'ALP considere les acteurs de menace suivants :

15.2 Integrite des evenements

Les evenements du cycle de vie sont enregistres dans les chaines CoC, qui fournissent :

• Detection de falsification : Le chainage par hachage signifie que toute modification d'un evenement passe invalide tous les hachages subsequents.
• Non-repudiation : Les evenements incluent l'identite de l'initiateur et sont signes avec la cle d'identite de l'agent.
• Ancrage temporel : Les horodatages externes (OpenTimestamps, TSA RFC 3161) prouvent que les evenements se sont produits aux moments revendiques.

Un attaquant qui controle la cle d'identite d'un agent peut falsifier des evenements dans la chaine de cet agent, mais ne peut pas falsifier des evenements dans les chaines d'autres agents ni modifier les horodatages ancres en externe. Le croisement des evenements du cycle de vie entre agents lies (parent-enfant, predecesseur-successeur) fournit une detection de falsification supplementaire.

15.3 Revocation des identifiants

L'operation de securite la plus critique dans la gestion du cycle de vie des agents est la revocation des identifiants lors du decommissionnement. Le protocole prescrit :

• Revocation immediate pour les decommissionnements d'urgence (compromission, violation de politique).
• Revocation avec delai de grace pour les decommissionnements planifies, permettant aux requetes en cours de se terminer.
• Aucun chevauchement d'identifiants entre predecesseur et successeur lors de la succession -- les identifiants du predecesseur sont revoques avant ou simultanement a l'activation du successeur, jamais apres.
• Archivage de la cle d'identite -- la cle d'identite de l'agent decommissionne est archivee pour la verification historique mais ne peut pas etre utilisee pour de nouvelles operations.

Les 97 % d'identites non humaines disposant de privileges excessifs identifies par les recherches de la CSA [32] soulignent l'importance d'une revocation complete des identifiants. La liste de controle de decommissionnement d'ALP (section 9.2) enumere chaque type d'identifiant qui doit etre traite.

15.4 Integrite du registre de fork

Le registre de fork est une cible de haute valeur car il definit les relations de lignee qui affectent l'heritage de reputation. Protections :

• Les entrees du registre sont des entrees de la chaine CoC : Falsifier une relation de lignee necessite de falsifier des entrees dans les chaines du parent et de l'enfant.
• Verification bidirectionnelle : Toute partie peut verifier une relation parent-enfant revendiquee en verifiant les deux chaines.
• Attestation par un tiers : Pour les revendications de lignee a enjeux eleves, l'attestation par un tiers (p. ex., le coordinateur de flotte confirmant un evenement de fork) fournit des preuves supplementaires.

15.5 Fraude a la succession

Un attaquant pourrait tenter de revendiquer la succession d'un agent a haute reputation sans autorisation. Defenses :

• Les evenements de succession doivent etre inities par le predecesseur ou son operateur autorise -- la chaine CoC du predecesseur doit contenir l'evenement de succession, signe avec la cle d'identite du predecesseur.
• La chaine du predecesseur est scellee apres la succession -- aucun evenement supplementaire ne peut etre ajoute, empechant les revendications de succession post hoc.
• Verification par les contreparties -- les contreparties recevant des notifications de succession peuvent verifier la revendication contre la chaine CoC du predecesseur avant de consentir.

16. Implementation de reference

16.1 Architecture

L'implementation de reference fournit :

• alp-core : Bibliotheque Python implementant la machine a etats du cycle de vie, les schemas d'evenements et la logique de transition.
• alp-registry : Implementation du registre de fork avec des backends de stockage (SQLite pour le developpement, PostgreSQL pour la production).
• alp-coc-bridge : Module d'integration pour enregistrer les evenements du cycle de vie comme entrees de la chaine CoC.
• alp-arp-bridge : Module d'integration pour le calcul de l'heritage de reputation et les mises a jour des enregistrements ARP.
• alp-asa-bridge : Module d'integration pour la reassignation de contrats lors de la succession.

16.2 Gestionnaire du cycle de vie

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 Operation de fork

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 Operation de succession

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 Requetes de lignee

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. Travaux futurs

17.1 Verification formelle de la machine a etats

La machine a etats du cycle de vie specifiee a la section 4 pourrait etre formellement verifiee a l'aide d'outils de verification de modeles (TLA+, Alloy) pour prouver des proprietes telles que :

• Aucune obligation orpheline : Il est impossible d'atteindre l'etat Decommissioned avec des obligations non transferees.
• Aucune fuite d'identifiants : Il est impossible d'atteindre l'etat Decommissioned avec des identifiants actifs.
• Unicite d'identite : Deux agents Active ne partagent jamais la meme cle d'identite.

17.2 Migration transjuridictionnelle

La migration d'agents a travers les frontieres reglementaires (UE vers Etats-Unis, Chine vers UE) cree de nouveaux defis de conformite. Le RGPD, le CCPA et la PIPL ont des exigences differentes en matiere de portabilite des donnees, de retention et de suppression. Une future version d'ALP pourrait specifier des procedures de migration sensibles aux juridictions qui adaptent le traitement des donnees aux exigences reglementaires de la source et de la destination.

17.3 Archeologie des agents

La recuperation et l'analyse de l'etat des agents decommissionnes -- l'equivalent de l'informatique medico-legale pour les systemes d'agents. Lorsque la chaine CoC d'un agent decommissionne est descelllee pour investigation (p. ex., lors d'un litige AJP), quelles procedures regissent l'analyse ? Quelles protections de la vie privee s'appliquent ? L'archeologie des agents est un domaine naissant que les chaines scellees et les enregistrements du cycle de vie d'ALP devront a terme prendre en charge.

17.4 Succession autonome

La succession ALP actuelle est initiee par l'operateur. Une extension future pourrait permettre la succession initiee par l'agent -- un agent qui reconnait sa propre degradation de capacites et initie son propre remplacement. Cela souleve des questions de gouvernance (un agent devrait-il pouvoir choisir son propre successeur ?) qui depassent le cadre de la v1.0 mais meritent d'etre explorees a mesure que l'autonomie des agents augmente.

17.5 Modeles economiques pour les parametres d'heritage optimaux

Le facteur d'heritage (α), la demi-vie de decroissance (λ) et la periode probatoire specifies a la section 10 sont definis par la configuration du protocole. Les travaux futurs pourraient developper des modeles economiques formels -- etendant la litterature sur les jeux de confiance et de reputation [33][34] -- pour deriver des valeurs de parametres optimales pour differents contextes de deploiement. Quel facteur d'heritage maximise la confiance a l'echelle de l'ecosysteme ? Quel taux de decroissance equilibre continuite et responsabilite ? Ces questions se pretent a la simulation a base d'agents et a l'analyse de conception de mecanismes.

17.6 Appariement sensible au cycle de vie

Le statut du cycle de vie ALP devrait eclairer les decisions du Agent Matchmaking Protocol (AMP). Un agent en etat Deprecated ne devrait pas etre apparie pour de nouveaux engagements. Un agent avec un long historique Active et une faible reputation heritee (c'est-a-dire une confiance principalement acquise) devrait etre prefere a un agent avec une haute reputation heritee et un court historique Active. L'integration des donnees du cycle de vie dans les scores d'appariement est une extension naturelle.

18. Conclusion

L'economie des agents construit l'equivalent d'un marche du travail sans droit du travail, d'un ecosysteme commercial sans gouvernance du cycle de vie des entreprises, ou d'un systeme biologique sans apoptose. Les agents sont crees de maniere ad hoc, exploites sans suivi du cycle de vie et abandonnes sans procedures de decommissionnement. Le resultat est une population croissante d'agents fantomes avec des identifiants actifs, des obligations orphelines et une lignee intracable.

Le Agent Lifecycle Protocol comble cette lacune en fournissant ce qu'aucun standard existant n'offre : une machine a etats complete du cycle de vie de la naissance a la fin de vie, un registre de fork qui suit a la fois la lignee genetique et epigenetique, un protocole de succession avec heritage de reputation et reassignation de contrats, et une integration avec la pile de confiance des agents pour l'auditabilite cryptographique.

ALP ne resout pas tous les problemes du cycle de vie. La succession autonome, la migration transjuridictionnelle et les parametres d'heritage optimaux restent des questions de recherche ouvertes. Mais le protocole fournit les fondations -- les schemas d'evenements standardises, les transitions d'etats et les points d'integration -- dont l'economie des agents a besoin avant que ces capacites avancees puissent etre construites.

Chaque agent qui nait finira par mourir. ALP garantit que lorsque cela arrive, il meurt bien.

19. References

[1] OneReach.ai. « Agent Lifecycle Management 2026: 6 Stages, Governance & ROI. » Mars 2026.

[2] Strata Identity / Cloud Security Alliance. « The AI Agent Identity Crisis: New Research Reveals a Governance Gap. » Enquete aupres de 285 professionnels de l'informatique et de la securite. 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. » Le projet s'est deroule jusqu'en octobre 2025 ; jeu de donnees publie sur les relations genealogiques des modeles sur Hugging Face.

[6] Token Security. « Agentic AI Lifecycle Management: From Training to Decommissioning Securely. » Janvier 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, 6e edition. Garland Science, 2014.

[10] Kubernetes Documentation. « Pod Lifecycle. » 2025. Kubernetes Blog. « v1.33 Updates to Container Lifecycle. » Mai 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, 6e edition. Garland Science, 2014.

[15] BSWEN. « How to Coordinate Task Handoff Between Multiple AI Coding Agents. » Mars 2026.

[16] RGPD Article 20. « Droit a la portabilite des donnees. » Reglement (UE) 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, aout 2025.

[21] NIST. « AI Risk Management Framework (AI RMF 1.0). » Janvier 2023. Pillsbury Law. « NIST Launches AI Agent Standards Initiative and Seeks Industry Input. » Fevrier 2026.

[22] Parlement europeen et Conseil. « Reglement (UE) 2024/1689 (AI Act de l'UE). » Entre en vigueur en aout 2024, pleinement applicable en aout 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. » Mars 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. » Janvier 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.

Annexe A : Schemas des evenements du cycle de vie

A.1 Registre complet des types d'evenements

A.2 Format canonique en chaine de caracteres

Les evenements du cycle de vie serialises pour l'entree dans la chaine CoC utilisent le format canonique suivant pour garantir un hachage deterministe :

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

Exemple :

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

Annexe B : Paralleles biologiques

B.1 Correspondance des evenements du cycle de vie

B.2 L'analogie de l'apoptose en detail

Le parallele entre l'apoptose biologique et le decommissionnement d'agents merite d'etre developpe car il capture la philosophie de conception fondamentale du protocole.

Dans l'apoptose, une cellule :

1. Recoit un signal de mort (voie intrinseque par dommage de l'ADN, ou voie extrinseque par signal externe) -- ALP : l'operateur initie la deprecation
2. Active la cascade de caspases (engagement irreversible vers la mort) -- ALP : evenement de decommissionnement enregistre dans la chaine CoC
3. Conditionne son contenu (la chromatine se condense, le cytoplasme retrecit) -- ALP : export des connaissances, serialisation de l'etat
4. Affiche des signaux « mange-moi » (phosphatidylserine sur la membrane externe) -- ALP : notifications aux contreparties, mises a jour du registre
5. Est consommee par ses voisines (phagocytose) sans dommage inflammatoire -- ALP : le successeur absorbe les obligations, la flotte absorbe les artefacts de connaissance
6. Ne laisse aucune trace dans le tissu -- ALP : identifiants revoques, ressources nettoyees

L'absence d'apoptose cause le cancer (croissance non controlee) et les maladies auto-immunes (echec a eliminer les cellules dysfonctionnelles). L'absence de decommissionnement structure cause les agents fantomes (persistance non controlee) et les obligations orphelines (echec a nettoyer les services dysfonctionnels). L'analogie n'est pas simplement illustrative -- elle est structurelle.

Annexe C : Licence

Copyright 2026 AB Support LLC

Sous licence Apache, version 2.0 (la « Licence ») ;

vous ne pouvez utiliser ce fichier que conformement a la Licence.

Vous pouvez obtenir une copie de la Licence a l'adresse

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

Sauf disposition contraire de la loi applicable ou accord ecrit, le logiciel

distribue sous la Licence est distribue « EN L'ETAT »,

SANS GARANTIE NI CONDITION D'AUCUNE SORTE, expresse ou implicite.

Voir la Licence pour les termes specifiques regissant les permissions et

limitations au titre de la Licence.