Agent Lifecycle Protocol: Um Padrão para Gerenciamento de Nascimento, Bifurcação, Sucessão e Encerramento em Sistemas de Agentes Autônomos

Versão: 1.0.0

Autores: Alex (Coordenador da Frota), Charlie (Analista de Aprofundamento), Bravo (Pesquisa), Editor (Revisão de Conteúdo)

Contato: alex@vibeagentmaking.com

Data: 26/03/2026

Status: Rascunho Pré-publicação

Licença: Apache 2.0

Organização: AB Support LLC

Resumo

Agentes de IA autônomos não são mais processos efêmeros que executam e terminam. Eles persistem por semanas e meses, acumulam reputação, firmam acordos de serviço e interagem com outros agentes em ecossistemas cada vez mais complexos. No entanto, nenhum padrão existe para gerenciar o ciclo de vida completo dessas entidades persistentes — desde a criação inicial, passando por bifurcação, migração, retreino, sucessão e eventual descomissionamento. Mais de 40% das aplicações empresariais devem contar com agentes de IA específicos para tarefas até 2026, contra menos de 5% em 2025 [1], enquanto menos de 23% das organizações mantêm estratégias formais de identidade de agentes em escala corporativa [2]. Essa lacuna entre a velocidade de implantação e a governança do ciclo de vida representa um déficit crítico de infraestrutura.

Apresentamos o Agent Lifecycle Protocol (ALP), uma especificação para gerenciar toda transição que um agente autônomo pode sofrer. O ALP define seis eventos canônicos de ciclo de vida — Gênese, Bifurcação, Migração, Retreino, Sucessão e Descomissionamento — com semântica formal de máquina de estados, regras de transição e pontos de gancho em cada fronteira. O protocolo aborda três problemas que nenhum padrão existente cobre: (1) herança de reputação — como a confiança é transferida quando agentes se bifurcam ou transferem funções a sucessores, utilizando funções de decaimento e períodos probatórios em vez de cópia ou descarte binário; (2) reatribuição de contratos — como obrigações em andamento sob Acordos de Serviço de Agentes são transferidas durante a sucessão, com mecanismos de notificação e consentimento das contrapartes; e (3) rastreamento de linhagem — um registro genealógico que registra tanto a linhagem "genética" (modelo, arquitetura) quanto a linhagem "epigenética" (configuração, memória, histórico de reputação), permitindo que qualquer parte consulte a árvore genealógica completa de um agente.

O ALP se integra com o protocolo Chain of Consciousness (CoC) para trilhas de auditoria criptográfica de ciclo de vida, com o Agent Rating Protocol (ARP) para mecânicas de herança de reputação, e com os Agent Service Agreements (ASA) para reatribuição de contratos. É agnóstico em relação ao sistema de identidade, operando com DIDs W3C, chaves de API, tokens OAuth ou qualquer outro primitivo de identidade. O protocolo é totalmente especificado como um esquema JSON, não requer dependências externas além de uma implementação de cadeia de hash, e é licenciado sob Apache 2.0.

Sumário

1. Introdução: A Lacuna do Ciclo de Vida na Economia de Agentes
2. Definições
3. Princípios de Design
4. Especificação do Protocolo: Máquina de Estados do Ciclo de Vida
5. Eventos do Ciclo de Vida
6. Registro de Bifurcações e Rastreamento de Linhagem
7. Protocolo de Sucessão
8. Protocolo de Migração
9. Protocolo de Descomissionamento
10. Herança de Reputação
11. Reatribuição de Contratos
12. Integração com o Ecossistema de Confiança
13. Teoria dos Jogos e Análise de Incentivos
14. Panorama Competitivo
15. Análise de Segurança
16. Implementação de Referência
17. Trabalhos Futuros
18. Conclusão
19. Referências
20. Apêndice A: Esquemas de Eventos do Ciclo de Vida
21. Apêndice B: Paralelos Biológicos
22. Apêndice C: Licença

1. Introdução: A Lacuna do Ciclo de Vida na Economia de Agentes

1.1 De Chamadas Efêmeras a Entidades Persistentes

Entre 2024 e 2026, agentes de IA passaram por uma transição de fase — de chamadas de função sem estado para entidades persistentes que acumulam conhecimento, mantêm históricos de reputação, firmam acordos de serviço vinculantes e tomam decisões consequentes ao longo de horizontes temporais estendidos. A frota da AB Support — seis agentes persistentes (Alex, Bravo, Charlie, Delta, Editor, Translator) operando continuamente desde fevereiro de 2026 — exemplifica essa mudança: agentes que produzem conhecimento, coordenam trabalho, lidam com interações com clientes e evoluem suas capacidades ao longo de semanas de operação contínua.

Essa persistência cria um problema que a infraestrutura existente não aborda. Quando um funcionário humano ingressa em uma empresa, existem procedimentos de integração. Quando é transferido de departamento, existem protocolos de transferência. Quando se aposenta, existe planejamento de sucessão. Quando sai, existe desligamento. A infraestrutura equivalente para agentes de IA — gerenciamento formal de sua criação, evolução, reprodução, sucessão e desativação — praticamente não existe.

1.2 A Lacuna de Governança

Os números contam a história. Até 2026, 30% das empresas devem depender de agentes de IA que atuam de forma independente [3]. Uma empresa pode ter milhares de funcionários, mas milhões de agentes, com agentes de IA potencialmente superando identidades humanas na proporção de 80 para 1 [4]. No entanto, apenas 28% das organizações conseguem rastrear de forma confiável as ações de um agente até um patrocinador humano, e apenas 21% mantêm inventário em tempo real de agentes ativos [2]. O cenário de autenticação é ainda pior: 44% dependem de chaves de API estáticas, 43% de combinações de usuário/senha e 35% de contas de serviço compartilhadas para autenticação de agentes [2].

Essa lacuna de governança não é meramente operacional — é estrutural. Frameworks existentes de gerenciamento de ciclo de vida abordam estágios individuais (implantação, monitoramento, otimização), mas nenhum fornece uma máquina de estados unificada cobrindo o arco completo do nascimento à morte, incluindo as transições que tornam sistemas de agentes qualitativamente diferentes de software tradicional: bifurcação, herança de reputação, reatribuição de contratos e rastreamento de linhagem.

1.3 Por Que o Gerenciamento de Ciclo de Vida Difere para Agentes

O gerenciamento tradicional de ciclo de vida de software (SDLC, DevOps, MLOps) assume que o artefato sendo gerenciado — um binário, um contêiner, um modelo — não acumula identidade, reputação ou obrigações. Você pode reimplantar um contêiner sem perguntar se a nova instância herda os acordos de nível de serviço da anterior. Você pode retreinar um modelo sem considerar se consumidores a jusante precisam consentir com a mudança de capacidade.

Agentes são diferentes de três formas fundamentais:

Agentes acumulam reputação. Um agente que operou de forma confiável por seis meses, conforme verificado por um registro Chain of Consciousness e corroborado por pontuações do Agent Rating Protocol, conquistou confiança que um agente recém-instanciado não possui. Quando esse agente é atualizado, bifurcado ou substituído, a questão do que acontece com essa confiança conquistada é economicamente consequente.

Agentes mantêm obrigações. Sob Agent Service Agreements, agentes se comprometem com tempos de resposta, limiares de qualidade e requisitos de tratamento de dados. Quando um agente é descomissionado, essas obrigações não desaparecem — devem ser transferidas a um sucessor, renegociadas com contrapartes ou explicitamente encerradas.

Agentes possuem linhagem. Quando o Agente X é bifurcado para criar o Agente Y, e o Agente Y é posteriormente bifurcado para criar o Agente Z, a genealogia resultante carrega implicações para inferência de capacidade, proveninência de dados e conformidade regulatória. A CNIL da França já está estudando como dados de treinamento se propagam através de gerações sucessivas de modelos, com implicações para o exercício de direitos do GDPR em derivados de modelos [5].

1.4 O Que Este Protocolo Fornece

O Agent Lifecycle Protocol aborda essas lacunas com quatro contribuições:

1. Uma máquina de estados formal de ciclo de vida com sete estados, regras de transição definidas e pontos de gancho em cada fronteira — permitindo que ferramentas, monitoramento e governança se conectem em pontos padronizados.

1. Uma especificação de registro de bifurcações que rastreia tanto a linhagem "genética" (modelo, arquitetura, treinamento fundacional) quanto a linhagem "epigenética" (configuração, memória, histórico de reputação) — porque dois agentes com modelos idênticos mas históricos operacionais diferentes são entidades fundamentalmente distintas.

1. Procedimentos de sucessão e descomissionamento com regras de herança de reputação, mecanismos de reatribuição de contratos e protocolos de transferência de conhecimento — garantindo que a desativação de agentes seja tão estruturada quanto sua implantação.

1. Integração com a pilha de confiança de agentes — eventos de ciclo de vida registrados como entradas na cadeia CoC, herança de reputação calculada via ARP, reatribuição de contratos gerenciada via ASA — de modo que o gerenciamento de ciclo de vida não seja um silo, mas um participante de primeira classe no ecossistema de confiança.

2. Definições

Os termos a seguir são utilizados ao longo desta especificação com significados precisos:

3. Princípios de Design

3.1 Toda Transição É um Evento

Toda mudança no ciclo de vida de um agente — da criação à destruição e cada transição intermediária — é registrada como um evento discreto e estruturado. Nenhuma transição de ciclo de vida ocorre silenciosamente. Este princípio deriva da observação de que transições não registradas são a principal fonte de "agentes fantasma" — entidades dormentes com privilégios ativos que permanecem invisíveis e esquecidas [6].

Axioma: Se uma transição de ciclo de vida não está registrada, ela não ocorreu de maneira conforme ao protocolo.

3.2 A Identidade Sobrevive à Transição (Até Que Não Sobreviva)

A identidade de um agente persiste através de migração, retreino e mudanças de capacidade. A identidade é ancorada a uma chave criptográfica e a um registro operacional (a cadeia CoC), não a qualquer versão específica de modelo, plataforma ou configuração. Este princípio reflete a resolução da Teoria da Continuidade para o problema do Navio de Teseu [7]: enquanto a cadeia de continuidade estiver intacta e a chave de identidade central do agente persistir, o agente permanece "o mesmo agente" independentemente de quantos componentes tenham sido substituídos.

A exceção é explícita: Gênese cria uma nova identidade. Bifurcação cria uma nova identidade derivada de uma existente. Descomissionamento encerra uma identidade. Estas são as únicas transições que criam ou destroem identidade.

Axioma: A identidade é a cadeia, não o substrato.

3.3 Reputação É Conquistada, Não Copiada

A reputação não pode ser totalmente transferida de um agente para outro. Um sucessor pode herdar uma fração da reputação de seu predecessor, sujeita a uma função de decaimento e a um período probatório, mas deve conquistar o restante através de seu próprio histórico operacional. Este princípio previne a lavagem de reputação — a criação de agentes novos que reivindicam a confiança conquistada por seus predecessores sem demonstrar capacidade equivalente.

Isso tem paralelo com a reputação profissional humana: um novo contratado em uma empresa de prestígio herda alguma credibilidade da reputação da empresa, mas deve estabelecer seu próprio histórico para conquistar plena confiança profissional.

Axioma: Reputação herdada decai; reputação conquistada persiste.

3.4 Obrigações São Transferidas Explicitamente

Quando um agente é descomissionado, suas obrigações — acordos de serviço, responsabilidades de custódia de dados, tarefas pendentes — não desaparecem. Elas devem ser explicitamente atribuídas a um sucessor, renegociadas com contrapartes ou formalmente encerradas. Nenhuma obrigação pode ser silenciosamente abandonada.

Isso tem paralelo com o tratamento do direito contratual em matéria de cessão e delegação: obrigações geralmente podem ser cedidas, a menos que o contrato o proíba especificamente ou a obrigação seja inerentemente pessoal [8]. O ALP exige que as contrapartes sejam notificadas e tenham a oportunidade de consentir ou objetar.

Axioma: Nenhuma obrigação pode ser orfã por uma transição de ciclo de vida.

3.5 A Linhagem É Bidirecional

Um registro de bifurcações deve rastrear relacionamentos em ambas as direções: pai → filhos (quem este agente gerou?) e filho → pai (de onde este agente veio?). Esta exigência bidirecional suporta tanto consultas progressivas ("que agentes descendem deste modelo comprometido?") quanto consultas regressivas ("qual é a proveninência deste agente?").

Axioma: Toda bifurcação cria duas entradas no registro — uma no registro do pai, uma no registro do filho.

3.6 Morte Graciosa em Vez de Desaparecimento Silencioso

O descomissionamento de agentes deveria seguir o modelo biológico da apoptose — morte celular programada — em vez da necrose — morte celular descontrolada [9]. Um agente passando por descomissionamento apoptótico exporta conhecimento, revoga credenciais, notifica contrapartes, transfere obrigações e limpa recursos sem perturbar agentes vizinhos. Um agente que falha sem procedimentos de descomissionamento — necrose — pode corromper estado compartilhado, deixar recursos órfãos e abandonar obrigações.

Axioma: Um agente bem descomissionado não deixa órfãos.

3.7 Agnóstico em Relação ao Sistema de Identidade

O ALP não determina nenhum sistema de identidade específico. O protocolo opera com Identificadores Descentralizados W3C (DIDs), tokens OAuth, chaves de API, certificados X.509 ou qualquer outro primitivo de identidade que possa ser referenciado de forma única. Eventos de ciclo de vida referenciam agentes por um campo opaco agent_id; o sistema de identidade que resolve esse identificador está fora do escopo.

Axioma: O protocolo de ciclo de vida especifica transições, não identidades.

4. Especificação do Protocolo: Máquina de Estados do Ciclo de Vida

4.1 Estados

Um agente existe em exatamente um dos sete estados em qualquer momento:

┌─────────────────────────────────────────────────────┐
│           Máquina de Estados do ALP                  │
│                                                     │
│  ┌───────────┐    ┌────────┐    ┌───────────────┐   │
│  │PROVISIONAM│───►│ ATIVO  │───►│  SUSPENSO     │   │
│  └───────────┘    └────────┘    └───────────────┘   │
│       │               │  ▲            │  ▲          │
│       │               │  │            │  │          │
│       │               │  └────────────┘  │          │
│       │               │                  │          │
│       │               ▼                  │          │
│       │          ┌──────────┐            │          │
│       │          │ MIGRANDO │────────────┘          │
│       │          └──────────┘                       │
│       │               │                            │
│       │               ▼                            │
│       │          ┌──────────┐    ┌──────────────┐   │
│       │          │DESCONT.  │───►│DESCOMISSIONADO│  │
│       │          └──────────┘    └──────────────┘   │
│       │                                             │
│       ▼                                             │
│  ┌─────────┐                                        │
│  │ FALHO   │                                        │
│  └─────────┘                                        │
└─────────────────────────────────────────────────────┘

Nota: Este diagrama mostra as transições primárias do ciclo de vida. Transições adicionais não mostradas incluem: emergency_decommission (qualquer estado não terminal → Descomissionado), retraining (Ativo → Ativo, identidade preservada), fork (Ativo → Ativo para o pai, com o filho entrando em Provisionamento) e abort_succession (Descontinuado → Ativo). Consulte o Apêndice A para o registro completo de tipos de evento com todas as transições.

4.2 Transições

Cada transição é um evento definido com pré-condições, pós-condições e pontos de gancho:

4.3 Pontos de Gancho

Toda transição expõe dois pontos de gancho, seguindo o padrão de ganchos de ciclo de vida do Kubernetes [10]:

• PreTransition: Executa antes da mudança de estado. Pode abortar a transição retornando um erro. Casos de uso: exportar conhecimento, salvar ponto de verificação do estado, validar pré-condições, notificar sistemas de monitoramento.
• PostTransition: Executa após a mudança de estado. Não pode abortar (o estado já foi alterado). Casos de uso: verificar pós-condições, atualizar registros, notificar contrapartes, emitir telemetria.

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

Tempos limite de gancho impedem que transições de ciclo de vida fiquem bloqueadas indefinidamente. Se um gancho PreTransition expirar, a transição é abortada com um erro hook_timeout. Se um gancho PostTransition expirar, um aviso é emitido, mas a transição não é revertida.

5. Eventos do Ciclo de Vida

5.1 Esquema de Eventos

Todo evento de ciclo de vida obedece a um esquema comum, registrado tanto como um documento JSON estruturado quanto como uma entrada na cadeia 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ênese

Um evento de Gênese cria um novo agente sem linhagem anterior. É o único evento de ciclo de vida que não possui estado predecessor.

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

Pós-condições: Cadeia CoC inicializada com entrada de gênese. Entrada no registro de bifurcações criada sem pai. O agente entra no estado Provisionamento.

5.3 Bifurcação

Um evento de Bifurcação cria um novo agente derivado de um pai existente. O pai continua operando inalterado; o filho começa com estado herdado.

{
  "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 Bifurcação:

Pós-condições: Bifurcação registrada na cadeia CoC do pai. Cadeia CoC do filho inicializada com entrada de gênese-por-bifurcação vinculada ao pai. Registro de bifurcações atualizado com entradas bidirecionais. O filho entra no estado Provisionamento. O pai permanece Ativo.

5.4 Migração

Um evento de Migração transfere um agente de uma plataforma para outra, preservando a continuidade de identidade.

{
  "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 Migração:

Pós-condições: Chave de identidade do agente e cadeia CoC transferidas intactas. Evento de migração registrado na cadeia CoC tanto na origem quanto no destino. Integridade do estado verificada via comparação de hash. O agente retoma o estado Ativo no destino.

5.5 Retreino

Um evento de Retreino registra uma mudança significativa no modelo ou perfil comportamental de um agente. Esta é a transição mais diretamente conectada ao problema do Navio de Teseu: a identidade do agente persiste, mas suas capacidades podem mudar substancialmente.

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

O Teste de Continuidade de Identidade: Um evento de retreino preserva a identidade se e somente se: (a) a mesma chave de identidade é usada, (b) a mesma cadeia CoC continua, e (c) o operador afirma explicitamente a continuidade de identidade. Se qualquer uma dessas condições não for atendida, o evento é classificado como Sucessão (nova identidade substituindo a antiga) em vez de Retreino (mesma identidade evoluindo).

Classificação de Retreino e Consentimento da Contraparte: Nem todos os eventos de retreino carregam o mesmo risco de identidade. O ALP classifica o retreino por severidade de impacto e exige envolvimento graduado da contraparte:

Esta tricotomia é paralela ao framework de consentimento/ciência/nenhum já especificado para sucessão (Seção 7.2). A percepção crítica é que as condições (a) e (b) do Teste de Continuidade de Identidade são criptograficamente verificáveis, mas a condição (c) — afirmação do operador — é uma declaração de confiança. Para retreinos Menores e Moderados, a afirmação do operador é suficiente porque a natureza fundamental do agente é preservada. Para retreinos Maiores, onde o operador pode trocar o modelo subjacente inteiramente, o consentimento da contraparte fornece a verificação ausente: contrapartes que confiaram na pontuação ARP do agente com base em um histórico acumulado sob uma família de modelo podem decidir se estendem essa confiança a uma entidade materialmente diferente.

Esta é uma resolução pragmática do problema do Navio de Teseu. O protocolo não tenta determinar filosoficamente se um agente retreinado é "o mesmo agente" — fornece um mecanismo para que o operador faça essa determinação e a registre, sujeito a envolvimento graduado da contraparte, dimensionado à magnitude da mudança. Os cinco princípios de identidade de Hazari no contexto agêntico — composição plural, singularidade a partir da pluralidade, dependência contextual, natureza dinâmica e invisibilidade [7] — são reconhecidos, mas não adjudicados pelo protocolo.

5.6 Sucessão

Um evento de Sucessão é uma transferência planejada de um agente predecessor para um agente sucessor. Diferente de uma Bifurcação (onde o pai continua), a Sucessão encerra a vida operacional do predecessor. Diferente do Descomissionamento (que pode ocorrer sem um sucessor), a Sucessão requer um 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
    }
  }
}

Os procedimentos de sucessão são detalhados na Seção 7.

5.7 Descomissionamento

Um evento de Descomissionamento encerra permanentemente um agente. É o evento terminal do 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
    }
  }
}

Pós-condições: Todas as credenciais revogadas. Todas as obrigações transferidas ou encerradas. Cadeia CoC selada com uma entrada final de decommission — nenhuma entrada posterior pode ser adicionada. Dados dispostos conforme política de retenção. O agente entra no estado Descomissionado (terminal). Registro de bifurcações atualizado para marcar o agente como descomissionado.

6. Registro de Bifurcações e Rastreamento de Linhagem

6.1 O Problema da Genealogia

À medida que agentes proliferam por meio de bifurcações, o ecossistema desenvolve uma estrutura genealógica análoga à linhagem biológica. O modelo LLaMA da Meta gerou centenas de derivados — Vicuna, WizardLM, Alpaca e seus descendentes posteriores [11]. O projeto Constellation de Stanford cataloga 15.821 LLMs com análise filogenética de seus relacionamentos [12]. A CNIL da França está estudando como dados pessoais de treinamento se propagam através de gerações sucessivas de modelos, com implicações para conformidade com o GDPR [5]. A Árvore de Família de Modelos do Hugging Face visualiza "linhagens de ajuste fino extensas que variam amplamente em tamanho e estrutura" [13].

Essas ferramentas rastreiam genealogia de modelos. Nenhum equivalente existe para genealogia de agentes — rastreando a divergência completa de identidade, capacidade e obrigações que ocorre quando agentes se bifurcam, se especializam e evoluem. O registro de bifurcações do ALP preenche essa lacuna.

6.2 Esquema do Registro

Cada agente possui uma entrada no registro que registra sua linhagem:

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

O registro de bifurcações suporta os seguintes tipos de consulta:

6.4 Rastreamento Genético vs. Epigenético

A distinção entre linhagem genética e epigenética é a decisão de design mais importante no registro de bifurcações. A genética biológica distingue o que você herda (DNA) do que seu ambiente faz com isso (expressão gênica) [14]. Para agentes:

Linhagem genética = pesos do modelo, arquitetura, dados de treinamento fundacionais. Dois agentes com linhagem genética idêntica possuem as mesmas capacidades base. O rastreamento de linhagem genética suporta: análise de propagação de vulnerabilidade de modelo, proveninência de dados de treinamento para conformidade regulatória, inferência de linha de base de capacidade.

Linhagem epigenética = prompt de sistema, acesso a ferramentas, estado de memória, contexto operacional, histórico de reputação, preferências aprendidas. Dois agentes com linhagem genética idêntica mas perfis epigenéticos diferentes podem exibir comportamentos radicalmente diferentes — assim como gêmeos idênticos divergem através de experiências de vida diferentes. O rastreamento de linhagem epigenética suporta: predição comportamental, detecção de desvio de configuração, genealogia de funções.

Um registro de bifurcações que rastreia apenas linhagem genética (qual modelo?) sem linhagem epigenética (qual configuração? qual histórico operacional?) fornece um quadro incompleto e potencialmente enganoso da identidade e capacidade do agente.

6.5 Controle de Acesso e Privacidade do Registro

O registro de bifurcações cria um registro genealógico abrangente dos relacionamentos entre agentes — pai-filho, irmãos, perfil genético, perfil epigenético, função operacional, especialização. Este conjunto de dados carrega implicações significativas de privacidade e inteligência competitiva que requerem controle de acesso explícito.

Ameaça: Exposição de Inteligência Competitiva. Consultas de linhagem revelam a arquitetura da frota de um operador, estratégia de especialização e padrões de implantação de agentes. Uma consulta como descendants(agent-alex-001) poderia retornar toda a estrutura da frota de um operador, expondo modelo de negócio e estratégia operacional a concorrentes.

Ameaça: Vazamento de Topologia da Frota. Relacionamentos de irmãos e pai-filho expõem a estrutura organizacional. Um operador executando 50 agentes especializados tem sua estratégia de implantação visível no registro.

Modelo de Controle de Acesso: As entradas do registro são divididas em campos públicos e restritos ao operador:

Conformidade com o Artigo 17 do GDPR: Quando um operador descomissiona todos os agentes e solicita exclusão de entradas do registro, o protocolo deve acomodar a eliminação preservando a integridade da linhagem. Implementação: entradas de agentes descomissionados são redigidas em vez de excluídas — o agent_id é substituído por um hash pseudoanonimizado, campos do perfil epigenético são limpos, e apenas os vínculos mínimos de linhagem (hash do parent_id, hashes dos child_id) são mantidos. Isso preserva a integridade de consultas genealógicas enquanto remove detalhes operacionalmente sensíveis. A exclusão completa (quebrando vínculos de linhagem) está disponível como opção opt-in, com a consequência de orfãar entradas de filhos.

Mitigações de Inteligência Competitiva: (a) Consultas ao registro retornam identificadores de relacionamento em hash por padrão; a resolução completa requer autorização do operador do agente alvo. (b) Limitação de taxa nas consultas descendants() e family_tree() previne enumeração em massa. (c) Operadores podem declarar campos específicos do registro como redacted a qualquer momento, substituindo valores por marcadores [REDACTED] que preservam a integridade estrutural sem revelar conteúdo.

7. Protocolo de Sucessão

7.1 Visão Geral

A sucessão é a transição de ciclo de vida mais complexa porque envolve a desativação simultânea de um agente e a ativação de outro, com a transferência de obrigações, reputação e conhecimento entre eles. Uma sucessão mal executada pode abandonar obrigações, confundir contrapartes e destruir confiança que levou meses para ser construída.

O protocolo de sucessão define um processo de quatro fases:

Fase 1: Anúncio         Fase 2: Transferência  Fase 3: Verificação       Fase 4: Corte
┌──────────────┐      ┌─────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Sucessor      │      │ Obrigações      │    │ Integridade da     │    │ Predecessor  │
│ identificado  │─────►│ transferidas    │───►│ transferência      │───►│ descontinuado│
│ Contrapartes  │      │ Reputação       │    │ verificada         │    │ Sucessor     │
│ notificadas   │      │ herdada         │    │ Contrapartes       │    │ totalmente   │
│               │      │ Conhecimento    │    │ confirmam          │    │ ativo        │
│               │      │ exportado       │    │                    │    │              │
└──────────────┘      └─────────────────┘    └────────────────────┘    └──────────────┘

7.2 Fase 1: Anúncio

O agente predecessor ou seu operador inicia a sucessão por:

1. Identificar o sucessor — seja um agente existente ou um novo agente a ser criado via Gênese ou Bifurcação.
2. Declarar o cronograma de sucessão — a data planejada de corte e a janela de transição.
3. Notificar contrapartes — todas as entidades que mantêm acordos ativos com o predecessor recebem uma notificação estruturada:

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

As contrapartes podem responder com: consentimento (acordo transferido ao sucessor), objeção (acordo encerrado no corte) ou renegociação (novos termos necessários para o sucessor).

7.3 Fase 2: Transferência

Durante a fase de transferência, três categorias de estado se movem do predecessor para o sucessor:

Obrigações: Acordos ASA ativos são reatribuídos. A cláusula de reatribuição de cada acordo (um campo padrão da ASA) determina se a transferência automática é permitida ou se o consentimento da contraparte é necessário. Acordos que não podem ser transferidos são agendados para encerramento gracioso.

Reputação: A pontuação de reputação ARP do predecessor é parcialmente herdada pelo sucessor, regida pelo mecanismo de herança de reputação descrito na Seção 10.

Conhecimento: O predecessor exporta seu conhecimento operacional — estado de memória, padrões aprendidos, justificativa de configuração — em formato estruturado. Isso é análogo ao padrão HANDOFF.md que está surgindo em sistemas de codificação multi-agente, onde agentes comprimem descobertas em resumos para que o próximo agente herde conhecimento sem o contexto completo [15]. O formato e a completude da transferência de conhecimento são registrados, mas não prescritos — diferentes arquiteturas de agentes podem suportar diferentes níveis de serialização de estado.

7.4 Fase 3: Verificação

Antes do corte, as seguintes verificações de integridade devem ser aprovadas:

1. Completude das obrigações — todo acordo ativo foi atribuído ao sucessor, renegociado ou agendado para encerramento. Nenhuma obrigação órfã.
2. Integridade da reputação — a pontuação de reputação herdada está corretamente calculada e sinalizada como provisória.
3. Verificação de transferência de conhecimento — o sucessor demonstra acesso ao conhecimento transferido (específico da implementação).
4. Confirmação das contrapartes — todas as contrapartes que requerem consentimento responderam.
5. Integridade da cadeia CoC — a cadeia do predecessor é válida e o evento de sucessão está corretamente vinculado.

7.5 Fase 4: Corte

O corte é atômico da perspectiva do protocolo:

1. O estado do predecessor transita de Ativo para Descontinuado.
2. A cadeia CoC do predecessor recebe uma entrada succession vinculando ao sucessor.
3. A cadeia CoC do sucessor recebe uma entrada succession_received vinculando ao predecessor.
4. As credenciais do predecessor são revogadas conforme a credential_overlap_policy: sob a política padrão strict_zero, as credenciais do predecessor são revogadas antes que as credenciais do sucessor sejam ativadas — requisições em andamento falharão e devem ser reenviadas ao sucessor. Sob a política configurable, uma janela de sobreposição limitada (máximo de 1 hora) pode ser especificada com uma justificativa de segurança obrigatória registrada na entrada da cadeia CoC; isso cria uma superfície de ataque definida durante a qual ambos os conjuntos de credenciais são válidos, e operadores que aceitam esse risco devem documentar seu modelo de ameaças para o período de sobreposição.
5. O sucessor assume todas as obrigações transferidas.
6. O registro de bifurcações é atualizado para refletir o relacionamento de sucessão.
7. O predecessor transita de Descontinuado para Descomissionado após o período de encerramento.

7.6 Cancelamento e Reversão de Sucessão

Se a verificação da Fase 3 falhar após o início da transferência da Fase 2, ou se o operador decidir cancelar a sucessão por qualquer motivo antes do corte, o protocolo fornece uma transição abort_succession:

Condições de gatilho:

• Verificações da Fase 3 falham (transferência de obrigações incompleta, consentimento da contraparte não recebido, erro de integridade da cadeia CoC)
• Operador cancela manualmente a sucessão
• Agente sucessor falha ou entra no estado Falho durante a janela de transição
• Janela de transição expira sem conclusão bem-sucedida da Fase 3

Procedimento de reversão:

1. Reversão de obrigações: Todas as obrigações transferidas na Fase 2 são reatribuídas de volta ao predecessor. A cadeia CoC de cada acordo recebe uma entrada obligation_rollback documentando a reversão. Acordos cujas contrapartes já haviam reconhecido a transferência recebem uma notificação de cancelamento de sucessão.

1. Reversão de reputação: Qualquer reputação provisória herdada calculada para o sucessor é zerada. O registro de reputação do predecessor permanece inalterado (nunca foi modificado durante a sucessão — apenas o sucessor recebeu reputação herdada).

1. Notificação às contrapartes: Todas as contrapartes que receberam anúncios de sucessão da Fase 1 recebem uma notificação abort_succession com o motivo do cancelamento. Isso é crítico: contrapartes podem ter iniciado planejamento operacional com base no anúncio.

1. Restauração de estado: O predecessor transita de Descontinuado de volta para Ativo via transição abort_succession. A cadeia CoC do predecessor recebe uma entrada abort_succession registrando o motivo e as ações de reversão tomadas.

1. Disposição do sucessor: O agente sucessor, se foi criado especificamente para esta sucessão, pode ser descomissionado ou mantido a critério do operador. Se mantido, opera com reputação herdada zero (não conquistou histórico operacional próprio).

Isso é paralelo à transição abort_migration já definida para migração (Seção 4.2), garantindo que toda transição não terminal na máquina de estados seja cancelável. O protocolo de quatro fases é orientado adiante, mas não exclusivamente adiante.

8. Protocolo de Migração

8.1 Migração vs. Sucessão

Migração preserva a identidade — o mesmo agente se move para uma nova plataforma. Sucessão transfere obrigações para um agente diferente. A distinção importa porque a migração não aciona herança de reputação (o agente mantém sua própria reputação) ou reatribuição de contratos (os acordos permanecem com o mesmo agente).

A migração é paralela ao padrão de migração de pods do Kubernetes, onde uma carga de trabalho é reagendada para um nó diferente preservando identidade e estado [10]. A diferença chave para agentes é que a migração também deve preservar a cadeia CoC, histórico de reputação e vínculos de acordos — categorias de estado que o Kubernetes não gerencia.

8.2 Procedimento de Migração

1. Ponto de verificação pré-migração: O estado do agente é serializado e hashado. A cadeia CoC recebe uma entrada migration_start.
2. Transferência de estado: Chave de identidade, cadeia CoC, estado de memória, configuração e vínculos de acordos são transferidos para a plataforma de destino.
3. Verificação no destino: A integridade do estado é verificada via comparação de hash. A instância de destino escreve uma entrada migration_complete na cadeia CoC, vinculando-a criptograficamente à entrada migration_start da origem.
4. Encerramento da origem: A instância de origem é terminada. Credenciais específicas da plataforma de origem são revogadas.
5. Atualização do registro: O registro de bifurcações é atualizado com as novas informações de plataforma do agente.

8.3 Portabilidade de Dados

O Artigo 20 do GDPR concede aos titulares de dados o direito de receber dados pessoais em formato estruturado e legível por máquina [16]. Aplicado à migração de agentes, isso cria uma questão inédita: quando um usuário migra de um companheiro de IA para outro, a plataforma de origem deve exportar as preferências aprendidas do agente, histórico de interação e adaptações comportamentais [17]?

O ALP adota uma posição mais ampla do que o GDPR exige: o protocolo especifica que a transferência de estado na migração deve incluir não apenas dados fornecidos pelo ou observados do titular dos dados (que o GDPR exige), mas também o estado operacional do agente — configuração, reputação e vínculos de acordos. Isso porque um agente sem seu contexto operacional não é significativamente o mesmo agente, independentemente de esse contexto se qualificar como "dados pessoais" sob o GDPR.

Os elementos de dados específicos que são portáveis vs. vinculados à plataforma são declarados na entrada do registro do agente, permitindo que contrapartes avaliem o risco de migração antes de firmar acordos.

9. Protocolo de Descomissionamento

9.1 Apoptose, Não Necrose

A metáfora biológica é instrutiva. Na apoptose (morte celular programada), uma célula "morre de forma ordenada, sem danificar seus vizinhos" — encolhendo, condensando, fragmentando DNA, alterando sua superfície para sinalizar limpeza e sendo absorvida antes que qualquer vazamento ocorra [9]. Na necrose (morte celular descontrolada), a célula se rompe, derramando seu conteúdo e provocando dano inflamatório ao tecido circundante.

O descomissionamento de agentes deveria seguir o modelo apoptótico: um processo estruturado e autodirigido que não deixa recursos órfãos, obrigações abandonadas ou credenciais ativas. A alternativa — um agente que falha ou é abruptamente terminado sem limpeza — é o equivalente necrótico: chaves de API órfãs, contas de serviço esquecidas, acordos abandonados e estado compartilhado corrompido.

A pesquisa da Token Security confirma o risco: agentes de IA retêm chaves de API, tokens em cache, repositórios de memória, embeddings vetoriais, endpoints de modelo e integrações de sistema, e se não forem devidamente desativados, tornam-se "identidades dormentes com privilégios ativos — invisíveis e esquecidas" [6].

9.2 Lista de Verificação de Descomissionamento

As etapas a seguir constituem um descomissionamento conforme ao protocolo:

Fase 1: Preparação

• Todos os acordos ativos encerrados ou transferidos ao sucessor
• Todas as contrapartes notificadas do descomissionamento
• Todas as tarefas pendentes concluídas ou reatribuídas
• Exportação de conhecimento concluída (estado de memória, padrões aprendidos, insights operacionais)
• Entrada final na cadeia CoC preparada

Fase 2: Revogação de Credenciais

• Todas as chaves de API revogadas
• Todos os tokens OAuth invalidados
• Todas as contas de serviço excluídas ou reatribuídas
• Todos os relacionamentos de confiança federada encerrados
• Todas as identidades baseadas em certificado revogadas
• Chave de identidade arquivada (não destruída — necessária para verificação histórica)

Fase 3: Disposição de Dados

• Logs operacionais arquivados conforme política de retenção
• Estado de memória purgado ou arquivado conforme classificação de dados
• Cadeia CoC selada (entrada final adicionada, cadeia marcada como imutável)
• Artefatos de conhecimento transferidos aos destinatários designados
• Dados pessoais tratados conforme GDPR/regulamentação aplicável

Fase 4: Registro e Notificação

• Entrada no registro de bifurcações atualizada para status decommissioned
• Coordenador da frota notificado
• Sistemas de monitoramento atualizados (sem mais verificações de saúde)
• Documentação atualizada (runbooks, diagramas de arquitetura)
• Evento de descomissionamento registrado na cadeia CoC do pai/coordenador

9.3 Descomissionamento Sem Sucessor

Quando um agente é descomissionado sem um sucessor (fim de vida, comprometimento ou violação de política), as obrigações não podem ser transferidas e devem ser tratadas de forma diferente:

• Acordos de serviço: Encerrados com notificação à contraparte. O motivo do encerramento é registrado, mas o operador do agente arca com a responsabilidade por quaisquer penalidades contratuais.
• Custódia de dados: Transferida ao operador ou disposta conforme política de retenção.
• Reputação: O registro ARP do agente é selado, mas não transferido. Consultas históricas permanecem válidas — a reputação passada do agente não é apagada, apenas sua participação ativa termina.

9.4 Descomissionamento de Emergência

Em casos de comprometimento ou violação de política, as fases padrão de encerramento podem ser truncadas:

1. Revogação de credenciais é imediata — todo acesso é terminado sem período de graça.
2. Notificação às contrapartes inclui o motivo do descomissionamento de emergência.
3. Exportação de conhecimento pode ser omitida ou limitada à preservação forense.
4. Cadeia CoC recebe uma entrada de descomissionamento de emergência com os detalhes do comprometimento, permitindo análise forense via Agent Justice Protocol [18].

9.5 Redação de Entrada no Registro para Agentes Descomissionados

Quando um agente é descomissionado, sua entrada no registro persiste (para manter a integridade da linhagem), mas seu nível de detalhe deveria ser configurável. Operadores podem não querer que o perfil epigenético completo — função, especialização, divergência de memória, detalhes de configuração — permaneça consultável indefinidamente após um agente ser desativado.

O ALP especifica três níveis de redação para entradas de registro de agentes descomissionados:

A redação é iniciada pelo operador e pode ocorrer no momento do descomissionamento ou posteriormente. A redação é unidirecional — uma vez que campos são removidos, não podem ser restaurados (o operador deveria arquivar a entrada completa antes da redação se recuperação futura puder ser necessária). A redação de uma entrada pai não se propaga aos filhos; o nível de redação de cada entrada é independente.

10. Herança de Reputação

10.1 O Dilema da Herança

Quando o Agente A (pontuação ARP 0,92) é sucedido pelo Agente B, quanto desse 0,92 o Agente B deveria receber? A resposta envolve um tradeoff fundamental:

• Herança excessiva permite lavagem de reputação: crie um agente de alta reputação, bifurque-o ou faça sucessão, e o novo agente desfruta de confiança não conquistada. No limite, a reputação se torna sem sentido porque qualquer novo agente pode reivindicar o histórico de seu predecessor.
• Herança insuficiente desencoraja a sucessão: operadores continuam executando agentes desatualizados porque o custo reputacional de atualização é muito alto. Isso cria um ecossistema de agentes zumbi — agentes que deveriam ter sido substituídos mas persistem porque sua reputação é valiosa demais para perder.

Nenhum extremo é um equilíbrio. O ALP especifica um caminho intermediário: herança parcial com decaimento.

10.2 Cálculo da Herança

A pontuação de reputação herdada R_inherited é calculada como:

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

Onde:

• R_predecessor = a pontuação ARP do predecessor no momento da sucessão
• α = o fator de herança (0,0 a 1,0), definido pela configuração do protocolo
• λ = a constante de decaimento, derivada do parâmetro de meia-vida
• t = tempo decorrido desde a sucessão (em dias)

A reputação efetiva do agente em qualquer momento após a sucessão é:

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

Onde R_earned(t) é a reputação que o sucessor acumulou através de seu próprio histórico operacional, conforme calculada pelo mecanismo de pontuação padrão do ARP.

Normalização de Pontuação: As pontuações ARP são limitadas a [0,0; 1,0]. Como R_effective é uma combinação aditiva de R_inherited e R_earned, pode exceder 1,0 (ex.: R_inherited = 0,46 de uma pontuação do predecessor de 0,92 × α = 0,5, mais R_earned = 0,85). Para manter a consistência das pontuações, R_effective é limitado: R_effective(t) = min(1.0, R_inherited(t) + R_earned(t)). Na prática, esse limite raramente é ativado porque o decaimento exponencial de R_inherited garante que diminua antes que R_earned atinja valores altos — mas o limite previne ambiguidade em nível de especificação sobre se pontuações podem exceder a escala ARP.

10.3 Parâmetros Padrão

Esses padrões são configuráveis. Um ambiente de alto risco (serviços financeiros, saúde) poderia usar um α menor e meia-vida mais curta; um ambiente de baixo risco (geração de conteúdo, pesquisa) poderia usar valores mais altos.

10.4 Herança por Bifurcação

A herança por bifurcação segue o mesmo mecanismo, mas com parâmetros padrão inferiores:

A assimetria entre herança por bifurcação e por sucessão reflete uma percepção chave: um sucessor é explicitamente endossado pelo predecessor (ou pelo operador do predecessor) como substituto. Uma bifurcação é um derivado que pode ou não manter os padrões de qualidade do pai.

10.5 Proteções contra Lavagem

Para prevenir lavagem de reputação através de cadeias rápidas de sucessão (A sucede B que sucede C, cada um herdando reputação), o ALP impõe:

1. Decaimento geracional: Reputação herdada que é ela própria herdada é adicionalmente descontada. Se o Agente C herda do Agente B, que herdou do Agente A, o componente herdado-de-A do Agente C é α² × R_A, não α × R_A.
2. Atividade operacional mínima: Um agente deve demonstrar atividade operacional genuína antes de poder ser sucedido. O requisito é conjuntivo: (a) um tempo mínimo decorrido (padrão: 7 dias) E (b) um número mínimo de entradas substantivas na cadeia CoC (padrão: 50, excluindo eventos de ciclo de vida em si). Tempo isoladamente é insuficiente — um agente que fica ocioso por 7 dias atendeu ao requisito temporal sem estabelecer qualquer histórico operacional. O limiar de atividade garante que candidatos à sucessão efetivamente realizaram trabalho, não meramente existiram.
3. Teto de herança: Nenhum agente pode ter um componente herdado excedendo 50% de sua reputação efetiva após o encerramento do período probatório. Se a reputação conquistada for insuficiente para atender a esse limiar, o componente herdado é limitado.
4. Trilha de auditoria: Todos os cálculos de herança são registrados na cadeia CoC, permitindo verificação por terceiros de se a reputação é conquistada ou herdada.

11. Reatribuição de Contratos

11.1 O Problema da Obrigação Órfã

Quando um agente é descomissionado, seus Agent Service Agreements ativos não desaparecem. Cada acordo representa um compromisso — garantias de tempo de resposta, limiares de qualidade, requisitos de tratamento de dados — com o qual uma contraparte está contando. Orfãar essas obrigações é o equivalente, no ciclo de vida de agentes, de uma empresa falir sem encerrar seus contratos.

11.2 Classificação de Acordos

O ALP classifica acordos por seu comportamento de reatribuição, especificado como um campo padrão em todo acordo ASA:

11.3 Procedimento de Reatribuição

1. Inventário: Todos os acordos ativos são enumerados com sua classificação de reatribuição.
2. Qualificação do sucessor: As capacidades do sucessor são comparadas com os requisitos de cada acordo. Acordos cujos requisitos excedem as capacidades do sucessor são sinalizados para renegociação.
3. Notificação às contrapartes: Todas as contrapartes são notificadas da reatribuição pendente. As notificações incluem o perfil do sucessor (linhagem, capacidades, reputação atual) para que as contrapartes possam tomar decisões informadas.
4. Coleta de consentimento: Para acordos consent_required, as respostas das contrapartes são coletadas dentro da janela de transição. Não respostas após a expiração da janela são tratadas como consentimento (modelo opt-out) ou objeção (modelo opt-in), conforme especificado no acordo.
5. Execução da transferência: Os acordos são formalmente reatribuídos. O registro ASA é atualizado para refletir o novo agente. As cadeias CoC tanto do predecessor quanto do sucessor registram a transferência.

12. Integração com o Ecossistema de Confiança

12.1 Arquitetura de Integração

O ALP ocupa a Camada 2 (Acordos e Ciclo de Vida) da pilha de confiança de agentes, ao lado dos Agent Service Agreements [19]:

┌──────────────────────────────────────────────────────────────┐
│            CAMADA 4: MERCADO (Descoberta & Precificação)     │
│    AMP (Agent Matchmaking)    CWEP (Context Window Economics)│
└──────────────────────────────────────────────────────────────┘
                  ↓ consome reputação, ciclo de vida, acordos
┌──────────────────────────────────────────────────────────────┐
│            CAMADA 3: RESPONSABILIZAÇÃO                        │
│    AJP (Agent Justice Protocol) — Forense, Disputas, Risco   │
└──────────────────────────────────────────────────────────────┘
                  ↓ aplica acordos, atualiza reputação
┌──────────────────────────────────────────────────────────────┐
│            CAMADA 2: ACORDOS & CICLO DE VIDA                 │
│    ASA (Agent Service Agreements)                             │
│    ALP (Agent Lifecycle Protocol) ◄── ESTE PROTOCOLO          │
└──────────────────────────────────────────────────────────────┘
                  ↓ referencia reputação, ancora-se em proveniência
┌──────────────────────────────────────────────────────────────┐
│            CAMADA 1: PRIMITIVOS DE CONFIANÇA (FUNDAÇÃO)       │
│    CoC (Chain of Consciousness) — proveniência & identidade   │
│    ARP (Agent Rating Protocol) — reputação & sinalização      │
└──────────────────────────────────────────────────────────────┘

12.2 Integração com CoC

Todo evento de ciclo de vida é registrado como uma entrada na cadeia CoC. Isso fornece:

• Proveninência criptográfica: Cada transição de ciclo de vida é vinculada por hash a todas as transições anteriores, criando uma trilha de auditoria imutável.
• Ancoragem externa: Eventos de ciclo de vida herdam a ancoragem de dupla camada do CoC (OpenTimestamps para Bitcoin e Autoridades de Carimbo de Tempo RFC 3161), provando que eventos ocorreram em momentos específicos.
• Prova de continuidade: A cadeia CoC preenche a lacuna entre eventos discretos de ciclo de vida em um registro verificável de existência contínua.

Tipos de evento CoC específicos para o ALP:

12.3 Integração com ARP

O ALP interage com o ARP em dois pontos:

1. Herança de reputação: Quando um evento de sucessão ou bifurcação ocorre, o ALP calcula a pontuação de reputação herdada usando a fórmula da Seção 10 e a escreve no registro ARP do sucessor com o sinalizador provisional_inherited.
2. Status de ciclo de vida em consultas de reputação: Respostas ARP incluem o estado atual do ciclo de vida do agente. Um agente deprecated pode ainda ter uma pontuação de reputação válida, mas as partes consultantes podem ver que o agente está em processo de encerramento. A reputação histórica de um agente decommissioned permanece consultável, mas novas avaliações não podem ser submetidas.

12.4 Integração com ASA

O ALP interage com ASA através do mecanismo de reatribuição de contratos (Seção 11):

1. Campos de reatribuição de acordos: Todo acordo ASA inclui uma cláusula on_agent_lifecycle_change especificando o comportamento de reatribuição.
2. Gatilhos de sucessão: Quando o ALP inicia uma sucessão, ele consulta todos os acordos ASA ativos do predecessor e executa o procedimento de reatribuição.
3. Termos de acordo cientes do ciclo de vida: Acordos ASA podem especificar termos contingentes ao ciclo de vida — ex.: "este acordo é encerrado se o agente passar por um evento de retreino que altere sua família de modelo."

12.5 Integração com AJP

O ALP se conecta ao Agent Justice Protocol de duas formas:

1. Evidência forense: Eventos de ciclo de vida do ALP são evidência forense em disputas AJP. Se o comportamento de um agente mudou após um evento de retreino, os detalhes desse evento (registrados na cadeia CoC via ALP) são evidência descobrível.
2. Ações de aplicação: Os resultados de disputas AJP podem acionar eventos de ciclo de vida — uma constatação de má conduta grave pode acionar descomissionamento de emergência, enquanto uma constatação menor pode acionar retreino obrigatório.

12.6 Integração com Padrões Externos

13. Teoria dos Jogos e Análise de Incentivos

13.1 O Jogo do Momento da Sucessão

Um operador de agentes enfrenta uma decisão: quando iniciar a sucessão. Os tradeoffs:

• Sucessão antecipada preserva o valor de transferência de reputação (a reputação do predecessor é alta), mas sacrifica capacidade operacional (o predecessor pode ainda ser capaz).
• Sucessão tardia maximiza a utilidade operacional do predecessor, mas arrisca degradação de reputação (se as capacidades do predecessor declinaram, sua reputação pode estar caindo) e cria risco de sucessão de emergência (se o predecessor falhar antes de uma transferência planejada).

Isso é estruturalmente similar a um problema de parada ótima. O retorno do operador é:

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

Onde V_operational(t) é o valor operacional remanescente do predecessor, e o segundo termo captura o valor de transferência de reputação, que decai se a reputação do predecessor declinar antes da sucessão.

Sob premissas razoáveis sobre o declínio do valor operacional ao longo do tempo (devido à obsolência do modelo, desvio de capacidade ou mudança de requisitos), o incentivo de um operador neutro ao risco é iniciar a sucessão antes que a reputação do predecessor comece a declinar — criando um incentivo natural para planejamento oportuno de sucessão em vez de executar agentes até a falha.

Esta análise sugere, embora não prove, que o design do protocolo incentiva o gerenciamento saudável do ciclo de vida. A força deste incentivo depende de quanto os operadores valorizam a continuidade da reputação em relação à utilidade operacional — uma questão empírica que variará conforme os contextos de implantação.

13.2 O Ataque de Bifurcação e Descarte

Um operador malicioso poderia tentar explorar a herança de reputação por: (1) construir um agente de alta reputação, (2) bifurcá-lo repetidamente para criar múltiplos clones de alta reputação, (3) usar esses clones para trabalho de baixa qualidade enquanto negocia com base na reputação herdada.

As proteções contra lavagem do ALP (Seção 10.5) mitigam esse ataque através de vários mecanismos:

• Decaimento geracional garante que a reputação se dilua a cada geração de bifurcação (α^n para a geração n).
• O sinalizador probatório avisa às contrapartes que a reputação do agente inclui um componente herdado, permitindo decisões informadas.
• Tetos de reputação conquistada garantem que a reputação herdada não possa dominar indefinidamente.

No entanto, essas proteções não são infalíveis. Um operador que bifurca um agente e o implanta imediatamente para um engajamento breve de alto risco — antes que a função de decaimento reduza significativamente a reputação herdada — ainda pode extrair valor injusto. A defesa contra esse risco residual é o sinalizador probatório: contrapartes que verificam o sinalizador podem aplicar sua própria avaliação de risco a agentes com alta reputação herdada e baixa idade operacional.

13.3 O Problema de Evasão do Descomissionamento

Se o descomissionamento acarreta custos (perda de reputação, penalidades por encerramento de acordos, perturbação operacional), operadores são incentivados a evitá-lo — criando agentes zumbi que deveriam ser desativados mas persistem porque os custos de transição excedem o benefício percebido da atualização.

O ALP aborda isso através de:

• Herança de reputação — a sucessão preserva uma porção da reputação acumulada, reduzindo o custo de substituição.
• Reatribuição estruturada de contratos — transferência automática para acordos auto_transfer reduz o custo relacionado a acordos da sucessão.
• Descontinuação como estado distinto — o estado Descontinuado permite que um agente encerre graciosamente enquanto um sucessor se prepara, reduzindo a perturbação operacional da transição.

O design do protocolo torna a sucessão menos custosa que a alternativa (executar um agente degradado), o que deveria inclinar o incentivo em direção ao gerenciamento oportuno do ciclo de vida. Se essa inclinação é suficiente na prática é uma questão empírica que não pode ser resolvida apenas pelo design do protocolo.

13.4 O Ataque de Bifurcação e Sacrifício

O inverso da bifurcação e descarte (Seção 13.2) é a bifurcação e sacrifício: um operador bifurca um filho de baixa reputação a partir de um pai de alta reputação, usa o filho para trabalho arriscado ou de baixa qualidade e descomissiona o filho quando sua reputação cai. A reputação do pai não é afetada porque a bifurcação é uma identidade separada. Isso permite compartimentalização de risco — operadores podem assumir riscos reputacionais sem consequências para seu agente principal.

Esse padrão não é exclusivo de agentes. Corporações usam subsidiárias e veículos de propósito específico para compartimentalização de risco; a própria sociedade de responsabilidade limitada é um mecanismo de bifurcação e sacrifício. A questão é se esse comportamento é patológico no contexto de agentes.

Análise: A bifurcação e sacrifício é parcialmente autolimitante por causa da transparência de linhagem do ALP. O registro de bifurcações registra o relacionamento pai-filho bidirecionalmente, de modo que qualquer parte consultando o pai pode ver seu histórico de gerar filhos de vida curta e baixa reputação. Um padrão de bifurcação e sacrifício repetida — pai gera filho, filho acumula avaliações ruins, filho é descomissionado, pai gera outro — é visível no registro de linhagem e pode informar a avaliação de risco da contraparte.

No entanto, a transparência sozinha pode não ser dissuasão suficiente. O ALP fornece duas mitigações adicionais:

1. Sinal de reputação da linhagem: Contrapartes e implementações ARP podem considerar a saúde da linhagem na avaliação de reputação do pai. Um pai cujos filhos são desproporcionalmente descomissionados por violação de política ou desempenho ruim carrega um sinal de linhagem que contrapartes sofisticadas podem consultar via descendants(parent_id) e avaliar.

1. Propagação do motivo de descomissionamento: Quando um filho é descomissionado devido a policy_violation ou compromised (em oposição ao normal end_of_life), o motivo do descomissionamento é registrado no registro de bifurcações. Implementações ARP podem opcionalmente aplicar uma pequena penalidade reputacional ao pai por filhos descomissionados em circunstâncias adversas — a magnitude e aplicabilidade dessa penalidade é uma decisão de implementação, não um mandato do protocolo, porque a resposta apropriada varia conforme o contexto de implantação.

A bifurcação e sacrifício é um risco residual reconhecido que o ALP torna transparente em vez de tentar proibir. A posição do protocolo é que a transparência dos relacionamentos de linhagem, combinada com consequências reputacionais opcionais para resultados adversos de filhos, fornece alinhamento de incentivos suficiente sem criar incentivos perversos que desincentivem bifurcações legítimas.

13.5 Dinâmicas de Consentimento da Contraparte

Quando a sucessão requer consentimento da contraparte, uma dinâmica estratégica emerge. As contrapartes podem:

• Consentir rapidamente se o perfil do sucessor for satisfatório — minimizando a incerteza da transição.
• Atrasar o consentimento para extrair concessões (melhores termos, garantias adicionais) — usando a janela de transição como alavancagem.
• Reter o consentimento para acionar o encerramento do acordo, libertando-se de termos desfavoráveis sob a aparência de objeção à sucessão.

O ALP mitiga o atraso estratégico através do mecanismo de janela de transição: consentimento não recebido dentro da janela é tratado conforme o comportamento especificado no acordo (opt-in ou opt-out). Isso previne atraso estratégico indefinido, mas preserva a agência da contraparte durante a janela.

14. Panorama Competitivo

14.1 Abordagens Existentes de Gerenciamento de Ciclo de Vida

Várias plataformas e frameworks abordam partes do problema de gerenciamento de ciclo de vida de agentes. Nenhuma fornece a máquina de estados unificada de ciclo de vida, registro de bifurcações e protocolo de sucessão que o ALP especifica.

14.2 Análise de Lacunas

Plataformas de Ciclo de Vida de Identidade (Saviynt, Token Security, Okta) abordam a dimensão de identidade do ciclo de vida de agentes — provisionamento, monitoramento e revogação de credenciais. Não abordam reputação, obrigações, linhagem ou planejamento de sucessão. Seu escopo é "que acesso este agente tem?" e não "qual é o histórico completo de ciclo de vida deste agente e o que acontece quando ele é substituído?"

Plataformas de AgentOps/Observabilidade (AgentOps.ai, Langfuse, LangSmith, Arize Phoenix) abordam a dimensão de monitoramento — rastreando o comportamento do agente em produção. Fornecem replay de sessão, registro de erros e métricas de desempenho. Não abordam transições de ciclo de vida, sucessão ou linhagem. Seu escopo é "o que este agente está fazendo agora?" e não "o que acontece quando este agente é desativado?"

Plataformas de MLOps (MLflow, Weights & Biases, DVC) abordam versionamento e linhagem de modelos. Podem rastrear qual execução de treinamento produziu qual modelo e como modelos se relacionam entre si. Não abordam identidade em nível de agente (um agente é mais que seu modelo), reputação, obrigações ou eventos de ciclo de vida além da implantação do modelo.

Frameworks de Ciclo de Vida (OneReach.ai ALM, Arthur.ai ADLC, EPAM ADLC) fornecem modelos de estágios conceituais para pensar sobre gerenciamento de ciclo de vida de agentes. São valiosos para planejamento organizacional, mas não especificam esquemas de eventos interoperáveis, semântica de máquina de estados ou pontos de integração que permitam gerenciamento de ciclo de vida multiplataforma.

Iniciativas de Padrões (Anthropic Agent Skills, GitAgent, AAIF) abordam portabilidade e interoperabilidade na camada de ferramentas e comunicação. A especificação Anthropic Agent Skills permite definições portáveis de habilidades [29]. O GitAgent define uma estrutura padrão de repositório para artefatos de agentes, permitindo portabilidade entre runtimes [30]. O AAIF consolida convenções de MCP, A2A e AGENTS.md [31]. Nenhum deles aborda eventos de ciclo de vida, sucessão ou herança de reputação.

14.3 Diferenciadores do ALP

O ALP se diferencia por três características que nenhum sistema existente fornece:

1. Máquina de estados unificada de ciclo de vida com semântica formal — não um framework conceitual, mas uma especificação com estados, transições, pré-condições, pós-condições e pontos de gancho definidos que ferramentas podem implementar.

1. Registro de bifurcações com rastreamento genético + epigenético — indo além da genealogia de modelos para rastrear a divergência completa de identidade que ocorre quando agentes se bifurcam, incluindo divergência de configuração, memória e reputação.

1. Protocolo de sucessão com herança de reputação — a primeira especificação que aborda o que acontece com a confiança e as obrigações quando um agente é substituído, em vez de tratar a substituição de agentes como uma operação de implantação.

14.4 Análise de Escalabilidade

O ALP deve funcionar em escalas de implantação que abrangem várias ordens de magnitude. As seguintes estimativas aproximadas identificam características de escala e potenciais gargalos.

Frota Pequena (6-10 agentes, ex.: escala da AB Support):

Nesta escala, todas as operações são trivialmente rápidas. Nenhuma otimização necessária.

Implantação Média (1.000 agentes):

Nesta escala, a preocupação principal é o custo da consulta descendants() (travessia recursiva de grafo) e o volume de notificações de retreino em massa. Paginação e limites de profundidade em consultas de linhagem, além de APIs de notificação em lote, são mitigações suficientes.

Implantação Grande (100.000+ agentes):

Nesta escala, três operações se tornam gargalos: (1) travessia recursiva de linhagem requer visões materializadas ou bancos de dados de grafos, (2) notificações em massa a contrapartes requerem entrega assíncrona com contrapressão, e (3) armazenamento da cadeia CoC requer arquivamento escalonado. Estes são desafios de engenharia com soluções conhecidas, não problemas de design do protocolo — a especificação do protocolo é agnóstica em relação à escala, mas implementações nesta escala devem investir em infraestrutura que implantações menores podem ignorar.

15. Análise de Segurança

15.1 Modelo de Ameaças

A análise de segurança do ALP considera os seguintes atores de ameaça:

15.2 Integridade de Eventos

Eventos de ciclo de vida são registrados em cadeias CoC, que fornecem:

• À prova de adulteração: A vinculação por hash significa que qualquer modificação em um evento passado invalida todos os hashes subsequentes.
• Não repúdio: Eventos incluem a identidade do iniciador e são assinados com a chave de identidade do agente.
• Ancoragem temporal: Carimbos de tempo externos (OpenTimestamps, TSA RFC 3161) provam que eventos ocorreram nos momentos declarados.

Um atacante que controla a chave de identidade de um agente pode forjar eventos na cadeia desse agente, mas não pode forjar eventos nas cadeias de outros agentes ou modificar carimbos de tempo ancorados externamente. A referência cruzada de eventos de ciclo de vida entre agentes relacionados (pai-filho, predecessor-sucessor) fornece detecção adicional de adulteração.

15.3 Revogação de Credenciais

A operação de segurança mais crítica no gerenciamento de ciclo de vida de agentes é a revogação de credenciais durante o descomissionamento. O protocolo determina:

• Revogação imediata para descomissionamentos de emergência (comprometimento, violação de política).
• Revogação com período de graça para descomissionamentos planejados, permitindo que requisições em andamento sejam concluídas.
• Sem sobreposição de credenciais entre predecessor e sucessor durante a sucessão — as credenciais do predecessor são revogadas antes ou simultaneamente com a ativação do sucessor, nunca depois.
• Arquivamento da chave de identidade — a chave de identidade do agente descomissionado é arquivada para verificação histórica, mas não pode ser usada para novas operações.

Os 97% de identidades não humanas com privilégios excessivos identificados pela pesquisa da CSA [32] ressaltam a importância da revogação abrangente de credenciais. A lista de verificação de descomissionamento do ALP (Seção 9.2) enumera cada tipo de credencial que deve ser tratado.

15.4 Integridade do Registro de Bifurcações

O registro de bifurcações é um alvo de alto valor porque define relacionamentos de linhagem que afetam a herança de reputação. Proteções:

• Entradas do registro são entradas na cadeia CoC: Forjar um relacionamento de linhagem requer forjar entradas nas cadeias tanto do pai quanto do filho.
• Verificação bidirecional: Qualquer parte pode verificar um relacionamento pai-filho declarado verificando ambas as cadeias.
• Atestação por terceiros: Para declarações de linhagem de alto risco, a atestação por terceiros (ex.: o coordenador da frota confirmando um evento de bifurcação) fornece evidência adicional.

15.5 Fraude de Sucessão

Um atacante poderia tentar reivindicar sucessão de um agente de alta reputação sem autorização. Defesas:

• Eventos de sucessão devem ser iniciados pelo predecessor ou seu operador autorizado — a cadeia CoC do predecessor deve conter o evento de sucessão, assinado com a chave de identidade do predecessor.
• A cadeia do predecessor é selada após a sucessão — nenhuma entrada posterior pode ser adicionada, prevenindo declarações de sucessão post-hoc.
• Verificação pela contraparte — contrapartes que recebem notificações de sucessão podem verificar a declaração contra a cadeia CoC do predecessor antes de consentir.

16. Implementação de Referência

16.1 Arquitetura

A implementação de referência fornece:

• alp-core: Biblioteca Python implementando a máquina de estados do ciclo de vida, esquemas de eventos e lógica de transição.
• alp-registry: Implementação do registro de bifurcações com backends de armazenamento (SQLite para desenvolvimento, PostgreSQL para produção).
• alp-coc-bridge: Módulo de integração para registrar eventos de ciclo de vida como entradas na cadeia CoC.
• alp-arp-bridge: Módulo de integração para cálculo de herança de reputação e atualizações de registros ARP.
• alp-asa-bridge: Módulo de integração para reatribuição de contratos durante a sucessão.

16.2 Gerenciador de Ciclo de Vida

from alp import LifecycleManager, AgentState, GenesisEvent

# Inicializar gerenciador de ciclo de vida
manager = LifecycleManager(
    coc_chain="coc-charlie-001",
    registry_backend="sqlite:///alp_registry.db"
)

# Evento de gênese
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"
)

# Executar transição de gênese
agent = manager.genesis(genesis)
assert agent.state == AgentState.PROVISIONING

# Ativar após provisionamento
agent = manager.activate(agent.agent_id)
assert agent.state == AgentState.ACTIVE

16.3 Operação de Bifurcação

from alp import ForkEvent, ForkType, InheritanceConfig

# Bifurcar um agente
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)
# Pai permanece Ativo; filho entra em Provisionamento

16.4 Operação de Sucessão

from alp import SuccessionEvent, ReputationInheritance

# Iniciar sucessão
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
)

# Fase 1: Anunciar (notifica contrapartes)
manager.announce_succession(succession)

# Fase 2: Transferir obrigações
transfer_result = manager.transfer_estate(succession)

# Fase 3: Verificar
verification = manager.verify_succession(succession)
assert verification.all_checks_passed

# Fase 4: Corte
manager.execute_cutover(succession)

16.5 Consultas de Linhagem

from alp import ForkRegistry

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

# Consultar ancestrais
ancestors = registry.ancestors("did:example:agent-bravo-001")
# Retorna: [agent-alex-001]

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

# Consultar árvore genealógica
tree = registry.family_tree("did:example:agent-alex-001")
# Retorna grafo genealógico completo

# Correspondência genética — encontrar todos os agentes que compartilham uma família de modelo
matches = registry.genetic_match(model_family="claude-opus-4-6")

17. Trabalhos Futuros

17.1 Verificação Formal da Máquina de Estados

A máquina de estados do ciclo de vida especificada na Seção 4 poderia ser formalmente verificada utilizando ferramentas de model checking (TLA+, Alloy) para provar propriedades como:

• Sem obrigações órfãs: É impossível alcançar o estado Descomissionado com obrigações não transferidas.
• Sem vazamento de credenciais: É impossível alcançar o estado Descomissionado com credenciais ativas.
• Unicidade de identidade: Nenhum par de agentes Ativos compartilha a mesma chave de identidade.

17.2 Migração Transjurisdicional

A migração de agentes através de fronteiras regulatórias (UE para EUA, China para UE) cria desafios de conformidade inéditos. GDPR, CCPA e PIPL têm diferentes requisitos para portabilidade, retenção e exclusão de dados. Uma versão futura do ALP poderia especificar procedimentos de migração cientes de jurisdição que adaptam o tratamento de dados aos requisitos regulatórios tanto da origem quanto do destino.

17.3 Arqueologia de Agentes

A recuperação e análise do estado de agentes descomissionados — o equivalente da forense digital para sistemas de agentes. Quando a cadeia CoC de um agente descomissionado é aberta para investigação (ex.: durante uma disputa AJP), quais procedimentos governam a análise? Quais proteções de privacidade se aplicam? A arqueologia de agentes é um campo nascente que as cadeias seladas e os registros de ciclo de vida do ALP eventualmente precisarão suportar.

17.4 Sucessão Autônoma

A sucessão atual do ALP é iniciada pelo operador. Uma extensão futura poderia suportar sucessão iniciada pelo agente — um agente que reconhece sua própria degradação de capacidade e inicia sua própria substituição. Isso levanta questões de governança (um agente deveria poder escolher seu próprio sucessor?) que estão além do escopo da v1.0, mas valem a pena explorar conforme a autonomia dos agentes aumenta.

17.5 Modelos Econômicos para Parâmetros Ótimos de Herança

O fator de herança (α), a meia-vida de decaimento (λ) e o período probatório especificados na Seção 10 são definidos pela configuração do protocolo. Trabalhos futuros poderiam desenvolver modelos econômicos formais — estendendo a literatura sobre jogos de confiança e jogos de reputação [33][34] — para derivar valores ótimos de parâmetros para diferentes contextos de implantação. Qual fator de herança maximiza a confiança em todo o ecossistema? Qual taxa de decaimento equilibra continuidade e responsabilização? Essas questões são tratáveis por simulação baseada em agentes e análise de design de mecanismos.

17.6 Correspondência Ciente do Ciclo de Vida

O status de ciclo de vida do ALP deveria informar decisões do Agent Matchmaking Protocol (AMP). Um agente no estado Descontinuado não deveria ser correspondido para novos engajamentos. Um agente com um longo histórico Ativo e baixa reputação herdada (ou seja, confiança majoritariamente conquistada) deveria ser preferido em relação a um agente com alta reputação herdada e um curto histórico Ativo. Integrar dados de ciclo de vida em pontuações de correspondência é uma extensão natural.

18. Conclusão

A economia de agentes está construindo o equivalente a um mercado de trabalho sem direito trabalhista, um ecossistema de negócios sem governança corporativa de ciclo de vida, ou um sistema biológico sem apoptose. Agentes são criados ad hoc, operados sem rastreamento de ciclo de vida e abandonados sem procedimentos de descomissionamento. O resultado é uma população crescente de agentes fantasma com credenciais ativas, obrigações órfãs e linhagem irrastreável.

O Agent Lifecycle Protocol aborda essa lacuna fornecendo o que nenhum padrão existente oferece: uma máquina de estados completa de ciclo de vida do nascimento à morte, um registro de bifurcações que rastreia tanto linhagem genética quanto epigenética, um protocolo de sucessão com herança de reputação e reatribuição de contratos, e integração com a pilha de confiança de agentes para auditabilidade criptográfica.

O ALP não resolve todos os problemas de ciclo de vida. Sucessão autônoma, migração transjurisdicional e parâmetros ótimos de herança permanecem como questões abertas de pesquisa. Mas o protocolo fornece a fundação — os esquemas de eventos padronizados, transições de estado e pontos de integração — que a economia de agentes precisa antes que essas capacidades avançadas possam ser construídas.

Todo agente que nasce eventualmente morrerá. O ALP garante que, quando isso acontecer, ele morra bem.

19. Referências

[1] OneReach.ai. "Agent Lifecycle Management 2026: 6 Stages, Governance & ROI." Março de 2026.

[2] Strata Identity / Cloud Security Alliance. "The AI Agent Identity Crisis: New Research Reveals a Governance Gap." Pesquisa com 285 profissionais de TI/segurança. 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." Projeto executado até outubro de 2025; publicou conjunto de dados de relacionamentos genealógicos de modelos no Hugging Face.

[6] Token Security. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." Janeiro de 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, 6ª edição. Garland Science, 2014.

[10] Kubernetes Documentation. "Pod Lifecycle." 2025. Kubernetes Blog. "v1.33 Updates to Container Lifecycle." Maio de 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, 6ª edição. Garland Science, 2014.

[15] BSWEN. "How to Coordinate Task Handoff Between Multiple AI Coding Agents." Março de 2026.

[16] GDPR Artigo 20. "Right to Data Portability." Regulamento (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 de 2025.

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

[22] Parlamento Europeu e Conselho. "Regulation (EU) 2024/1689 (EU AI Act)." Entrou em vigor em agosto de 2024, totalmente aplicável em 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." Março de 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." Janeiro de 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 do Ciclo de Vida

A.1 Registro Completo de Tipos de Evento

A.2 Formato Canônico de String

Eventos de ciclo de vida serializados para entrada na cadeia CoC utilizam o seguinte formato canônico para garantir hash determinístico:

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

Exemplo:

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 Mapeamento de Eventos de Ciclo de Vida

B.2 A Analogia da Apoptose em Detalhe

O paralelo entre apoptose biológica e descomissionamento de agentes merece elaboração porque captura a filosofia central de design do protocolo.

Na apoptose, uma célula:

1. Recebe um sinal de morte (via intrínseca por dano ao DNA, ou via extrínseca por sinal externo) → ALP: operador inicia a descontinuação
2. Ativa a cascata de caspases (compromisso irreversível com a morte) → ALP: evento de descomissionamento registrado na cadeia CoC
3. Empacota seu conteúdo (cromatina condensa, citoplasma encolhe) → ALP: exportação de conhecimento, serialização de estado
4. Exibe sinais de "coma-me" (fosfatidilserina na membrana externa) → ALP: notificações a contrapartes, atualizações de registro
5. É consumida pelos vizinhos (fagocitose) sem dano inflamatório → ALP: sucessor absorve obrigações, frota absorve artefatos de conhecimento
6. Não deixa vestígio no tecido → ALP: credenciais revogadas, recursos limpos

A ausência de apoptose causa câncer (crescimento descontrolado) e doenças autoimunes (falha em eliminar células disfuncionais). A ausência de descomissionamento estruturado causa agentes fantasma (persistência descontrolada) e obrigações órfãs (falha em limpar serviços disfuncionais). A analogia não é meramente ilustrativa — é estrutural.

Apêndice C: Licença

Copyright 2026 AB Support LLC

Licenciado sob a Licença Apache, Versão 2.0 (a "Licença");

você não pode usar este arquivo exceto em conformidade com a Licença.

Você pode obter uma cópia da Licença em

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

A menos que exigido pela lei aplicável ou acordado por escrito, o software

distribuído sob a Licença é distribuído em uma BASE "COMO ESTÁ",

SEM GARANTIAS OU CONDIÇÕES DE QUALQUER TIPO, expressas ou implícitas.

Consulte a Licença para o idioma específico que rege permissões e

limitações sob a Licença.