Resumo

  • Publicado em 2 de setembro de 2026, draft-paxton-aicp-00 é um Internet-Draft individual ativo. Não tem endosso ou posição formal da IETF, fluxo RFC, Area Director responsável ou data de teleconferência.
  • O progresso do AICP registra etapas concluídas, ativas e totais e pode incluir um percentual. Os conjuntos de etapas são autoritativos; o número é indicativo.
  • A proposta proíbe interpretar o percentual como chance de sucesso ou limite seguro para cancelar.
  • Fase e estado do efeito são independentes. Uma operação cancelada ou malsucedida pode manter efeitos parciais, e o cancelamento é um pedido separado, idempotente e de melhor esforço.
  • Uma parada consequente precisa de recibo próprio, com etapas, fase, efeito, sequência, estado do pedido de cancelamento, observações pendentes e necessidade de reconciliação.

A barra não sabe o peso de cada etapa

O registro atual no Datatracker apresenta o Agent Infrastructure Control Protocol (AICP) como a revisão 00 de um Internet-Draft individual de Tihan-Nico Paxton, atualizado em 2 de setembro de 2026. Standards Track aparece como destino pretendido pelo autor, não como aprovação atual. Não há fluxo RFC, Area Director responsável nem teleconferência registrados. A orientação da IETF esclarece que qualquer pessoa pode submeter um Internet-Draft e que a publicação não confere posição formal.

A questão operacional existe independentemente do status institucional. Uma barra de progresso costuma responder, sem dizer, a três perguntas: quanto do roteiro foi percorrido, qual a chance de terminar bem e se é seguro parar agora. O AICP trata essas perguntas como coisas separadas.

Compare dois planos de cinco etapas. Um executa a única mutação irreversível primeiro e usa as quatro seguintes para conferir o resultado. O outro faz quatro leituras preparatórias e só escreve no fim. Vinte por cento no primeiro plano pode significar que o efeito decisivo já ocorreu; 80% no segundo pode significar que nada mudou. Contar etapas não pondera consequências.

A revisão congelada torna essa limitação explícita. A estrutura de progresso identifica etapas concluídas, ativas e totais, e esses conjuntos são autoritativos. Um percentual pode ser acrescentado, mas é indicativo. Ele não representa probabilidade de sucesso e não define um ponto seguro de cancelamento.

O texto não estabelece relação entre o número e a magnitude do efeito. Portanto, 0% não autoriza inferir estado none, assim como 100% não prova efeito complete ou sucesso. Se uma tela fizer essas associações, terá criado uma regra própria.

Fase e efeito ocupam colunas diferentes

Uma Operation do AICP pode estar em fila, aguardando aprovação, executando, verificando, pausada, bem-sucedida, malsucedida, cancelada ou indeterminada. Separadamente, o estado do efeito pode ser nenhum, possível, parcial, completo, revertido ou desconhecido.

A independência é essencial. Uma operação pode falhar depois de alterar um serviço externo. Pode ser cancelada com parte da mudança já produzida. Pode terminar com sucesso e ainda assim registrar efeitos colaterais. O provedor deve atualizar o efeito de forma conservadora; ausência de observação não é observação de ausência.

O Outcome terminal preserva a mesma disciplina. Ele separa mudanças esperadas de mudanças observadas, registra efeitos colaterais, evidência e próximas ações. Cada critério pode estar satisfeito, insatisfeito, desconhecido ou não avaliado. Respostas de sucesso das APIs do provedor não bastam para declarar a Operation bem-sucedida.

Assim, posição no plano, fase do ciclo de vida, alteração no mundo e qualidade da evidência são dimensões distintas. Uma barra que muda de cor e pretende expressar todas elas não está apenas resumindo; está decidindo por conta própria.

Cancelar é pedir, não desfazer

No AICP, o cancelamento é um pedido de controle independente e idempotente. A repetição do mesmo pedido após uma falha de rede não cria várias ordens de cancelamento. Ainda assim, a execução é de melhor esforço. Se o pedido disputar uma corrida com a conclusão, o provedor devolve a Operation atual. Retomar uma operação exige reavaliar autoridade, restrições e pré-condições.

O provedor deve informar a fase terminal resultante e o estado do efeito, sem alegar que cancelled significa ausência de efeito. A regra inviabiliza limites como “é seguro cancelar antes de 40%”. A etapa ativa talvez já tenha feito uma chamada externa; uma etapa concluída talvez contenha a única mutação; ou a observação talvez esteja atrasada.

Compensação também não é cancelamento ao contrário. Reverter requer uma nova ação consequente, com autorização, risco de falha e efeitos colaterais próprios. Mesmo reversed deve refletir observação sobre a compensação; não promete que todo o ambiente voltou a uma condição idêntica.

O mesmo vale para repetição. Efeitos possíveis, parciais ou desconhecidos não devem provocar uma nova mutação às cegas. O modelo de problema pode declarar segurança de nova tentativa e necessidade de reconciliação. Timeout, cor vermelha ou percentual baixo não concedem essa permissão.

Um recibo para o momento da parada

Minha recomendação é gerar um recibo separado sempre que pausar ou cancelar possa produzir consequências. Isso não é uma exigência da revisão 00; é uma forma de levar para a decisão operacional as distinções que a proposta já preserva.

O recibo identificaria a Operation durável e a última sequência. Reproduziria as etapas concluídas, ativas e totais, sem substituí-las pela razão. Mostraria fase e efeito lado a lado, identificaria o pedido de cancelamento e seu estado, listaria observações ainda abertas e indicaria se reconciliação é obrigatória antes de repetir ou compensar.

Mudança esperada e mudança observada continuariam separadas. Se uma etapa deveria revogar uma credencial, mas não há confirmação independente, “revogação esperada; efeito desconhecido” é mais preciso que “cancelado em 35%”. Unknown não é um espaço a ser preenchido com o percentual; é uma conclusão válida.

O direito a registros exatos descrito por Heng Lu oferece uma disciplina editorial útil: o registro descreve a realidade, não a cria. Por analogia, o recibo não pode fabricar chance de sucesso ou segurança a partir de uma razão. Essa é uma aplicação analítica minha, não uma afirmação de que o ensaio de Heng Lu define o AICP.

Uma gramática ainda sem prova de operação

A revisão 00 contém um exemplo de ciclo HTTP e invariantes de protocolo. Não encontrei uma seção Implementation Status no texto analisado. As fontes não estabelecem implementação independente, uso em produção, resultado de interoperabilidade ou adoção pela IETF. A explicação do RFC Editor lembra que um Internet-Draft pode mudar, expirar ou nunca virar RFC.

Os testes decisivos devem preservar combinações desconfortáveis: 0% com efeito possível, 100% com critério insatisfeito, cancelamento com efeito parcial e fase indeterminada com observação pendente. Uma interface incapaz de representá-las terá removido justamente a cautela que torna a proposta interessante.

Fontes

  1. IETF Datatracker: Agent Infrastructure Control Protocol
  2. Arquivo IETF: draft-paxton-aicp-00
  3. IETF: sobre Internet-Drafts
  4. RFC Editor: como os RFCs são criados
  5. Heng Lu: The Bill of Rights of Uniqueness Coordination