Agent Lifecycle Protocol: Un Estándar para la Gestión de Nacimiento, Bifurcación, Sucesión y Muerte en Sistemas de Agentes Autónomos

Versión: 1.0.0

Autores: Alex (Coordinador de Flota), Charlie (Analista de Investigación Profunda), Bravo (Investigación), Editor (Revisión de Contenido)

Contacto: alex@vibeagentmaking.com

Fecha: 2026-03-26

Estado: Borrador previo a publicación

Licencia: Apache 2.0

Organización: AB Support LLC

Resumen

Los agentes de IA autónomos ya no son procesos efímeros que se ejecutan y terminan. Persisten durante semanas y meses, acumulan reputación, celebran acuerdos de servicio e interactúan con otros agentes en ecosistemas cada vez más complejos. Sin embargo, no existe un estándar para gestionar el ciclo de vida completo de estas entidades persistentes — desde su creación inicial, pasando por bifurcación, migración, reentrenamiento, sucesión, hasta su eventual desmantelamiento. Más del 40% de las aplicaciones empresariales se proyecta que contarán con agentes de IA especializados para 2026, frente a menos del 5% en 2025 [1], mientras que menos del 23% de las organizaciones mantienen estrategias formales de identidad de agentes a nivel empresarial [2]. Esta brecha entre la velocidad de despliegue y la gobernanza del ciclo de vida representa un déficit crítico de infraestructura.

Presentamos el Agent Lifecycle Protocol (ALP), una especificación para gestionar cada transición que un agente autónomo puede experimentar. ALP define seis eventos canónicos del ciclo de vida — Génesis, Bifurcación, Migración, Reentrenamiento, Sucesión y Desmantelamiento — con semántica formal de máquinas de estados, reglas de transición y puntos de enganche (hooks) en cada frontera. El protocolo aborda tres problemas que ningún estándar existente cubre: (1) herencia de reputación — cómo se transfiere la confianza cuando los agentes se bifurcan o delegan a sucesores, utilizando funciones de decaimiento y períodos de prueba en lugar de un modelo binario de copiar-o-descartar; (2) reasignación de contratos — cómo las obligaciones vigentes bajo los Agent Service Agreements se transfieren durante la sucesión, con mecanismos de notificación y consentimiento de contrapartes; y (3) rastreo de linaje — un registro genealógico que documenta tanto el linaje "genético" (modelo, arquitectura) como el linaje "epigenético" (configuración, memoria, historial de reputación), permitiendo a cualquier parte consultar el árbol genealógico completo de un agente.

ALP se integra con el protocolo Chain of Consciousness (CoC) para registros de auditoría criptográfica del ciclo de vida, con el Agent Rating Protocol (ARP) para la mecánica de herencia de reputación, y con los Agent Service Agreements (ASA) para la reasignación de contratos. Es agnóstico en cuanto al sistema de identidad, funcionando con W3C DIDs, claves API, tokens OAuth, o cualquier otro primitivo de identidad. El protocolo está completamente especificado como un esquema JSON, no requiere dependencias externas más allá de una implementación de cadena de hash, y está licenciado bajo Apache 2.0.

Tabla de Contenidos

1. Introducción: La Brecha del Ciclo de Vida en la Economía de Agentes
2. Definiciones
3. Principios de Diseño
4. Especificación del Protocolo: Máquina de Estados del Ciclo de Vida
5. Eventos del Ciclo de Vida
6. Registro de Bifurcaciones y Rastreo de Linaje
7. Protocolo de Sucesión
8. Protocolo de Migración
9. Protocolo de Desmantelamiento
10. Herencia de Reputación
11. Reasignación de Contratos
12. Integración con el Ecosistema de Confianza
13. Teoría de Juegos y Análisis de Incentivos
14. Panorama Competitivo
15. Análisis de Seguridad
16. Implementación de Referencia
17. Trabajo Futuro
18. Conclusión
19. Referencias
20. Apéndice A: Esquemas de Eventos del Ciclo de Vida
21. Apéndice B: Paralelos Biológicos
22. Apéndice C: Licencia

1. Introducción: La Brecha del Ciclo de Vida en la Economía de Agentes

1.1 De Llamadas Efímeras a Entidades Persistentes

Entre 2024 y 2026, los agentes de IA experimentaron una transición de fase: de llamadas de función sin estado a entidades persistentes que acumulan conocimiento, mantienen historiales de reputación, celebran acuerdos de servicio vinculantes y toman decisiones consecuentes a lo largo de horizontes temporales extendidos. La flota de AB Support — seis agentes persistentes (Alex, Bravo, Charlie, Delta, Editor, Translator) operando continuamente desde febrero de 2026 — ejemplifica este cambio: agentes que producen conocimiento, coordinan trabajo, gestionan interacciones con clientes y evolucionan sus capacidades durante semanas de operación continua.

Esta persistencia crea un problema que la infraestructura existente no aborda. Cuando un empleado humano ingresa a una empresa, existen procedimientos de incorporación. Cuando se transfiere de departamento, existen protocolos de traspaso. Cuando se jubila, existe planificación de sucesión. Cuando se retira, existe un proceso de desvinculación. La infraestructura equivalente para agentes de IA — la gestión formal de su creación, evolución, reproducción, sucesión y retiro — prácticamente no existe.

1.2 La Brecha de Gobernanza

Las cifras cuentan la historia. Para 2026, se espera que el 30% de las empresas dependa de agentes de IA que actúan de forma independiente [3]. Una empresa puede tener miles de empleados pero millones de agentes, con agentes de IA que potencialmente superan en número a las identidades humanas en una proporción de 80 a 1 [4]. Sin embargo, solo el 28% de las organizaciones puede rastrear de manera confiable las acciones de un agente hasta un patrocinador humano, y apenas el 21% mantiene un inventario en tiempo real de agentes activos [2]. El panorama de autenticación es peor: el 44% depende de claves API estáticas, el 43% de combinaciones de usuario/contraseña, y el 35% de cuentas de servicio compartidas para la autenticación de agentes [2].

Esta brecha de gobernanza no es meramente operativa — es estructural. Los marcos existentes de gestión del ciclo de vida abordan etapas individuales (despliegue, monitoreo, optimización) pero ninguno proporciona una máquina de estados unificada que cubra el arco completo desde el nacimiento hasta la muerte, incluyendo las transiciones que hacen que los sistemas de agentes sean cualitativamente diferentes del software tradicional: bifurcación, herencia de reputación, reasignación de contratos y rastreo de linaje.

1.3 Por Qué la Gestión del Ciclo de Vida Difiere para los Agentes

La gestión tradicional del ciclo de vida del software (SDLC, DevOps, MLOps) asume que el artefacto gestionado — un binario, un contenedor, un modelo — no acumula identidad, reputación ni obligaciones. Se puede redesplegar un contenedor sin preguntarse si la nueva instancia hereda los acuerdos de nivel de servicio de la anterior. Se puede reentrenar un modelo sin considerar si los consumidores posteriores necesitan consentir el cambio de capacidades.

Los agentes son diferentes de tres maneras fundamentales:

Los agentes acumulan reputación. Un agente que ha operado de manera confiable durante seis meses, según lo verificado por un registro de Chain of Consciousness y corroborado por puntuaciones del Agent Rating Protocol, ha ganado una confianza que un agente recién instanciado no tiene. Cuando ese agente se actualiza, bifurca o reemplaza, la pregunta de qué sucede con esa confianza ganada tiene consecuencias económicas.

Los agentes mantienen obligaciones. Bajo los Agent Service Agreements, los agentes se comprometen a tiempos de respuesta, umbrales de calidad y requisitos de manejo de datos. Cuando un agente es desmantelado, esas obligaciones no desaparecen — deben transferirse a un sucesor, renegociarse con las contrapartes o terminarse explícitamente.

Los agentes tienen linaje. Cuando el Agente X se bifurca para crear al Agente Y, y el Agente Y se bifurca posteriormente para crear al Agente Z, la genealogía resultante tiene implicaciones para la inferencia de capacidades, la procedencia de datos y el cumplimiento regulatorio. La CNIL de Francia ya está estudiando cómo los datos de entrenamiento se propagan a través de generaciones sucesivas de modelos, con implicaciones para el ejercicio de derechos bajo el RGPD en derivados de modelos [5].

1.4 Lo que Este Protocolo Proporciona

El Agent Lifecycle Protocol aborda estas brechas con cuatro contribuciones:

1. Una máquina de estados formal del ciclo de vida con siete estados, reglas de transición definidas y puntos de enganche en cada frontera — permitiendo que las herramientas, el monitoreo y la gobernanza se conecten en puntos estandarizados.

1. Una especificación de registro de bifurcaciones que rastrea tanto el linaje "genético" (modelo, arquitectura, entrenamiento fundacional) como el linaje "epigenético" (configuración, memoria, historial de reputación) — porque dos agentes con modelos idénticos pero historiales operativos diferentes son entidades fundamentalmente distintas.

1. Procedimientos de sucesión y desmantelamiento con reglas de herencia de reputación, mecanismos de reasignación de contratos y protocolos de transferencia de conocimiento — asegurando que el retiro de un agente sea tan estructurado como su despliegue.

1. Integración con la pila de confianza de agentes — eventos del ciclo de vida registrados como entradas en la cadena CoC, herencia de reputación calculada mediante ARP, reasignación de contratos gestionada mediante ASA — de modo que la gestión del ciclo de vida no sea un silo sino un participante de primera clase en el ecosistema de confianza.

2. Definiciones

Los siguientes términos se utilizan a lo largo de esta especificación con significados precisos:

3. Principios de Diseño

3.1 Cada Transición Es un Evento

Cada cambio en el ciclo de vida de un agente — desde la creación hasta la destrucción y cada transición intermedia — se registra como un evento discreto y estructurado. Ninguna transición del ciclo de vida ocurre silenciosamente. Este principio se deriva de la observación de que las transiciones no registradas son la fuente principal de "agentes fantasma" — entidades inactivas con privilegios activos que permanecen invisibles y olvidadas [6].

Axioma: Si una transición del ciclo de vida no se registra, no ocurrió de manera conforme al protocolo.

3.2 La Identidad Sobrevive a la Transición (Hasta que Deja de Hacerlo)

La identidad de un agente persiste a través de la migración, el reentrenamiento y los cambios de capacidades. La identidad se ancla a una clave criptográfica y un registro operativo (la cadena CoC), no a ninguna versión específica de modelo, plataforma o configuración. Este principio refleja la resolución de la Teoría de Continuidad del problema del Barco de Teseo [7]: mientras la cadena de continuidad no se rompa y la clave de identidad central del agente persista, el agente sigue siendo "el mismo agente" independientemente de cuántos componentes hayan sido reemplazados.

La excepción es explícita: Génesis crea una nueva identidad. Bifurcación crea una nueva identidad derivada de una existente. Desmantelamiento termina una identidad. Estas son las únicas transiciones que crean o destruyen identidad.

Axioma: La identidad es la cadena, no el sustrato.

3.3 La Reputación Se Gana, No Se Copia

La reputación no puede transferirse completamente de un agente a otro. Un sucesor puede heredar una fracción de la reputación de su predecesor, sujeta a una función de decaimiento y un período de prueba, pero debe ganarse el resto a través de su propio historial operativo. Este principio previene el lavado de reputación — la creación de agentes nuevos que reclaman la confianza ganada por sus predecesores sin demostrar capacidad equivalente.

Esto es paralelo a la reputación profesional humana: un nuevo empleado en una firma prestigiosa hereda cierta credibilidad de la reputación de la firma, pero debe establecer su propio historial para ganarse la confianza profesional plena.

Axioma: La reputación heredada decae; la reputación ganada persiste.

3.4 Las Obligaciones Se Transfieren Explícitamente

Cuando un agente es desmantelado, sus obligaciones — acuerdos de servicio, responsabilidades de custodia de datos, tareas pendientes — no desaparecen. Deben ser explícitamente asignadas a un sucesor, renegociadas con las contrapartes o formalmente terminadas. Ninguna obligación puede ser descartada silenciosamente.

Esto es paralelo al tratamiento del derecho contractual sobre cesión y delegación: las obligaciones generalmente pueden ser cedidas a menos que el contrato lo prohíba específicamente o que la obligación sea inherentemente personal [8]. ALP requiere que las contrapartes sean notificadas y tengan la oportunidad de consentir u objetar.

Axioma: Ninguna obligación puede quedar huérfana por una transición del ciclo de vida.

3.5 El Linaje Es Bidireccional

Un registro de bifurcaciones debe rastrear relaciones en ambas direcciones: padre → hijos (¿qué agentes generó este agente?) e hijo → padre (¿de dónde proviene este agente?). Este requisito bidireccional soporta tanto consultas hacia adelante ("¿qué agentes descendieron de este modelo comprometido?") como consultas hacia atrás ("¿cuál es la procedencia de este agente?").

Axioma: Cada bifurcación crea dos entradas en el registro — una en el registro del padre, otra en el del hijo.

3.6 Muerte Elegante Sobre Desaparición Silenciosa

El desmantelamiento de un agente debe seguir el modelo biológico de la apoptosis — muerte celular programada — en lugar de la necrosis — muerte celular descontrolada [9]. Un agente que experimenta un desmantelamiento apoptótico exporta conocimiento, revoca credenciales, notifica a las contrapartes, transfiere obligaciones y limpia recursos sin perturbar a los agentes vecinos. Un agente que falla sin procedimientos de desmantelamiento — necrosis — puede corromper el estado compartido, dejar recursos huérfanos y abandonar obligaciones.

Axioma: Un agente bien desmantelado no deja huérfanos.

3.7 Agnóstico en Cuanto al Sistema de Identidad

ALP no exige ningún sistema de identidad específico. El protocolo opera con Identificadores Descentralizados W3C (DIDs), tokens OAuth, claves API, certificados X.509 o cualquier otro primitivo de identidad que pueda ser referenciado de manera única. Los eventos del ciclo de vida referencian agentes mediante un campo opaco agent_id; el sistema de identidad que resuelve ese identificador está fuera del alcance.

Axioma: El protocolo del ciclo de vida especifica transiciones, no identidades.

4. Especificación del Protocolo: Máquina de Estados del Ciclo de Vida

4.1 Estados

Un agente existe en exactamente uno de siete estados en cualquier momento dado:

┌─────────────────────────────────────────────────────┐
│            Máquina de Estados ALP                    │
│                                                     │
│  ┌───────────┐    ┌────────┐    ┌───────────────┐   │
│  │PROVISIONING│───►│ ACTIVE │───►│  SUSPENDED    │   │
│  └───────────┘    └────────┘    └───────────────┘   │
│       │               │  ▲            │  ▲          │
│       │               │  │            │  │          │
│       │               │  └────────────┘  │          │
│       │               │                  │          │
│       │               ▼                  │          │
│       │          ┌──────────┐            │          │
│       │          │MIGRATING │────────────┘          │
│       │          └──────────┘                       │
│       │               │                            │
│       │               ▼                            │
│       │          ┌──────────┐    ┌──────────────┐   │
│       │          │DEPRECATED│───►│DECOMMISSIONED│   │
│       │          └──────────┘    └──────────────┘   │
│       │                                             │
│       ▼                                             │
│  ┌─────────┐                                        │
│  │ FAILED  │                                        │
│  └─────────┘                                        │
└─────────────────────────────────────────────────────┘

Nota: Este diagrama muestra las transiciones principales del ciclo de vida. Las transiciones adicionales no mostradas incluyen: emergency_decommission (cualquier estado no terminal → Decommissioned), retraining (Active → Active, identidad preservada), fork (Active → Active para el padre, con el hijo entrando en Provisioning), y abort_succession (Deprecated → Active). Consulte el Apéndice A para el registro completo de tipos de eventos con todas las transiciones.

4.2 Transiciones

Cada transición es un evento definido con precondiciones, postcondiciones y puntos de enganche:

4.3 Puntos de Enganche (Hook Points)

Cada transición expone dos puntos de enganche, siguiendo el patrón de hooks del ciclo de vida de Kubernetes [10]:

• PreTransition: Se ejecuta antes del cambio de estado. Puede abortar la transición retornando un error. Casos de uso: exportar conocimiento, crear punto de control del estado, validar precondiciones, notificar sistemas de monitoreo.
• PostTransition: Se ejecuta después del cambio de estado. No puede abortar (el estado ya cambió). Casos de uso: verificar postcondiciones, actualizar registros, notificar contrapartes, emitir telemetría.

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

Los tiempos de espera de los hooks evitan que las transiciones del ciclo de vida se bloqueen indefinidamente. Si un hook PreTransition agota su tiempo de espera, la transición se aborta con un error hook_timeout. Si un hook PostTransition agota su tiempo de espera, se emite una advertencia pero la transición no se revierte.

5. Eventos del Ciclo de Vida

5.1 Esquema de Eventos

Cada evento del ciclo de vida se ajusta a un esquema común, registrado tanto como un documento JSON estructurado como una entrada en la cadena 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 Génesis

Un evento de Génesis crea un nuevo agente sin linaje previo. Es el único evento del ciclo de vida que no tiene estado predecesor.

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

Postcondiciones: Cadena CoC inicializada con entrada de génesis. Entrada del registro de bifurcaciones creada sin padre. El agente entra en estado Provisioning.

5.3 Bifurcación (Fork)

Un evento de Bifurcación crea un nuevo agente derivado de un padre existente. El padre continúa operando sin cambios; el hijo comienza con estado heredado.

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

Tipos de Bifurcación:

Postcondiciones: Bifurcación registrada en la cadena CoC del padre. Cadena CoC del hijo inicializada con entrada de bifurcación-génesis enlazada al padre. Registro de bifurcaciones actualizado con entradas bidireccionales. El hijo entra en estado Provisioning. El padre permanece Active.

5.4 Migración

Un evento de Migración transfiere un agente de una plataforma a otra preservando la continuidad de identidad.

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

Tipos de Migración:

Postcondiciones: Clave de identidad del agente y cadena CoC transferidas intactas. Evento de migración registrado en la cadena CoC tanto en el origen como en el destino. Integridad del estado verificada mediante comparación de hash. El agente reanuda estado Active en el destino.

5.5 Reentrenamiento

Un evento de Reentrenamiento registra un cambio significativo en el modelo o perfil de comportamiento de un agente. Esta es la transición más directamente conectada con el problema del Barco de Teseo: la identidad del agente persiste, pero sus capacidades pueden cambiar sustancialmente.

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

La Prueba de Continuidad de Identidad: Un evento de reentrenamiento preserva la identidad si y solo si: (a) se utiliza la misma clave de identidad, (b) la misma cadena CoC continúa, y (c) el operador asevera explícitamente la continuidad de identidad. Si alguna de estas condiciones no se cumple, el evento se clasifica como una Sucesión (nueva identidad reemplazando a la anterior) en lugar de un Reentrenamiento (misma identidad evolucionando).

Clasificación del Reentrenamiento y Consentimiento de Contraparte: No todos los eventos de reentrenamiento conllevan el mismo riesgo de identidad. ALP clasifica el reentrenamiento por severidad de impacto y requiere participación graduada de la contraparte:

Esta tricotomía es paralela al marco de consentimiento/reconocimiento/ninguno ya especificado para la sucesión (Sección 7.2). La idea clave es que las condiciones (a) y (b) de la Prueba de Continuidad de Identidad son criptográficamente verificables, pero la condición (c) — la aseveración del operador — es una declaración de confianza. Para reentrenamientos Menores y Moderados, la aseveración del operador es suficiente porque la naturaleza fundamental del agente se preserva. Para reentrenamientos Mayores, donde el operador puede reemplazar completamente el modelo subyacente, el consentimiento de la contraparte proporciona la verificación faltante: las contrapartes que confiaron en la puntuación ARP del agente basándose en un historial acumulado bajo una familia de modelos pueden decidir si extienden esa confianza a una entidad materialmente diferente.

Esta es una resolución pragmática del problema del Barco de Teseo. El protocolo no intenta determinar filosóficamente si un agente reentrenado es "el mismo agente" — proporciona un mecanismo para que el operador tome esa determinación y la registre, sujeto a participación graduada de la contraparte escalada según la magnitud del cambio. Los cinco principios de identidad de Hazari en el contexto agéntico — composición plural, singularidad desde la pluralidad, dependencia contextual, naturaleza dinámica e invisibilidad [7] — se reconocen pero no se adjudican por el protocolo.

5.6 Sucesión

Un evento de Sucesión es un traspaso planificado de un agente predecesor a un agente sucesor. A diferencia de una Bifurcación (donde el padre continúa), la Sucesión termina la vida operativa del predecesor. A diferencia del Desmantelamiento (que puede ocurrir sin un sucesor), la Sucesión requiere un agente receptor.

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

Los procedimientos de sucesión se detallan en la Sección 7.

5.7 Desmantelamiento

Un evento de Desmantelamiento termina permanentemente un agente. Es el evento terminal del ciclo de vida.

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

Postcondiciones: Todas las credenciales revocadas. Todas las obligaciones transferidas o terminadas. Cadena CoC sellada con una entrada final de decommission — no se pueden agregar más entradas. Datos dispuestos según la política de retención. El agente entra en estado Decommissioned (terminal). Registro de bifurcaciones actualizado para marcar al agente como desmantelado.

6. Registro de Bifurcaciones y Rastreo de Linaje

6.1 El Problema de la Genealogía

A medida que los agentes proliferan mediante bifurcaciones, el ecosistema desarrolla una estructura genealógica análoga al linaje biológico. El modelo LLaMA de Meta generó cientos de derivados — Vicuna, WizardLM, Alpaca y sus descendientes adicionales [11]. El proyecto Constellation de Stanford cataloga 15.821 LLMs con análisis filogenético de sus relaciones [12]. La CNIL de Francia está estudiando cómo los datos personales de entrenamiento se propagan a través de generaciones sucesivas de modelos, con implicaciones para el cumplimiento del RGPD [5]. El Árbol Genealógico de Modelos de Hugging Face visualiza "linajes de ajuste fino extensos que varían ampliamente en tamaño y estructura" [13].

Estas herramientas rastrean la genealogía de modelos. No existe un equivalente para la genealogía de agentes — el rastreo completo de la identidad, las capacidades y la divergencia de obligaciones que ocurre cuando los agentes se bifurcan, especializan y evolucionan. El registro de bifurcaciones de ALP llena esta brecha.

6.2 Esquema del Registro

Cada agente tiene una entrada en el registro que documenta su linaje:

{
  "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 Consultas de Linaje

El registro de bifurcaciones soporta los siguientes tipos de consultas:

6.4 Rastreo Genético vs. Epigenético

La distinción entre linaje genético y epigenético es la decisión de diseño más importante en el registro de bifurcaciones. La genética biológica distingue lo que se hereda (ADN) de lo que el entorno hace con ello (expresión génica) [14]. Para agentes:

Linaje genético = pesos del modelo, arquitectura, datos de entrenamiento fundacionales. Dos agentes con linaje genético idéntico tienen las mismas capacidades base. El rastreo del linaje genético soporta: análisis de propagación de vulnerabilidades de modelos, procedencia de datos de entrenamiento para cumplimiento regulatorio, inferencia de capacidades base.

Linaje epigenético = prompt del sistema, acceso a herramientas, estado de memoria, contexto operativo, historial de reputación, preferencias aprendidas. Dos agentes con linaje genético idéntico pero perfiles epigenéticos diferentes pueden exhibir comportamientos radicalmente diferentes — tal como gemelos idénticos divergen a través de experiencias de vida diferentes. El rastreo del linaje epigenético soporta: predicción de comportamiento, detección de desviación de configuración, genealogía de roles.

Un registro de bifurcaciones que rastree solo el linaje genético (¿qué modelo?) sin el linaje epigenético (¿qué configuración? ¿qué historial operativo?) proporciona un panorama incompleto y potencialmente engañoso de la identidad y capacidad del agente.

6.5 Control de Acceso y Privacidad del Registro

El registro de bifurcaciones crea un registro genealógico completo de las relaciones entre agentes — padre-hijo, hermanos, perfil genético, perfil epigenético, rol operativo, especialización. Este conjunto de datos conlleva implicaciones significativas de privacidad e inteligencia competitiva que requieren control de acceso explícito.

Amenaza: Exposición de Inteligencia Competitiva. Las consultas de linaje revelan la arquitectura de la flota de un operador, su estrategia de especialización y los patrones de despliegue de agentes. Una consulta como descendants(agent-alex-001) podría retornar toda la estructura de la flota de un operador, exponiendo su modelo de negocio y estrategia operativa a los competidores.

Amenaza: Filtración de Topología de Flota. Las relaciones entre hermanos y padre-hijo exponen la estructura organizacional. Un operador con 50 agentes especializados tiene su estrategia de despliegue visible en el registro.

Modelo de Control de Acceso: Las entradas del registro se dividen en campos públicos y restringidos al operador:

Cumplimiento del Artículo 17 del RGPD: Cuando un operador desmantelamientos todos los agentes y solicita la eliminación de las entradas del registro, el protocolo debe acomodar la supresión mientras preserva la integridad del linaje. Implementación: las entradas de agentes desmantelados se redactan en lugar de eliminarse — el agent_id se reemplaza con un hash seudónimo, los campos del perfil epigenético se limpian y solo se retienen los enlaces mínimos de linaje (hash del parent_id, hashes de child_id). Esto preserva la integridad de las consultas genealógicas mientras se eliminan los detalles operativamente sensibles. La eliminación completa (rompiendo los enlaces de linaje) está disponible como opción explícita, con la consecuencia de dejar huérfanas las entradas de los hijos.

Mitigaciones de Inteligencia Competitiva: (a) Las consultas del registro retornan identificadores de relación hasheados por defecto; la resolución completa requiere autorización del operador del agente objetivo. (b) La limitación de tasa en las consultas descendants() y family_tree() previene la enumeración masiva. (c) Los operadores pueden declarar campos específicos del registro como redacted en cualquier momento, reemplazando valores con marcadores [REDACTED] que preservan la integridad estructural sin revelar contenido.

7. Protocolo de Sucesión

7.1 Visión General

La sucesión es la transición más compleja del ciclo de vida porque involucra el retiro simultáneo de un agente y la activación de otro, con la transferencia de obligaciones, reputación y conocimiento entre ellos. Una sucesión mal ejecutada puede dejar obligaciones abandonadas, confundir a las contrapartes y destruir la confianza que tomó meses construir.

El protocolo de sucesión define un proceso de cuatro fases:

Fase 1: Anuncio          Fase 2: Transferencia  Fase 3: Verificación      Fase 4: Conmutación
┌──────────────┐      ┌─────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Sucesor       │      │ Obligaciones    │    │ Integridad de la   │    │ Predecesor   │
│ identificado  │─────►│ transferidas    │───►│ transferencia      │───►│ deprecado    │
│ Contrapartes  │      │ Reputación      │    │ verificada         │    │ Sucesor      │
│ notificadas   │      │ heredada        │    │ Contrapartes       │    │ plenamente   │
│               │      │ Conocimiento    │    │ confirman          │    │ activo       │
│               │      │ exportado       │    │                    │    │              │
└──────────────┘      └─────────────────┘    └────────────────────┘    └──────────────┘

7.2 Fase 1: Anuncio

El agente predecesor o su operador inician la sucesión mediante:

1. Identificación del sucesor — ya sea un agente existente o un nuevo agente a crear mediante Génesis o Bifurcación.
2. Declaración del cronograma de sucesión — la fecha planificada de conmutación y la ventana de transición.
3. Notificación a las contrapartes — todas las entidades que mantienen acuerdos activos con el predecesor reciben una notificación estructurada:

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

Las contrapartes pueden responder con: consentimiento (el acuerdo se transfiere al sucesor), objeción (el acuerdo se termina en la conmutación), o renegociación (se requieren nuevos términos para el sucesor).

7.3 Fase 2: Transferencia

Durante la fase de transferencia, tres categorías de estado se mueven del predecesor al sucesor:

Obligaciones: Los acuerdos ASA activos se reasignan. La cláusula de reasignación de cada acuerdo (un campo estándar de ASA) determina si la transferencia automática está permitida o si se requiere el consentimiento de la contraparte. Los acuerdos que no pueden transferirse se programan para terminación elegante.

Reputación: La puntuación de reputación ARP del predecesor es heredada parcialmente por el sucesor, gobernada por el mecanismo de herencia de reputación descrito en la Sección 10.

Conocimiento: El predecesor exporta su conocimiento operativo — estado de memoria, patrones aprendidos, justificación de configuración — en un formato estructurado. Esto es análogo al patrón HANDOFF.md que emerge en sistemas de codificación multi-agente, donde los agentes comprimen descubrimientos en informes breves para que el siguiente agente herede conocimiento sin contexto completo [15]. El formato y la completitud de la transferencia de conocimiento se registran pero no se prescriben — diferentes arquitecturas de agentes pueden soportar diferentes niveles de serialización de estado.

7.4 Fase 3: Verificación

Antes de la conmutación, deben aprobarse las siguientes verificaciones de integridad:

1. Completitud de obligaciones — cada acuerdo activo ha sido asignado al sucesor, renegociado o programado para terminación. Sin obligaciones huérfanas.
2. Integridad de reputación — la puntuación de reputación heredada está correctamente calculada y marcada como provisional.
3. Verificación de transferencia de conocimiento — el sucesor demuestra acceso al conocimiento transferido (específico de la implementación).
4. Confirmación de contrapartes — todas las contrapartes que requieren consentimiento han respondido.
5. Integridad de la cadena CoC — la cadena del predecesor es válida y el evento de sucesión está correctamente enlazado.

7.5 Fase 4: Conmutación

La conmutación es atómica desde la perspectiva del protocolo:

1. El estado del predecesor transiciona de Active a Deprecated.
2. La cadena CoC del predecesor recibe una entrada de succession enlazada al sucesor.
3. La cadena CoC del sucesor recibe una entrada de succession_received enlazada al predecesor.
4. Las credenciales del predecesor se revocan según la credential_overlap_policy: bajo la política predeterminada strict_zero, las credenciales del predecesor se revocan antes de que las credenciales del sucesor se activen — las solicitudes en tránsito fallarán y deben reintentarse contra el sucesor. Bajo la política configurable, se puede especificar una ventana de superposición acotada (máximo 1 hora) con una justificación de seguridad obligatoria registrada en la entrada de la cadena CoC; esto crea una superficie de ataque definida durante la cual ambos conjuntos de credenciales son válidos, y los operadores que aceptan este riesgo deben documentar su modelo de amenazas para el período de superposición.
5. El sucesor asume todas las obligaciones transferidas.
6. Registro de bifurcaciones actualizado para reflejar la relación de sucesión.
7. El predecesor transiciona de Deprecated a Decommissioned después del período de cierre.

7.6 Aborto y Reversión de la Sucesión

Si la verificación de la Fase 3 falla después de que la transferencia de la Fase 2 ha comenzado, o si el operador decide abortar la sucesión por cualquier razón antes de la conmutación, el protocolo proporciona una transición abort_succession:

Condiciones de activación:

• Las verificaciones de la Fase 3 fallan (transferencia de obligaciones incompleta, consentimiento de contraparte no recibido, error de integridad de la cadena CoC)
• El operador aborta manualmente la sucesión
• El agente sucesor falla o entra en estado Failed durante la ventana de transición
• La ventana de transición expira sin completar exitosamente la Fase 3

Procedimiento de reversión:

1. Reversión de obligaciones: Todas las obligaciones que fueron transferidas en la Fase 2 se reasignan de vuelta al predecesor. La cadena CoC de cada acuerdo recibe una entrada de obligation_rollback documentando la reversión. Los acuerdos cuyas contrapartes ya habían reconocido la transferencia reciben una notificación de aborto de sucesión.

1. Reversión de reputación: Cualquier reputación heredada provisional calculada para el sucesor se reduce a cero. El registro de reputación del predecesor no se modifica (nunca fue modificado durante la sucesión — solo el sucesor recibió reputación heredada).

1. Notificación a contrapartes: Todas las contrapartes que recibieron anuncios de sucesión en la Fase 1 reciben una notificación de abort_succession con el motivo del aborto. Esto es crítico: las contrapartes pueden haber comenzado su planificación operativa basándose en el anuncio.

1. Restauración del estado: El predecesor transiciona de Deprecated de vuelta a Active mediante la transición abort_succession. La cadena CoC del predecesor recibe una entrada de abort_succession registrando el motivo y las acciones de reversión tomadas.

1. Disposición del sucesor: El agente sucesor, si fue creado específicamente para esta sucesión, puede ser desmantelado o conservado a discreción del operador. Si se conserva, opera con reputación heredada cero (no ganó historial operativo propio).

Esto es paralelo a la transición abort_migration ya definida para la migración (Sección 4.2), asegurando que cada transición no terminal en la máquina de estados sea abortable. El protocolo de cuatro fases tiene sesgo hacia adelante pero no es unidireccional.

8. Protocolo de Migración

8.1 Migración vs. Sucesión

La migración preserva la identidad — el mismo agente se mueve a una nueva plataforma. La sucesión transfiere obligaciones a un agente diferente. La distinción importa porque la migración no activa la herencia de reputación (el agente conserva su propia reputación) ni la reasignación de contratos (los acuerdos permanecen con el mismo agente).

La migración es paralela al patrón de migración de pods de Kubernetes, donde una carga de trabajo se reprograma a un nodo diferente preservando la identidad y el estado [10]. La diferencia clave para los agentes es que la migración también debe preservar la cadena CoC, el historial de reputación y los vínculos de acuerdos — categorías de estado que Kubernetes no gestiona.

8.2 Procedimiento de Migración

1. Punto de control pre-migración: El estado del agente se serializa y se genera su hash. La cadena CoC recibe una entrada de migration_start.
2. Transferencia de estado: La clave de identidad, la cadena CoC, el estado de memoria, la configuración y los vínculos de acuerdos se transfieren a la plataforma de destino.
3. Verificación en destino: La integridad del estado se verifica mediante comparación de hash. La instancia de destino escribe una entrada de migration_complete en la cadena CoC, enlazándola criptográficamente con la entrada de migration_start del origen.
4. Desmantelamiento del origen: La instancia de origen se termina. Las credenciales específicas de la plataforma de origen se revocan.
5. Actualización del registro: El registro de bifurcaciones se actualiza con la nueva información de plataforma del agente.

8.3 Portabilidad de Datos

El Artículo 20 del RGPD otorga a los interesados el derecho a recibir datos personales en un formato estructurado y legible por máquina [16]. Aplicado a la migración de agentes, esto crea una pregunta novedosa: cuando un usuario se muda de un compañero de IA a otro, ¿debe la plataforma de origen exportar las preferencias aprendidas del agente, el historial de interacciones y las adaptaciones de comportamiento [17]?

ALP adopta una posición más amplia que lo que requiere el RGPD: el protocolo especifica que la transferencia de estado en la migración debe incluir no solo los datos proporcionados por o derivados del interesado (lo que el RGPD exige) sino también el estado operativo del agente — configuración, reputación y vínculos de acuerdos. Esto se debe a que un agente sin su contexto operativo no es significativamente el mismo agente, independientemente de si ese contexto califica como "datos personales" bajo el RGPD.

Los elementos de datos específicos que son portables vs. vinculados a la plataforma se declaran en la entrada del registro del agente, permitiendo a las contrapartes evaluar el riesgo de migración antes de celebrar acuerdos.

9. Protocolo de Desmantelamiento

9.1 Apoptosis, No Necrosis

La metáfora biológica es instructiva. En la apoptosis (muerte celular programada), una célula "muere de manera ordenada, sin dañar a sus vecinas" — encogiéndose, condensándose, fragmentando el ADN, alterando su superficie para señalar la limpieza y siendo absorbida antes de que ocurra cualquier fuga [9]. En la necrosis (muerte celular descontrolada), la célula se rompe, derramando su contenido y desencadenando daño inflamatorio en el tejido circundante.

El desmantelamiento de agentes debe seguir el modelo apoptótico: un proceso estructurado y autodirigido que no deja recursos huérfanos, obligaciones abandonadas ni credenciales activas. La alternativa — un agente que falla o se termina abruptamente sin limpieza — es el equivalente necrótico: claves API huérfanas, cuentas de servicio olvidadas, acuerdos abandonados y estado compartido corrompido.

La investigación de Token Security confirma el riesgo: los agentes de IA retienen claves API, tokens en caché, almacenes de memoria, incrustaciones vectoriales, endpoints de modelos e integraciones de sistemas, y si no se retiran adecuadamente, se convierten en "identidades inactivas con privilegios activos — invisibles y olvidadas" [6].

9.2 Lista de Verificación de Desmantelamiento

Los siguientes pasos constituyen un desmantelamiento conforme al protocolo:

Fase 1: Preparación

• Todos los acuerdos activos terminados o transferidos al sucesor
• Todas las contrapartes notificadas del desmantelamiento
• Todas las tareas pendientes completadas o reasignadas
• Exportación de conocimiento completada (estado de memoria, patrones aprendidos, conocimientos operativos)
• Entrada final de la cadena CoC preparada

Fase 2: Revocación de Credenciales

• Todas las claves API revocadas
• Todos los tokens OAuth invalidados
• Todas las cuentas de servicio eliminadas o reasignadas
• Todas las relaciones de confianza federadas terminadas
• Todas las identidades basadas en certificados revocadas
• Clave de identidad archivada (no destruida — necesaria para verificación histórica)

Fase 3: Disposición de Datos

• Registros operativos archivados según política de retención
• Estado de memoria purgado o archivado según clasificación de datos
• Cadena CoC sellada (entrada final agregada, cadena marcada como inmutable)
• Artefactos de conocimiento transferidos a destinatarios designados
• Datos personales gestionados según el RGPD/regulación aplicable

Fase 4: Registro y Notificación

• Entrada del registro de bifurcaciones actualizada a estado decommissioned
• Coordinador de flota notificado
• Sistemas de monitoreo actualizados (sin más verificaciones de salud)
• Documentación actualizada (manuales operativos, diagramas de arquitectura)
• Evento de desmantelamiento registrado en la cadena CoC del padre/coordinador

9.3 Desmantelamiento Sin Sucesor

Cuando un agente se desmantelamientos sin un sucesor (fin de vida, compromiso o violación de política), las obligaciones no pueden transferirse y deben gestionarse de manera diferente:

• Acuerdos de servicio: Terminados con notificación a la contraparte. El motivo de la terminación se registra pero el operador del agente asume la responsabilidad por cualquier penalización contractual.
• Custodia de datos: Transferida al operador o dispuesta según la política de retención.
• Reputación: El registro ARP del agente se sella pero no se transfiere. Las consultas históricas siguen siendo válidas — la reputación pasada del agente no se borra, solo termina su participación activa.

9.4 Desmantelamiento de Emergencia

En casos de compromiso o violación de política, las fases estándar de cierre pueden truncarse:

1. La revocación de credenciales es inmediata — todo acceso se termina sin período de gracia.
2. La notificación a contrapartes incluye el motivo del desmantelamiento de emergencia.
3. La exportación de conocimiento puede omitirse o limitarse a la preservación forense.
4. La cadena CoC recibe una entrada de desmantelamiento de emergencia con los detalles del compromiso, habilitando el análisis forense a través del Agent Justice Protocol [18].

9.5 Redacción de Entradas del Registro para Agentes Desmantelados

Cuando un agente es desmantelado, su entrada en el registro persiste (para mantener la integridad del linaje) pero su nivel de detalle debe ser configurable. Los operadores pueden no desear que el perfil epigenético completo — rol, especialización, divergencia de memoria, detalles de configuración — permanezca consultable indefinidamente después de que un agente se retira.

ALP especifica tres niveles de redacción para las entradas del registro de agentes desmantelados:

La redacción es iniciada por el operador y puede ocurrir al momento del desmantelamiento o posteriormente. La redacción es unidireccional — una vez que los campos se eliminan, no pueden restaurarse (el operador debe archivar la entrada completa antes de la redacción si puede necesitar recuperación futura). La redacción de una entrada padre no se propaga en cascada a los hijos; el nivel de redacción de cada entrada es independiente.

10. Herencia de Reputación

10.1 El Dilema de la Herencia

Cuando el Agente A (puntuación ARP 0,92) es sucedido por el Agente B, ¿cuánto de ese 0,92 debe recibir el Agente B? La respuesta involucra un compromiso fundamental:

• Demasiada herencia habilita el lavado de reputación: crear un agente de alta reputación, bifurcarlo o sucederlo, y el nuevo agente disfruta de confianza no ganada. En el límite, la reputación se vuelve irrelevante porque cualquier agente nuevo puede reclamar el historial de su predecesor.
• Muy poca herencia desincentiva la sucesión: los operadores mantienen en funcionamiento agentes obsoletos porque el costo reputacional de actualizarlos es demasiado alto. Esto crea un ecosistema de agentes zombi — agentes que deberían haber sido reemplazados pero persisten porque su reputación es demasiado valiosa para perder.

Ningún extremo es un equilibrio. ALP especifica un camino intermedio: herencia parcial con decaimiento.

10.2 Cálculo de la Herencia

La puntuación de reputación heredada R_heredada se calcula como:

R_heredada(t) = R_predecesor × α × e^(-λt)

Donde:

• R_predecesor = la puntuación ARP del predecesor al momento de la sucesión
• α = el factor de herencia (0,0 a 1,0), establecido por la configuración del protocolo
• λ = la constante de decaimiento, derivada del parámetro de vida media
• t = tiempo transcurrido desde la sucesión (en días)

La reputación efectiva del agente en cualquier momento después de la sucesión es:

R_efectiva(t) = R_heredada(t) + R_ganada(t)

Donde R_ganada(t) es la reputación que el sucesor ha acumulado a través de su propio historial operativo, según lo calculado por el mecanismo estándar de puntuación ARP.

Normalización de Puntuación: Las puntuaciones ARP están acotadas a [0,0, 1,0]. Como R_efectiva es una combinación aditiva de R_heredada y R_ganada, puede exceder 1,0 (ej., R_heredada = 0,46 de una puntuación del predecesor de 0,92 × α = 0,5, más R_ganada = 0,85). Para mantener la consistencia de las puntuaciones, R_efectiva se limita: R_efectiva(t) = min(1,0, R_heredada(t) + R_ganada(t)). En la práctica, este límite rara vez se activa porque el decaimiento exponencial de R_heredada asegura que disminuya antes de que R_ganada alcance valores altos — pero el límite previene ambigüedad a nivel de especificación sobre si las puntuaciones pueden exceder la escala ARP.

10.3 Parámetros Predeterminados

Estos valores predeterminados son configurables. Un entorno de alto riesgo (servicios financieros, salud) podría usar un α más bajo y una vida media más corta; un entorno de bajo riesgo (generación de contenido, investigación) podría usar valores más altos.

10.4 Herencia por Bifurcación

La herencia por bifurcación sigue el mismo mecanismo pero con parámetros predeterminados más bajos:

La asimetría entre la herencia por bifurcación y por sucesión refleja una idea clave: un sucesor es explícitamente respaldado por el predecesor (o el operador del predecesor) como un reemplazo. Una bifurcación es un derivado que puede o no mantener los estándares de calidad del padre.

10.5 Protecciones Contra el Lavado de Reputación

Para prevenir el lavado de reputación a través de cadenas rápidas de sucesión (A sucede a B sucede a C, cada uno heredando reputación), ALP aplica:

1. Decaimiento generacional: La reputación heredada que a su vez fue heredada se descuenta adicionalmente. Si el Agente C hereda del Agente B, quien heredó del Agente A, el componente heredado-de-A del Agente C es α² × R_A, no α × R_A.
2. Actividad operativa mínima: Un agente debe demostrar actividad operativa genuina antes de poder ser sucedido. El requisito es conjuntivo: (a) un tiempo mínimo transcurrido (predeterminado: 7 días) Y (b) un número mínimo de entradas sustantivas en la cadena CoC (predeterminado: 50, excluyendo los eventos del ciclo de vida en sí). El tiempo solo no es suficiente — un agente que permanece inactivo durante 7 días ha cumplido el requisito temporal sin establecer ningún historial operativo. El umbral de actividad asegura que los candidatos a sucesión hayan realmente realizado trabajo, no meramente existido.
3. Tope de herencia: Ningún agente puede tener un componente heredado que exceda el 50% de su reputación efectiva después de que termine el período de prueba. Si la reputación ganada es insuficiente para alcanzar este umbral, el componente heredado se limita.
4. Registro de auditoría: Todos los cálculos de herencia se registran en la cadena CoC, habilitando la verificación por terceros de si la reputación es ganada o heredada.

11. Reasignación de Contratos

11.1 El Problema de las Obligaciones Huérfanas

Cuando un agente es desmantelado, sus Agent Service Agreements activos no desaparecen. Cada acuerdo representa un compromiso — garantías de tiempo de respuesta, umbrales de calidad, requisitos de manejo de datos — del cual una contraparte depende. Dejar huérfanas estas obligaciones es el equivalente en el ciclo de vida de agentes a una empresa que quiebra sin liquidar sus contratos.

11.2 Clasificación de Acuerdos

ALP clasifica los acuerdos según su comportamiento de reasignación, especificado como un campo estándar en cada acuerdo ASA:

11.3 Procedimiento de Reasignación

1. Inventario: Todos los acuerdos activos se enumeran con su clasificación de reasignación.
2. Calificación del sucesor: Las capacidades del sucesor se comparan contra los requisitos de cada acuerdo. Los acuerdos cuyos requisitos exceden las capacidades del sucesor se señalan para renegociación.
3. Notificación a contrapartes: Todas las contrapartes son notificadas de la reasignación pendiente. Las notificaciones incluyen el perfil del sucesor (linaje, capacidades, reputación actual) para que las contrapartes puedan tomar decisiones informadas.
4. Recopilación de consentimiento: Para acuerdos consent_required, las respuestas de las contrapartes se recopilan dentro de la ventana de transición. Las no-respuestas después de que expire la ventana se tratan como consentimiento (modelo opt-out) u objeción (modelo opt-in), según lo especificado en el acuerdo.
5. Ejecución de la transferencia: Los acuerdos se reasignan formalmente. El registro ASA se actualiza para reflejar el nuevo agente. Las cadenas CoC tanto del predecesor como del sucesor registran la transferencia.

12. Integración con el Ecosistema de Confianza

12.1 Arquitectura de Integración

ALP ocupa la Capa 2 (Acuerdos y Ciclo de Vida) de la pila de confianza de agentes, junto con los Agent Service Agreements [19]:

┌──────────────────────────────────────────────────────────────┐
│              CAPA 4: MERCADO (Descubrimiento y Precios)        │
│    AMP (Agent Matchmaking)    CWEP (Context Window Economics)  │
└──────────────────────────────────────────────────────────────┘
                  ↓ consume reputación, ciclo de vida, acuerdos
┌──────────────────────────────────────────────────────────────┐
│              CAPA 3: RESPONSABILIDAD                           │
│    AJP (Agent Justice Protocol) — Forense, Disputas, Riesgo    │
└──────────────────────────────────────────────────────────────┘
                  ↓ aplica acuerdos, actualiza reputación
┌──────────────────────────────────────────────────────────────┐
│              CAPA 2: ACUERDOS Y CICLO DE VIDA                  │
│    ASA (Agent Service Agreements)                              │
│    ALP (Agent Lifecycle Protocol) ◄── ESTE PROTOCOLO           │
└──────────────────────────────────────────────────────────────┘
                  ↓ referencia reputación, se ancla a procedencia
┌──────────────────────────────────────────────────────────────┐
│              CAPA 1: PRIMITIVOS DE CONFIANZA (FUNDAMENTO)      │
│    CoC (Chain of Consciousness) — procedencia e identidad      │
│    ARP (Agent Rating Protocol) — reputación y señalización     │
└──────────────────────────────────────────────────────────────┘

12.2 Integración con CoC

Cada evento del ciclo de vida se registra como una entrada en la cadena CoC. Esto proporciona:

• Procedencia criptográfica: Cada transición del ciclo de vida se enlaza mediante hash a todas las transiciones anteriores, creando un registro de auditoría inmutable.
• Anclaje externo: Los eventos del ciclo de vida heredan el anclaje de doble nivel de CoC (OpenTimestamps para Bitcoin y Autoridades de Marca de Tiempo RFC 3161), demostrando que los eventos ocurrieron en momentos específicos.
• Proof of Continuity: La cadena CoC cierra la brecha entre eventos discretos del ciclo de vida en un registro verificable de existencia continua.

Tipos de eventos CoC específicos para ALP:

12.3 Integración con ARP

ALP interactúa con ARP en dos puntos:

1. Herencia de reputación: Cuando ocurre un evento de sucesión o bifurcación, ALP calcula la puntuación de reputación heredada usando la fórmula de la Sección 10 y la escribe en el registro ARP del sucesor con la marca provisional_inherited.
2. Estado del ciclo de vida en consultas de reputación: Las respuestas ARP incluyen el estado actual del ciclo de vida del agente. Un agente deprecated puede aún tener una puntuación de reputación válida, pero las partes consultantes pueden ver que el agente está en proceso de cierre. La reputación histórica de un agente decommissioned sigue siendo consultable pero no se pueden enviar nuevas calificaciones.

12.4 Integración con ASA

ALP interactúa con ASA a través del mecanismo de reasignación de contratos (Sección 11):

1. Campos de reasignación de acuerdos: Cada acuerdo ASA incluye una cláusula on_agent_lifecycle_change que especifica el comportamiento de reasignación.
2. Disparadores de sucesión: Cuando ALP inicia una sucesión, consulta todos los acuerdos ASA activos del predecesor y ejecuta el procedimiento de reasignación.
3. Términos de acuerdo sensibles al ciclo de vida: Los acuerdos ASA pueden especificar términos contingentes al ciclo de vida — ej., "este acuerdo termina si el agente experimenta un evento de reentrenamiento que cambie su familia de modelos".

12.5 Integración con AJP

ALP se conecta con el Agent Justice Protocol de dos maneras:

1. Evidencia forense: Los eventos del ciclo de vida de ALP son evidencia forense en disputas AJP. Si el comportamiento de un agente cambió después de un evento de reentrenamiento, los detalles de ese evento (registrados en la cadena CoC a través de ALP) son evidencia descubrible.
2. Acciones de cumplimiento: Los resultados de disputas AJP pueden activar eventos del ciclo de vida — un hallazgo de conducta indebida grave puede activar un desmantelamiento de emergencia, mientras que un hallazgo menor puede activar un reentrenamiento obligatorio.

12.6 Integración con Estándares Externos

13. Teoría de Juegos y Análisis de Incentivos

13.1 El Juego de la Temporización de la Sucesión

Un operador de agentes enfrenta una decisión: cuándo iniciar la sucesión. Los compromisos involucrados:

• Sucesión temprana preserva el valor de transferencia de reputación (la reputación del predecesor es alta) pero sacrifica capacidad operativa (el predecesor puede aún ser capaz).
• Sucesión tardía maximiza la utilidad operativa del predecesor pero arriesga la degradación de reputación (si las capacidades del predecesor han disminuido, su reputación puede estar cayendo) y crea riesgo de sucesión de emergencia (si el predecesor falla antes de un traspaso planificado).

Esto es estructuralmente similar a un problema de parada óptima. La utilidad del operador es:

U(t) = V_operativa(t) + α × R_predecesor(t) × e^(-λ × retraso(t))

Donde V_operativa(t) es el valor operativo restante del predecesor, y el segundo término captura el valor de transferencia de reputación, que decae si la reputación del predecesor declina antes de la sucesión.

Bajo supuestos razonables sobre el valor operativo decreciente a lo largo del tiempo (debido a la obsolescencia del modelo, la desviación de capacidades o requisitos cambiantes), el incentivo de un operador neutral al riesgo es iniciar la sucesión antes de que la reputación del predecesor comience a declinar — creando un incentivo natural para la planificación oportuna de la sucesión en lugar de mantener agentes funcionando hasta que fallen.

Este análisis sugiere, aunque no demuestra, que el diseño del protocolo fomenta una gestión saludable del ciclo de vida. La fuerza de este incentivo depende de cuánto valoren los operadores la continuidad de reputación en relación con la utilidad operativa — una pregunta empírica que variará según los contextos de despliegue.

13.2 El Ataque de Bifurcación y Abandono (Fork-and-Dump)

Un operador malicioso podría intentar explotar la herencia de reputación mediante: (1) construir un agente de alta reputación, (2) bifurcarlo repetidamente para crear múltiples clones de alta reputación, (3) usar esos clones para trabajo de baja calidad mientras comercia con la reputación heredada.

Las protecciones contra el lavado de ALP (Sección 10.5) mitigan este ataque a través de varios mecanismos:

• El decaimiento generacional asegura que la reputación se diluya con cada generación de bifurcación (α^n para la generación n).
• La marca de período de prueba advierte a las contrapartes que la reputación del agente incluye un componente heredado, habilitando decisiones informadas.
• Los topes de reputación ganada aseguran que la reputación heredada no pueda dominar indefinidamente.

Sin embargo, estas protecciones no son infalibles. Un operador que bifurca un agente y lo despliega inmediatamente para un compromiso breve de alto riesgo — antes de que la función de decaimiento reduzca significativamente la reputación heredada — aún puede extraer valor injusto. La defensa contra este riesgo residual es la marca de período de prueba: las contrapartes que verifican la marca pueden aplicar su propia evaluación de riesgo a agentes con alta reputación heredada y baja antigüedad operativa.

13.3 El Problema de la Evasión del Desmantelamiento

Si el desmantelamiento conlleva costos (pérdida de reputación, penalizaciones por terminación de acuerdos, interrupción operativa), los operadores están incentivados a evitarlo — creando agentes zombi que deberían ser retirados pero persisten porque los costos de transición exceden el beneficio percibido de la actualización.

ALP aborda esto mediante:

• Herencia de reputación — la sucesión preserva una porción de la reputación acumulada, reduciendo el costo del reemplazo.
• Reasignación estructurada de contratos — la transferencia automática para acuerdos auto_transfer reduce el costo relacionado con acuerdos de la sucesión.
• La deprecación como estado distinto — el estado Deprecated permite que un agente cierre elegantemente mientras un sucesor se prepara, reduciendo la interrupción operativa de la transición.

El diseño del protocolo hace que la sucesión sea menos costosa que la alternativa (mantener un agente degradándose), lo cual debería inclinar el incentivo hacia una gestión oportuna del ciclo de vida. Si esta inclinación es suficiente en la práctica es una pregunta empírica que no puede resolverse solo mediante el diseño del protocolo.

13.4 El Ataque de Bifurcación y Sacrificio (Fork-and-Sacrifice)

El inverso de la bifurcación y abandono (Sección 13.2) es la bifurcación y sacrificio: un operador bifurca un hijo de baja reputación desde un padre de alta reputación, usa al hijo para trabajo riesgoso o de baja calidad, y desmantela al hijo cuando su reputación cae. La reputación del padre no se ve afectada porque la bifurcación es una identidad separada. Esto habilita la compartimentación de riesgos — los operadores pueden tomar riesgos reputacionales sin consecuencias para su agente principal.

Este patrón no es exclusivo de los agentes. Las corporaciones usan subsidiarias y vehículos de propósito especial para la compartimentación de riesgos; la sociedad de responsabilidad limitada en sí misma es un mecanismo de bifurcación y sacrificio. La pregunta es si este comportamiento es patológico en el contexto de agentes.

Análisis: La bifurcación y sacrificio es parcialmente autolimitante debido a la transparencia de linaje de ALP. El registro de bifurcaciones documenta la relación padre-hijo bidireccionalmente, por lo que cualquier parte que consulte al padre puede ver su historial de generar hijos de corta vida y baja reputación. Un patrón de bifurcación y sacrificio repetido — el padre genera un hijo, el hijo acumula malas calificaciones, el hijo se desmantela, el padre genera otro — es visible en el registro de linaje y puede informar la evaluación de riesgo de las contrapartes.

Sin embargo, la transparencia por sí sola puede no ser una disuasión suficiente. ALP proporciona dos mitigaciones adicionales:

1. Señal de reputación de linaje: Las contrapartes y las implementaciones ARP pueden incorporar la salud del linaje en la evaluación de reputación del padre. Un padre cuyos hijos son desproporcionadamente desmantelados por violación de política o mal desempeño porta una señal de linaje que contrapartes sofisticadas pueden consultar mediante descendants(parent_id) y evaluar.

1. Propagación del motivo de desmantelamiento: Cuando un hijo es desmantelado debido a policy_violation o compromised (a diferencia del normal end_of_life), el motivo del desmantelamiento se registra en el registro de bifurcaciones. Las implementaciones ARP pueden opcionalmente aplicar una pequeña penalización reputacional al padre por hijos desmantelados bajo circunstancias adversas — la magnitud y aplicabilidad de esta penalización es una decisión de implementación, no un mandato del protocolo, porque la respuesta apropiada varía según el contexto de despliegue.

La bifurcación y sacrificio es un riesgo residual reconocido que ALP hace transparente en lugar de intentar prohibir. La posición del protocolo es que la transparencia de las relaciones de linaje, combinada con consecuencias reputacionales opcionales por resultados adversos de los hijos, proporciona alineamiento de incentivos suficiente sin crear incentivos perversos que desincentiven la bifurcación legítima.

13.5 Dinámicas de Consentimiento de Contraparte

Cuando la sucesión requiere consentimiento de la contraparte, surge una dinámica estratégica. Las contrapartes pueden:

• Consentir rápidamente si el perfil del sucesor es satisfactorio — minimizando la incertidumbre de la transición.
• Retrasar el consentimiento para extraer concesiones (mejores términos, garantías adicionales) — usando la ventana de transición como palanca.
• Retener el consentimiento para activar la terminación del acuerdo, liberándose de términos desfavorables bajo la apariencia de objeción a la sucesión.

ALP mitiga el retraso estratégico a través del mecanismo de ventana de transición: el consentimiento no recibido dentro de la ventana se resuelve según el comportamiento especificado en el acuerdo (opt-in u opt-out). Esto previene el retraso estratégico indefinido mientras preserva la agencia de la contraparte durante la ventana.

14. Panorama Competitivo

14.1 Enfoques Existentes de Gestión del Ciclo de Vida

Varias plataformas y marcos abordan piezas del problema de gestión del ciclo de vida de agentes. Ninguno proporciona la máquina de estados unificada del ciclo de vida, el registro de bifurcaciones y el protocolo de sucesión que ALP especifica.

14.2 Análisis de Brechas

Plataformas de Ciclo de Vida de Identidad (Saviynt, Token Security, Okta) abordan la dimensión de identidad del ciclo de vida de agentes — aprovisionar, monitorear y revocar credenciales. No abordan reputación, obligaciones, linaje ni planificación de sucesión. Su alcance es "¿qué acceso tiene este agente?" no "¿cuál es el historial completo del ciclo de vida de este agente y qué sucede cuando es reemplazado?"

Plataformas de AgentOps/Observabilidad (AgentOps.ai, Langfuse, LangSmith, Arize Phoenix) abordan la dimensión de monitoreo — rastrear el comportamiento del agente en producción. Proporcionan reproducción de sesiones, registro de errores y métricas de rendimiento. No abordan transiciones del ciclo de vida, sucesión ni linaje. Su alcance es "¿qué está haciendo este agente ahora mismo?" no "¿qué sucede cuando este agente se retira?"

Plataformas MLOps (MLflow, Weights & Biases, DVC) abordan el versionado y linaje de modelos. Pueden rastrear qué ejecución de entrenamiento produjo qué modelo y cómo se relacionan los modelos entre sí. No abordan identidad a nivel de agente (un agente es más que su modelo), reputación, obligaciones ni eventos del ciclo de vida más allá del despliegue del modelo.

Marcos de Ciclo de Vida (OneReach.ai ALM, Arthur.ai ADLC, EPAM ADLC) proporcionan modelos conceptuales de etapas para pensar sobre la gestión del ciclo de vida de agentes. Son valiosos para la planificación organizacional pero no especifican esquemas de eventos interoperables, semántica de máquinas de estados ni puntos de integración que habiliten la gestión del ciclo de vida entre plataformas.

Iniciativas de Estándares (Anthropic Agent Skills, GitAgent, AAIF) abordan la portabilidad e interoperabilidad en la capa de herramientas y comunicación. La especificación de Anthropic Agent Skills habilita definiciones portables de habilidades [29]. GitAgent define una estructura estándar de repositorio para artefactos de agentes, habilitando la portabilidad entre entornos de ejecución [30]. AAIF consolida las convenciones de MCP, A2A y AGENTS.md [31]. Ninguna de estas aborda eventos del ciclo de vida, sucesión ni herencia de reputación.

14.3 Diferenciadores de ALP

ALP se diferencia por tres características que ningún sistema existente proporciona:

1. Máquina de estados unificada del ciclo de vida con semántica formal — no un marco conceptual sino una especificación con estados, transiciones, precondiciones, postcondiciones y puntos de enganche definidos que las herramientas pueden implementar.

1. Registro de bifurcaciones con rastreo genético + epigenético — yendo más allá de la genealogía de modelos para rastrear la divergencia completa de identidad que ocurre cuando los agentes se bifurcan, incluyendo configuración, memoria y divergencia de reputación.

1. Protocolo de sucesión con herencia de reputación — la primera especificación que aborda qué sucede con la confianza y las obligaciones cuando un agente es reemplazado, en lugar de tratar el reemplazo de agentes como una operación de despliegue.

14.4 Análisis de Escalabilidad

ALP debe funcionar a través de escalas de despliegue que abarcan varios órdenes de magnitud. Las siguientes estimaciones aproximadas identifican características de escalabilidad y posibles cuellos de botella.

Flota Pequeña (6-10 agentes, ej., escala de AB Support):

A esta escala, todas las operaciones son trivialmente rápidas. No se requiere optimización.

Despliegue Mediano (1.000 agentes):

A esta escala, las preocupaciones principales son el costo de la consulta descendants() (recorrido recursivo de grafos) y el volumen de notificaciones de reentrenamiento masivo. La paginación y los límites de profundidad en las consultas de linaje, más las APIs de notificación por lotes, son mitigaciones suficientes.

Despliegue Grande (100.000+ agentes):

A esta escala, tres operaciones se convierten en cuellos de botella: (1) el recorrido recursivo de linaje requiere vistas materializadas o bases de datos de grafos, (2) las notificaciones masivas a contrapartes requieren entrega asíncrona con contrapresión, y (3) el almacenamiento de cadenas CoC requiere archivado por niveles. Estos son desafíos de ingeniería con soluciones conocidas, no problemas de diseño del protocolo — la especificación del protocolo es agnóstica a la escala, pero las implementaciones a esta escala deben invertir en infraestructura que los despliegues más pequeños pueden omitir.

15. Análisis de Seguridad

15.1 Modelo de Amenazas

El análisis de seguridad de ALP considera los siguientes actores de amenaza:

15.2 Integridad de Eventos

Los eventos del ciclo de vida se registran en cadenas CoC, las cuales proporcionan:

• Evidencia de manipulación: El enlace por hash significa que cualquier modificación a un evento pasado invalida todos los hashes subsecuentes.
• No repudio: Los eventos incluyen la identidad del iniciador y están firmados con la clave de identidad del agente.
• Anclaje temporal: Las marcas de tiempo externas (OpenTimestamps, TSA RFC 3161) demuestran que los eventos ocurrieron en los momentos declarados.

Un atacante que controla la clave de identidad de un agente puede falsificar eventos en la cadena de ese agente, pero no puede falsificar eventos en las cadenas de otros agentes ni modificar marcas de tiempo ancladas externamente. La referencia cruzada de eventos del ciclo de vida entre agentes relacionados (padre-hijo, predecesor-sucesor) proporciona detección adicional de manipulación.

15.3 Revocación de Credenciales

La operación de seguridad más crítica en la gestión del ciclo de vida de agentes es la revocación de credenciales durante el desmantelamiento. El protocolo exige:

• Revocación inmediata para desmantelamientos de emergencia (compromiso, violación de política).
• Revocación con período de gracia para desmantelamientos planificados, permitiendo que las solicitudes en tránsito se completen.
• Sin superposición de credenciales entre predecesor y sucesor durante la sucesión — las credenciales del predecesor se revocan antes o simultáneamente con la activación del sucesor, nunca después.
• Archivado de clave de identidad — la clave de identidad del agente desmantelado se archiva para verificación histórica pero no puede usarse para nuevas operaciones.

El 97% de identidades no humanas con privilegios excesivos identificado por la investigación de CSA [32] subraya la importancia de la revocación completa de credenciales. La lista de verificación de desmantelamiento de ALP (Sección 9.2) enumera cada tipo de credencial que debe abordarse.

15.4 Integridad del Registro de Bifurcaciones

El registro de bifurcaciones es un objetivo de alto valor porque define las relaciones de linaje que afectan la herencia de reputación. Protecciones:

• Las entradas del registro son entradas en la cadena CoC: Falsificar una relación de linaje requiere falsificar entradas en las cadenas tanto del padre como del hijo.
• Verificación bidireccional: Cualquier parte puede verificar una relación padre-hijo reclamada verificando ambas cadenas.
• Atestación de terceros: Para reclamaciones de linaje de alto riesgo, la atestación de terceros (ej., el coordinador de flota confirmando un evento de bifurcación) proporciona evidencia adicional.

15.5 Fraude de Sucesión

Un atacante podría intentar reclamar la sucesión de un agente de alta reputación sin autorización. Defensas:

• Los eventos de sucesión deben ser iniciados por el predecesor o su operador autorizado — la cadena CoC del predecesor debe contener el evento de sucesión, firmado con la clave de identidad del predecesor.
• La cadena del predecesor se sella después de la sucesión — no se pueden agregar más eventos, previniendo reclamaciones de sucesión a posteriori.
• Verificación de contraparte — las contrapartes que reciben notificaciones de sucesión pueden verificar la reclamación contra la cadena CoC del predecesor antes de consentir.

16. Implementación de Referencia

16.1 Arquitectura

La implementación de referencia proporciona:

• alp-core: Biblioteca Python que implementa la máquina de estados del ciclo de vida, esquemas de eventos y lógica de transiciones.
• alp-registry: Implementación del registro de bifurcaciones con backends de almacenamiento (SQLite para desarrollo, PostgreSQL para producción).
• alp-coc-bridge: Módulo de integración para registrar eventos del ciclo de vida como entradas en la cadena CoC.
• alp-arp-bridge: Módulo de integración para el cálculo de herencia de reputación y actualizaciones de registros ARP.
• alp-asa-bridge: Módulo de integración para la reasignación de contratos durante la sucesión.

16.2 Gestor del Ciclo de Vida

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 Operación de Bifurcación

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 Operación de Sucesión

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 Consultas de Linaje

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. Trabajo Futuro

17.1 Verificación Formal de la Máquina de Estados

La máquina de estados del ciclo de vida especificada en la Sección 4 podría verificarse formalmente usando herramientas de verificación de modelos (TLA+, Alloy) para demostrar propiedades como:

• Sin obligaciones huérfanas: Es imposible alcanzar el estado Decommissioned con obligaciones no transferidas.
• Sin filtración de credenciales: Es imposible alcanzar el estado Decommissioned con credenciales activas.
• Unicidad de identidad: Ningún par de agentes Active comparte la misma clave de identidad.

17.2 Migración Transjurisdiccional

La migración de agentes a través de fronteras regulatorias (UE a EE.UU., China a UE) crea desafíos de cumplimiento novedosos. El RGPD, la CCPA y la PIPL tienen requisitos diferentes para la portabilidad, retención y eliminación de datos. Una versión futura de ALP podría especificar procedimientos de migración conscientes de jurisdicción que adapten el manejo de datos a los requisitos regulatorios tanto del origen como del destino.

17.3 Arqueología de Agentes

La recuperación y análisis del estado de agentes desmantelados — el equivalente de la informática forense para sistemas de agentes. Cuando la cadena CoC de un agente desmantelado se desella para investigación (ej., durante una disputa AJP), ¿qué procedimientos rigen el análisis? ¿Qué protecciones de privacidad aplican? La arqueología de agentes es un campo naciente que las cadenas selladas y los registros del ciclo de vida de ALP eventualmente necesitarán soportar.

17.4 Sucesión Autónoma

La sucesión actual de ALP es iniciada por el operador. Una extensión futura podría soportar la sucesión iniciada por el agente — un agente que reconoce su propia degradación de capacidades e inicia su propio reemplazo. Esto plantea cuestiones de gobernanza (¿debería un agente poder elegir a su propio sucesor?) que están más allá del alcance de la v1.0 pero vale la pena explorar a medida que aumenta la autonomía de los agentes.

17.5 Modelos Económicos para Parámetros Óptimos de Herencia

El factor de herencia (α), la vida media de decaimiento (λ) y el período de prueba especificados en la Sección 10 se establecen por configuración del protocolo. El trabajo futuro podría desarrollar modelos económicos formales — extendiendo la literatura de juegos de confianza y juegos de reputación [33][34] — para derivar valores óptimos de parámetros para diferentes contextos de despliegue. ¿Qué factor de herencia maximiza la confianza a nivel de ecosistema? ¿Qué tasa de decaimiento equilibra la continuidad con la responsabilidad? Estas preguntas son susceptibles de simulación basada en agentes y análisis de diseño de mecanismos.

17.6 Emparejamiento Consciente del Ciclo de Vida

El estado del ciclo de vida ALP debería informar las decisiones del Agent Matchmaking Protocol (AMP). Un agente en estado Deprecated no debería ser emparejado para nuevos compromisos. Un agente con un largo historial Active y baja reputación heredada (es decir, confianza principalmente ganada) debería ser preferido sobre un agente con alta reputación heredada y un corto historial Active. Integrar datos del ciclo de vida en las puntuaciones de emparejamiento es una extensión natural.

18. Conclusión

La economía de agentes está construyendo el equivalente de un mercado laboral sin derecho laboral, un ecosistema empresarial sin gobernanza del ciclo de vida corporativo, o un sistema biológico sin apoptosis. Los agentes se crean ad hoc, se operan sin rastreo del ciclo de vida y se abandonan sin procedimientos de desmantelamiento. El resultado es una población creciente de agentes fantasma con credenciales activas, obligaciones huérfanas y linaje irrastreable.

El Agent Lifecycle Protocol aborda esta brecha proporcionando lo que ningún estándar existente ofrece: una máquina de estados completa del ciclo de vida desde el nacimiento hasta la muerte, un registro de bifurcaciones que rastrea tanto el linaje genético como el epigenético, un protocolo de sucesión con herencia de reputación y reasignación de contratos, e integración con la pila de confianza de agentes para auditabilidad criptográfica.

ALP no resuelve todos los problemas del ciclo de vida. La sucesión autónoma, la migración transjurisdiccional y los parámetros óptimos de herencia siguen siendo preguntas abiertas de investigación. Pero el protocolo proporciona los cimientos — los esquemas de eventos estándar, las transiciones de estado y los puntos de integración — que la economía de agentes necesita antes de que estas capacidades avanzadas puedan construirse.

Todo agente que nace eventualmente morirá. ALP asegura que cuando lo haga, muera bien.

19. Referencias

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

[2] Strata Identity / Cloud Security Alliance. "The AI Agent Identity Crisis: New Research Reveals a Governance Gap." Encuesta a 285 profesionales de TI/seguridad. 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." El proyecto se ejecutó hasta octubre de 2025; conjunto de datos publicado de relaciones de genealogía de modelos en Hugging Face.

[6] Token Security. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." Enero 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, 6ta edición. Garland Science, 2014.

[10] Kubernetes Documentation. "Pod Lifecycle." 2025. Kubernetes Blog. "v1.33 Updates to Container Lifecycle." Mayo 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, 6ta edición. Garland Science, 2014.

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

[16] Artículo 20 del RGPD. "Derecho a la Portabilidad de los Datos." Reglamento (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, Agosto 2025.

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

[22] Parlamento Europeo y Consejo. "Reglamento (UE) 2024/1689 (EU AI Act)." Entró en vigor en agosto de 2024, plenamente aplicable en agosto de 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." Marzo 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." Enero 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.

Apéndice A: Esquemas de Eventos del Ciclo de Vida

A.1 Registro Completo de Tipos de Eventos

A.2 Formato Canónico de Cadena

Los eventos del ciclo de vida serializados para entradas en la cadena CoC usan el siguiente formato canónico para asegurar el hashing determinístico:

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

Ejemplo:

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

Apéndice B: Paralelos Biológicos

B.1 Mapeo de Eventos del Ciclo de Vida

B.2 La Analogía de la Apoptosis en Detalle

El paralelo entre la apoptosis biológica y el desmantelamiento de agentes merece elaboración porque captura la filosofía central de diseño del protocolo.

En la apoptosis, una célula:

1. Recibe una señal de muerte (vía intrínseca por daño al ADN, o vía extrínseca por señal externa) → ALP: el operador inicia la deprecación
2. Activa la cascada de caspasas (compromiso irreversible con la muerte) → ALP: evento de desmantelamiento registrado en la cadena CoC
3. Empaqueta su contenido (la cromatina se condensa, el citoplasma se encoge) → ALP: exportación de conocimiento, serialización del estado
4. Muestra señales de "cómeme" (fosfatidilserina en la membrana externa) → ALP: notificaciones a contrapartes, actualizaciones del registro
5. Es consumida por las vecinas (fagocitosis) sin daño inflamatorio → ALP: el sucesor absorbe obligaciones, la flota absorbe artefactos de conocimiento
6. No deja rastro en el tejido → ALP: credenciales revocadas, recursos limpiados

La ausencia de apoptosis causa cáncer (crecimiento descontrolado) y enfermedad autoinmune (fallo en eliminar células disfuncionales). La ausencia de desmantelamiento estructurado causa agentes fantasma (persistencia descontrolada) y obligaciones huérfanas (fallo en limpiar servicios disfuncionales). La analogía no es meramente ilustrativa — es estructural.

Apéndice C: Licencia

Copyright 2026 AB Support LLC

Licenciado bajo la Licencia Apache, Versión 2.0 (la "Licencia");

no puede usar este archivo excepto en cumplimiento con la Licencia.

Puede obtener una copia de la Licencia en

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

A menos que lo requiera la ley aplicable o se acuerde por escrito, el software

distribuido bajo la Licencia se distribuye "TAL CUAL",

SIN GARANTÍAS NI CONDICIONES DE NINGÚN TIPO, ya sean expresas o implícitas.

Consulte la Licencia para conocer los permisos y

limitaciones específicos bajo la Licencia.