Como a aprovação de agentes de IA vira controle real

Um agente com acesso de gravação deve conquistar aprovação para um efeito específico, não receber uma bênção para um plano geral. O ponto de controle útil fica depois que o agente resolveu sua intenção em alvos e parâmetros exatos, mas antes que o primeiro sistema externo aceite uma alteração. Qualquer ponto anterior pede que uma pessoa aprove uma suposição. Qualquer ponto posterior transforma a aprovação em análise de incidente.

Isso parece simples até uma tarefa se expandir para quarenta chamadas de API, o estado de produção mudar enquanto a caixa de aprovação está aberta ou a suposta reversão não conseguir recriar o que foi sobrescrito. Um controle significativo precisa de quatro propriedades: o revisor vê o efeito proposto, a ação aprovada não pode mudar em silêncio, o sistema registra o que aconteceu e o operador tem um caminho de recuperação testado. Alguns efeitos não passam nesse teste e devem continuar manuais.

Trato o acesso de gravação como uma coleção de capacidades estreitas, não como uma única permissão. Criar um registro de rascunho e publicá-lo são capacidades diferentes. Preparar uma migração de banco de dados e aplicá-la também. Quando esses limites existem, a etapa de aprovação protege a operação que traz consequências sem interromper cada cálculo inofensivo.

Coloque a aprovação junto ao efeito

A barreira de aprovação fica imediatamente antes do componente capaz de confirmar a gravação. Deixe o agente ler, raciocinar, calcular um patch, executar validações e produzir um resultado de simulação sem interrupção. Pare quando ele pedir à camada confiável de execução que transforme essa proposta em um efeito externo. O executor, não o modelo, deve impor essa parada.

Aprovar no momento do prompt é cedo demais. Um pedido como «limpe registros duplicados de clientes» não diz quais registros serão unidos, quais valores vencerão nem quantas referências posteriores serão movidas. A aprovação depois da escolha da ferramenta ainda costuma vir cedo, pois os argumentos podem conter uma consulta ampla. A pessoa precisa ver o conjunto resolvido de alvos e o efeito sobre cada um.

A barreira também precisa estar dentro do limite de autorização. Se o agente pode chamar diretamente a API de produção e uma interface separada apenas pede consentimento, a caixa de diálogo é teatro. Dê ao agente credenciais que preparem uma ação e exija que o executor troque um token de aprovação pela capacidade mais forte e de curta duração usada para confirmá-la. Vincule o token ao digest da carga canônica da ação. Uma mudança de alvo, parâmetro ou precondição gera outro digest e exige nova aprovação.

Para um lote, aprove o lote delimitado em vez de um objetivo vago. Mostre a contagem, enumere os alvos quando a lista for razoavelmente pequena e ofereça um anexo legível por máquina quando ela for grande. Defina em política um máximo de itens e um custo máximo. Se a descoberta encontrar mais trabalho que o aprovado, o executor deve parar em vez de tratar a resposta anterior como permissão para continuar.

O teste prático é direto: depois de clicar em Aprovar, o revisor consegue dizer exatamente qual sistema vai mudar, quais objetos serão alterados e qual invariante ainda deve valer? Se alguma parte continuar desconhecida, a proposta não está pronta para aprovação.

Mostre ao revisor a ação resolvida

O revisor deve ver uma representação orientada ao efeito, gerada a partir da mesma carga canônica que o executor consumirá. Não peça que ele interprete raciocínio interno, uma transcrição de chat ou uma promessa escrita pelo modelo. Esses materiais podem dar contexto, mas não são o contrato. O contrato é a ação normalizada.

Para uma alteração de arquivo, mostre repositório, revisão, caminhos, diff, arquivos gerados e verificações executadas. Para SQL, mostre a identidade do banco, a instrução ou o digest da migração, o modo de transação, a estimativa de linhas afetadas obtida de um plano seguro e as implicações de bloqueio que puder determinar. Para uma mensagem, mostre destinatários, conteúdo visível, anexos e se o envio pode acionar outro sistema. Para infraestrutura em nuvem, apresente o plano de recursos e identifique substituições ou exclusões separadamente.

A tela de aprovação deve responder a quatro perguntas sem exigir expansão:

• Qual estado exato vai mudar?
• Por que o agente escolheu esses alvos?
• Quais verificações passaram e quais não foram executadas?
• Qual operação de recuperação existe se o resultado estiver errado?

Mantenha a explicação do agente separada dos fatos medidos por ferramentas. «A suíte de testes passou» deve vir do executor de testes com status de saída e digest do artefato. «Esta alteração tem baixo risco» é uma avaliação, e a interface deve rotulá-la assim. Já vi revisores confiarem em explicações fluentes enquanto ignoravam uma opção destrutiva nos argumentos reais. Coloque os argumentos primeiro.

A aprovação também precisa ter prazo. Inclua a revisão base, a versão do registro, ETag, versão do esquema ou outra precondição que prove que o mundo revisado ainda existe. Um patch de arquivo de dez minutos atrás pode continuar seguro com uma verificação limpa de revisão. Uma decisão de dez minutos atrás para cancelar um pagamento ou rotacionar um segredo de produção talvez já esteja vencida. A expiração deve seguir a operação, não um cronômetro universal.

Não deixe o agente aprovar sua própria representação. Construa a visão em código confiável a partir de um esquema de ação tipado, escape texto não confiável e torne visíveis os campos omitidos. Um campo de destinatário vazio deve aparecer vazio, não sumir do cartão. Valores padrão ocultos continuam sendo parâmetros e pertencem ao digest da carga.

Classifique as ações antes de automatizá-las

Uma política útil classifica operações por consequência e reversibilidade antes que algum agente as solicite. O modelo pode sugerir uma classe, mas código confiável associa um tipo de ação registrado à sua política. Caso contrário, uma descrição persuasiva pode rebaixar uma operação perigosa.

Uso quatro classes práticas. Trabalho somente de leitura não precisa de aprovação, exceto quando a própria leitura expõe dados muito restritos. Gravações em rascunho podem rodar automaticamente dentro de um espaço isolado. Gravações externas reversíveis precisam de aprovação na confirmação. Operações irreversíveis ou que alteram autoridade continuam manuais e muitas vezes exigem uma segunda pessoa no sistema que as cerca.

Uma política compacta pode ser assim:

actions:
  repo.patch:
    mode: approve_at_commit
    require: [base_revision, diff_digest, test_run_id]
    expires_in: 30m
    rollback: revert_commit
  customer.merge:
    mode: approve_at_commit
    require: [source_ids, winner_id, snapshot_id]
    max_targets: 20
    expires_in: 5m
    rollback: restore_snapshot
  signing_key.destroy:
    mode: human_only
  audit_log.delete:
    mode: forbidden

A distinção entre human_only e forbidden importa. Uma pessoa pode destruir uma chave de assinatura aposentada pelo console de gestão de chaves após o procedimento normal da organização. Nem o agente nem seu executor devem possuir essa capacidade. Excluir o registro de auditoria que explicaria o comportamento do próprio agente não tem lugar legítimo neste caminho de automação, mesmo que uma pessoa clique em um botão.

Mantenha várias outras operações fora da execução autônoma: desativar os controles que supervisionam o agente, ampliar as permissões do próprio agente, mudar a política de aprovação, apagar backups, remover a última cópia de recuperação e enviar um compromisso jurídico ou financeiro irrevogável. A lista exata depende do negócio, mas o padrão é estável. Um agente não deve alterar as evidências, a autoridade ou os mecanismos de recuperação que o restringem.

Algumas equipes argumentam que uma segunda aprovação torna qualquer ação segura. Não torna. Duas pessoas podem aprovar uma solicitação ilegível e ambas podem perder o mesmo valor padrão oculto. Vários aprovadores ajudam na separação de funções, mas não consertam um contrato de ação ruim.

Registre a ação como um envelope verificável

Registre um envelope durável para cada ação proposta e acrescente transições de estado à medida que ela passa pela aprovação e execução. Uma transcrição de chat pode servir como evidência complementar, mas é um registro de auditoria ruim: mistura deliberação com instruções, pode omitir padrões das ferramentas e raramente prova quais bytes chegaram ao sistema de destino.

O controle AU-3 do NIST SP 800-53 diz que os registros de auditoria devem estabelecer o que ocorreu, quando, onde, a origem, o resultado e a identidade associada ao evento. É um bom mínimo, mas o executor de um agente precisa de mais porque a proposta e o efeito confirmado podem divergir. Registre intenção e resultado observado, ligados por identificadores estáveis.

Este é o formato que espero de um evento de execução:

{
  "action_id": "act_01J...",
  "run_id": "run_01J...",
  "action_type": "repo.patch",
  "actor": {"agent_id": "migration-agent", "model_release": "approved-release"},
  "requester": {"user_id": "u_1842", "session_id": "s_9031"},
  "target": {"repository": "billing", "base_revision": "4b2c..."},
  "intent_digest": "sha256:9f3a...",
  "policy": {"version": "2026-08-14.3", "decision": "approval_required"},
  "approval": {"approver_id": "u_771", "payload_digest": "sha256:9f3a...", "at": "2026-08-14T09:31:22Z"},
  "execution": {"started_at": "2026-08-14T09:31:24Z", "executor_id": "exec-prod-2", "attempt": 1},
  "result": {"status": "committed", "revision": "51ad...", "changed_files": 7},
  "recovery": {"kind": "revert_commit", "handle": "51ad..."}
}

O evento real também deve incluir os parâmetros canônicos ou uma referência resistente a alterações, versões das ferramentas e conectores, entradas da política, resultados das precondições, artefatos de validação, códigos de erro e o recibo ou identificador da solicitação no sistema de destino. Registre as tentativas separadamente. Se um timeout de rede deixar o resultado desconhecido, escreva unknown, faça a conciliação com o destino e não repita às cegas uma operação não idempotente.

Proteja o registro do ator que ele registra. O NIST AU-9 trata da proteção de informações e ferramentas de auditoria. Na prática, a credencial de gravação do agente não pode editar nem excluir sua trilha de auditoria. Envie os eventos a um armazenamento orientado a anexação, com administração restrita, regras de retenção, sincronização de relógio e verificações de integridade. Remova os segredos antes de armazenar, mas não transforme remoção em omissão: registre que um campo sensível existia e guarde um digest com chave ou referência protegida quando uma investigação puder precisar da correlação.

A reversibilidade deve ser projetada por operação

Uma alteração só é reversível se você puder nomear a operação inversa, preservar os dados de que ela precisa e demonstrar que a inversão ainda funciona depois da ação inicial. Um sinalizador genérico «desfazer disponível» não prova nada. Sistemas diferentes precisam de projetos de recuperação diferentes.

O controle de versão oferece um commit de reversão, mas reverter uma implantação talvez não reverta uma gravação no banco já feita pelo código lançado. Uma transação de banco permite rollback limpo apenas até o commit. Depois dele, a restauração pode exigir uma transação compensatória ou recuperação pontual, e ambas podem sobrescrever trabalho legítimo que chegou mais tarde. Um e-mail enviado não pode ser retirado dos sistemas que já o receberam. Uma correção é compensação, não reversão.

Antes da aprovação, o contrato da ação deve nomear um destes modos de recuperação:

• Rollback de transação, quando o sistema pode abortar antes de expor a alteração.
• Restauração de versão, quando o objeto anterior e sua versão permanecem disponíveis.
• Ação compensatória, quando um evento novo compensa semanticamente o primeiro.
• Reparo para a frente, quando operadores implantam uma correção porque o rollback danificaria o estado mais recente.
• Sem reversão, o que eleva a classe de aprovação ou mantém a ação manual.

Capture o estado anterior de forma seletiva. Um snapshot dos registros afetados pode tornar recuperável uma união de clientes, mas copiar todo um banco restrito para o espaço de trabalho do agente cria um problema pior. Mantenha snapshots no sistema protegido de recuperação do destino, criptografe-os sob acesso separado, aplique retenção e coloque somente o identificador de recuperação no registro da ação.

Teste a recuperação com a mesma seriedade do caminho de ida. Para cada ação de gravação registrada, passe uma massa de teste por preparação, aprovação, confirmação e recuperação, depois compare. Verifique efeitos em filas, caches, índices de busca, webhooks e livros contábeis posteriores. Se o teste verificar apenas a tabela principal, ele só prova que a tabela principal pode ser restaurada.

Idempotência é relacionada, mas diferente. Uma chave de idempotência impede que uma repetição aplique a mesma operação lógica duas vezes. Ela não reverte uma operação ruim. Use as duas coisas: IDs de ação estáveis para repetição segura e identificadores explícitos de recuperação para correção.

Uma aprovação desatualizada viola a precondição

Uma aprovação autoriza uma carga contra um estado conhecido. Se um dos dois mudar, o executor deve rejeitá-la e pedir uma proposta nova. É o controle de concorrência otimista aplicado ao julgamento humano, e fecha uma lacuna que muitos fluxos de aprovação deixam aberta.

Vincule ações em arquivos a um hash de commit, atualizações de API a um ETag ou versão de registro, trabalho de banco a uma versão de esquema e predicado limitado, e planos de infraestrutura ao digest do plano mais a série de estado do provedor, quando disponível. Avalie as precondições dentro do executor imediatamente antes do commit. Não deixe o agente apenas declarar que as verificou antes.

Falha parcial de lote exige uma regra explícita. Lotes atômicos devem reverter todos os itens quando um falhar. Lotes não atômicos devem registrar um resultado para cada alvo e parar quando o limite de erros aprovado for ultrapassado. A interface precisa dizer ao revisor qual comportamento se aplica. Continuar silenciosamente depois de várias falhas transforma uma aprovação delimitada em experimento na produção.

Trabalhos longos devem separar a aprovação do plano da aprovação de cada fase perigosa. Uma pessoa pode aprovar a geração de mil alterações candidatas em uma branch isolada. A promoção ainda exige uma nova barreira baseada no diff final e na revisão base atual. Reutilizar a aprovação do planejamento para implantação combina duas decisões diferentes.

Tokens de aprovação devem ter uso único. Se a execução falhar antes do commit, o sistema pode emitir uma nova solicitação que referencia a ação anterior e mostra o que mudou. Reutilizar o mesmo token depois de uma resposta ambígua pode duplicar um efeito ou aplicar uma decisão antiga a um estado novo.

Dê ao executor menos autoridade que produção

O executor confiável deve possuir apenas as capacidades registradas na política de ações, não uma credencial geral de administrador de produção. Tirar a chave de gravação do processo do agente resolve pouco se o executor puder transformar qualquer texto produzido pelo modelo em uma chamada de API, comando de shell ou instrução SQL arbitrária. O limite exige operações tipadas e validação estrita de parâmetros.

Crie um adaptador por tipo de ação. Um adaptador de status do cliente pode aceitar ID do cliente, versão esperada do registro e um valor de uma enumeração pequena. Não deve aceitar URL bruta, cabeçalhos arbitrários nem consulta livre. Um adaptador de repositório pode aplicar um patch validado a um único repositório nomeado sem oferecer um shell. Isso dá mais trabalho que expor um conector genérico, e é o trabalho que torna a aprovação significativa.

Restrinja o executor no destino e também no código da aplicação. Dê à identidade do banco permissão para chamar procedimentos armazenados aprovados, não para gravar em todas as tabelas. Limite funções de nuvem a classes de recursos nomeadas e operações permitidas. Restrinja credenciais de repositório por organização e repositório. Use política de rede para impedir que um adaptador alcance serviços não relacionados mesmo quando um parâmetro malformado tenta redirecioná-lo.

Trate a saída de ferramentas como entrada não confiável. Uma descrição de incidente, comentário no código, valor de banco ou resposta web pode conter texto que tenta influenciar o agente. Isso costuma ser discutido como injeção de prompt, mas a consequência para o controle é simples: conteúdo lido de um destino nunca vira autoridade para gravar nele. Apenas a política e um token de aprovação válido concedem autoridade. O executor analisa campos tipados e rejeita instruções escondidas em campos de dados.

Segredos exigem tratamento igualmente estreito. O modelo raramente precisa ver uma credencial. Deixe o executor resolver uma referência depois da aprovação, usá-la em uma única operação registrada e manter o valor fora de prompts, prévias, erros e registros. Quando um destino exigir um segredo estático poderoso, coloque um intermediário que emita uma credencial de curta duração e escopo específico. Se o destino não aceitar esse escopo, classifique o adaptador pelo poder total da credencial, não pela intenção modesta da solicitação atual.

O agente também não pode registrar um novo tipo de ação durante a execução. Código de adaptadores, esquemas, representações, manipuladores de recuperação e associações de política pertencem ao plano de controle revisado. Atualizá-los é uma entrega de software com processo humano próprio. Caso contrário, o agente pode contornar uma operação proibida inventando um nome mais amigável e encaminhando a mesma chamada destrutiva por ele.

Por fim, separe a identidade de execução da identidade do aprovador. O sistema de destino deve registrar que o executor fez a gravação em nome de um solicitante identificado e sob uma aprovação identificada, sem se passar pelo revisor. Isso preserva a responsabilidade sem ensinar às pessoas que aprovar significa emprestar ao agente toda a sua sessão.

Meça se as pessoas conseguem decidir

A qualidade da aprovação pode ser observada. Se quase toda solicitação é aprovada em poucos segundos, o fluxo talvez contenha ruído de baixo risco ou os revisores podem estar clicando sem ler. Se eles abrem registros brutos repetidamente para entender uma proposta, falta informação na representação principal. Se propostas vencidas são reaprovadas sem inspeção, a atualidade virou apenas mais um botão incômodo.

Colete medidas de processo sem avaliar funcionários individuais pela velocidade. Sinais úteis incluem tempo até a decisão por classe de ação, motivos de rejeição, solicitações devolvidas por falta de contexto, cargas alteradas após rejeição, falhas de precondição desatualizada, uso do caminho de emergência e recuperações executadas. Compare os sinais por tipo de ação e versão da interface. Uma taxa global de aprovação esconde o adaptador problemático.

Peça motivos estruturados de rejeição e ofereça texto livre opcional. Mantenha a lista curta: alvo errado, escopo inesperado, evidência insuficiente, momento inseguro, recuperação pouco confiável e conflito de política cobrem a maioria das decisões técnicas. Leve esses motivos de volta ao esquema e à representação. Se alvo errado for frequente, mova identidade e ambiente para o topo do cartão. Se recuperação pouco confiável se repetir, pare de chamar a ação de reversível até seu manipulador passar por um exercício.

Filas precisam de dono e escalonamento. Uma solicitação enviada a um canal amplo dilui a responsabilidade; todos presumem que alguém mais próximo do sistema fará a análise. Encaminhe por sistema e classe de ação a um pequeno grupo de plantão, mostre quem assumiu a revisão e libere-a se ficar inativa. O solicitante deve ver que a proposta está esperando, mas não pode pressionar a interface a escolher uma aprovação padrão.

Projete o diálogo para a recusa. O controle Rejeitar deve estar tão disponível quanto Aprovar, e fechar a janela não pode contar como consentimento. Não deixe aprovação pré-selecionada, não use pressão de contagem regressiva nem esconda detalhes destrutivos em painéis recolhidos. Para diffs complexos, permita busca e filtro mantendo o resumo canônico e o digest visíveis. Acessibilidade faz parte do controle de segurança, porque um revisor que não consegue operar a comparação não consegue inspecionar a ação.

Separe uma amostra de ações aprovadas para revisão independente. Compare a proposta apresentada, a carga canônica, o recibo do destino e o resultado observado. Isso pode revelar campos ambíguos, adaptadores que acrescentam padrões no destino e revisores designados fora de sua competência. Use os achados para mudar política ou interface, não apenas para lembrar as pessoas de tomar cuidado.

Fadiga de aprovação geralmente é falha de classificação. Mova ações previsíveis e de baixa consequência para uma política automática estreita, com limites e monitoramento. Combine alterações relacionadas em um lote delimitado quando uma decisão realmente cobrir todas. Mantenha barreiras individuais onde o contexto humano pode mudar o resultado. Poucas decisões sérias recebem mais atenção que um fluxo de solicitações cerimoniais.

Reescritas de legado precisam de evidência de paridade

Em uma reescrita de legado, a aprovação deve ficar na promoção de uma mudança de comportamento verificada, não em cada arquivo gerado. Agentes precisam de espaço para inspecionar toda a árvore de fontes, mapear dependências, gerar código de destino e rodar testes isoladamente. O momento de consequência chega quando o novo serviço, cliente, esquema ou núcleo numérico pode alcançar tráfego ou dados de produção.

Um diff de código sozinho é evidência fraca nessa situação. Revisores precisam da revisão de origem, revisão de destino gerada, decisões de arquitetura com efeito operacional, mudanças de esquema e resultados de paridade contra o comportamento de produção registrado. Também precisam de uma lista clara de diferenças intencionais. Uma compilação verde diz que o código novo compila. Não diz que um cálculo de fechamento mensal reescrito concorda com o programa que sustenta o negócio há anos.

CodeHero lê toda a base de código em várias linguagens e verifica o comportamento reescrito com uma estrutura de paridade contra o tráfego de produção registrado. Essa evidência deve aparecer junto à solicitação de promoção, sem permitir que qualquer divergência se esconda num resumo. Em ambientes regulados, seus modelos podem rodar sem conexão dentro do perímetro do cliente, mas os controles de aprovação e auditoria do cliente ainda decidem quem promove o resultado.

Trate a migração de dados como uma ação de gravação própria. Aprove a versão exata do esquema, o digest da transformação, o escopo de linhas, consultas de validação, precondições de virada e ponto de recuperação. A aprovação de uma promoção de código não pode autorizar silenciosamente uma carga retroativa, e a aprovação dessa carga não pode autorizar a exclusão do armazenamento antigo. Essas operações têm modos de falha e prazos de recuperação diferentes.

A mesma separação vale para modernizar a arquitetura. Um agente pode propor dividir um monólito ou substituir um arquivo compartilhado por Postgres, mas a aprovação deve cobrir consequências observáveis: mudanças de roteamento, propriedade dos dados, comportamento concorrente e reversão operacional. Caso contrário, o revisor aprova um rótulo de projeto em vez de um efeito no sistema.

Teste o controle tentando contorná-lo

Um sistema de aprovação só está pronto depois que testes provam que o agente não pode encontrar um caminho por fora. Uma caixa de diálogo bem-sucedida no caso esperado mostra que a interface funciona. Não mostra que toda gravação em produção passa pelo executor nem que o token está vinculado à carga exibida.

Execute casos adversários contra o controle:

1. Altere um parâmetro depois da aprovação e confirme que a verificação do digest rejeita a execução.
2. Mude a versão do destino enquanto a caixa está aberta e confirme que a precondição falha.
3. Reutilize um token de aprovação e confirme que o executor rejeita o segundo uso.
4. Remova um campo obrigatório e confirme que a representação mostra um erro em vez de aplicar um padrão.
5. Negue a aprovação e confirme que o agente não pode chamar o conector por outra credencial ou ferramenta.

Acrescente exercícios de recuperação, não apenas testes unitários. Escolha uma ação segura semelhante à produção, execute-a, invoque o identificador de recuperação registrado e verifique o estado posterior. Meça se operadores conseguem encontrar a ação pelo ID, identificar o aprovador, reconstruir a carga exibida e dizer se a recuperação terminou. Um controle que só existe em documentação falhará justamente quando o sistema estiver sob pressão.

Revise taxas de aprovação e exceções em busca de problemas de projeto. Aprovação quase universal pode significar que as solicitações são rotineiras o bastante para uma política automática mais estreita, ou que os revisores pararam de ler. Rejeições frequentes por falta de contexto apontam para esquema de ação ou representação deficientes. Não resolva fadiga treinando pessoas a clicar mais rápido. Remova barreiras de pouca consequência e melhore as restantes.

O acesso de emergência deve deixar mais evidências

O acesso de emergência pode encurtar o caminho de aprovação, mas nunca deve apagar identidade, escopo ou registro de auditoria. Defina-o antes de um incidente: quem pode invocá-lo, quais ações permite, por quanto tempo a capacidade dura e quem revisa seu uso depois. Uma credencial administrativa vaga de «quebrar o vidro», compartilhada por uma equipe, é um desvio sem atribuição.

Use uma solicitação autenticada individualmente, uma capacidade estreita e temporária, um motivo registrado antes da execução e notificação imediata a alguém diferente do solicitante. Preserve a mesma carga canônica da ação e o mesmo envelope de resultado do funcionamento normal. Se a urgência tornar impossível a aprovação prévia, exija revisão retrospectiva rápida, mas não finja que essa revisão foi autorização. Dê o nome certo.

O sistema deve negar gravações perigosas quando o serviço de aprovação estiver indisponível. Leitura e preparação isolada podem continuar. Propostas enfileiradas podem esperar. Permitir que o agente confirme porque o plano de controle caiu torna o controle menos eficaz durante uma interrupção, exatamente quando os operadores têm menos atenção disponível.

Aprovação significativa é deliberadamente estreita: um ator conhecido, uma ação canônica, um estado atual, um efeito delimitado e um resultado registrado. Coloque esse contrato no executor, mantenha autoridade e evidências fora do alcance do agente e recuse automação quando não existir um caminho honesto de recuperação.