O post do Pi Durable, da Earendil (data no cabeçalho: 01 Oct 2026), traz uma frase que todo fluxo de aprovação deveria conseguir dizer: depois de um reinício, o hook encontra a resposta guardada em vez de perguntar de novo (no original, “After a restart, the hook finds the stored answer instead of asking again”). O humano disse sim uma vez. A queda não apagou o sim.
Aí você lê o código de exemplo. O memo da aprovação é tipado como booleano. O código não guarda identidade do aprovador nem horário. A decisão sobrevive ao reinício. Quem decidiu não aparece em lugar nenhum.
Este texto trata de um único objeto, a aprovação, e do que ela deveria carregar quando agentes rodam de forma contínua. Três produtos publicados no fim de setembro e no início de outubro de 2026 tratam a aprovação de maneiras diferentes, e o que cada página descreve varia.
O que o Pi Durable guarda
O mecanismo é simples. Segundo o post, um hook pode rodar de novo depois de uma queda, então um hook que toma uma decisão a guarda num memo: um valor pequeno armazenado junto com a tarefa, em que a primeira escrita vence. Um hook que lança erro é reportado e a cadeia continua, “exceto em beforeTool, onde um throw bloqueia a chamada”. Assim, uma resposta humana guardada num memo pode travar uma chamada de ferramenta e permanecer depois de uma queda.
O replay segue a mesma lógica. Uma chamada de ferramenta interrompida roda de novo se for seguro; do contrário, o modelo é informado de que ela foi interrompida. Uma ferramenta de deploy não declara replay, então é reportada ao modelo e nunca repetida. É engenharia cuidadosa em torno de um problema difícil: o que fazer com uma ação pela metade.
Dois limites importam para a leitura. A aprovação é um hook de exemplo escrito pelo usuário, com um helper de mentira (stub). Nenhum recurso embutido a oferece. E a página diz com todas as letras: “Pi Durable is experimental, and the API might still change.” Tratamos o caso como um padrão de projeto que vale examinar, e não como recomendação de adoção.
Como padrão, ele é forte em um eixo e silencioso em três. Persiste a resposta. Não persiste quem a deu, quando, nem o que exatamente foi aprovado.
Quem pode conduzir
A pergunta sobre identidade não é abstrata nessa página. Ela diz que “any client can steer a running conversation or queue a follow-up” e que qualquer número de clientes pode se conectar a qualquer conversa do harness. Nem o texto da página nem o código descrevem autenticação, autorização ou identidade para conduzir a conversa.
Coloque os dois fatos lado a lado. Muitos clientes podem se conectar a uma conversa. O memo da aprovação registra um sim. Nada do que está descrito liga esse sim a um daqueles clientes. Quem audita o memo depois de um incidente encontra um valor verdadeiro e nenhum nome.
A página também diz que instalar uma extensão com um nome já instalado a substitui em um único passo, e que uma ferramenta com o mesmo nome em uma extensão posterior substitui a anterior. Ela não descreve assinatura nem verificação de integridade do código instalado. É uma afirmação sobre a página e só sobre ela. A página descreve hooks e extensões separadamente. Se um hook de aprovação for distribuído como extensão, a mesma regra de substituição valeria para ele.
Sobre o lado de persistência dos hooks, veja nosso texto anterior sobre hooks de agente como superfície de persistência. Não o recontamos aqui.
O que as outras duas páginas descrevem
A página Introducing dots, da OpenAI (datada de 29 de setembro de 2026), descreve mais mecanismo de aprovação. Os dots começam com regras embutidas para decidir quando agir sozinhos e quando pedir aprovação. Regras Personalizadas (Custom Rules) permitem autorizar ações específicas, exigir aprovação ou bloqueá-las. Requisitos de segurança embutidos sempre se aplicam. O conteúdo das regras embutidas não é mostrado.
A página acrescenta que os dots usam auto-review para checar ações que possam afetar suas contas ou compartilhar informação, contra suas instruções, as Custom Rules e os requisitos de segurança, e que, se o sistema de monitoramento detectar uma preocupação de segurança, ele pode pausar ou interromper o trabalho do dot. Também avisa: os dots ainda podem errar, então revise sempre o trabalho consequente. A página descreve uma Activity View. Ela não diz se essa visão registra o aprovador. Lemos só a página, então não afirmamos nada sobre como o auto-review decide, nem sobre o que a Activity View guarda.
Um item de identidade aparece. Os dots especialistas têm identidade própria para gestão de acesso e hardware provisionado pela TI, e a página os chama de prévia dos dots especialistas, começando com pilotos empresariais focados. É identidade do agente. A pergunta deste texto é a identidade do humano que aprovou.
A página do Cloudflare OS gerenciado (Phillip Jones, data de metadados 2026-10-01) lista três controles: o domínio personalizado, as políticas do Cloudflare Access aplicáveis e qual AI Gateway conectar, além de Gatekeepers por serviço. A mesma página diz que o OS pode enviar e-mails e fazer push para o GitHub. Ela não descreve etapa de aprovação, log de auditoria nem isolamento entre inquilinos. A implantação gerenciada é uma lista de espera. Lemos uma página, então só podemos dizer o que ela descreve. Sobre como os conectores definem o alcance de um agente, veja o conector como raio de explosão.
Por que um booleano é um registro fraco
Um sim à prova de queda responde a uma pergunta: um humano aprovou isto? Três perguntas vêm depois em qualquer revisão, e um booleano não responde a nenhuma.
Quem aprovou? Sem nome, uma aprovação não pode ser atribuída, contestada nem revogada. Quando aprovou? Sem horário, um sim dado antes de uma mudança de política fica idêntico a um sim dado depois. O que aprovou? Sem os argumentos, um sim guardado para “deploy” pode ser lido como cobertura de um deploy que o humano nunca viu.
A última merece uma leitura concreta. No exemplo do Pi Durable, o memo fica guardado junto com a tarefa e a primeira escrita vence. O texto da página que lemos não esclarece como a chave do memo se relaciona com a chamada específica. Se a chave não estivesse atrelada à chamada, um true puro voltaria para qualquer chamada que o hook estivesse avaliando. Essa é uma hipótese nossa. A página não documenta esse comportamento. Descrevemos um possível risco do padrão como mostrado. O código é um exemplo e o helper é um stub, então não há defeito de produto em circulação a apontar. Um time que copiar o exemplo precisaria verificar como a chave é delimitada.
Para a versão do lado do fornecedor, veja a lacuna de auditoria da sessão do fornecedor.
Nossa proposta: um registro de aprovação com três campos
Esta parte é nossa. Nenhuma das três páginas descreve um registro de aprovação com esses três campos.
Uma aprovação deve ser gravada como registro, e não como flag. No mínimo:
- Aprovador: a identidade autenticada da pessoa ou do serviço que deu a resposta. O cliente que por acaso estava conectado não serve.
- Horário: quando a resposta foi dada, em formato comparável com as mudanças de política.
- Argumentos: o nome exato da ferramenta e os argumentos a que a resposta se aplica, para que um hook repetido compare o que vai executar com o que foi aprovado.
Com esses três, um reinício pode repetir a decisão e se recusar a reutilizá-la para outra chamada. Um auditor lê o mesmo registro sem reconstruir a intenção a partir de logs. No nosso desenho, acrescentar campos a um memo é uma mudança pequena. O difícil é o primeiro: um campo de aprovador só tem sentido se conduzir a conversa for um ato autenticado, e a página do Pi Durable não descreve identidade para isso. O registro precisaria dessa base por baixo.
O mesmo formato vale para aprovações do lado do fornecedor. Se Custom Rules podem exigir aprovação, quem compra deve perguntar onde a resposta fica guardada e quais campos ela carrega. Se um OS gerenciado pode enviar e-mail e fazer push para o GitHub, quem compra deve perguntar onde fica registrada a aprovação de um envio específico, já que a página não descreve nenhuma.
Faça isto agora
Escolha um fluxo de agente na sua própria stack que já tenha aprovação humana. Descubra onde a resposta é guardada. Anote o que esse armazenamento contém: só o valor, ou também quem, quando e para quais argumentos. Se for só o valor, acrescente os três campos antes da próxima vez que alguém disser que o fluxo é auditado. Depois faça a cada fornecedor que você usa as mesmas três perguntas e arquive as respostas junto do contrato.
Fontes
- Earendil. “Pi Durable.” Outubro de 2026.
- OpenAI. “Introducing dots.” Setembro de 2026.
- Cloudflare Blog. “Cloudflare OS: your company’s agent workspace, managed for you.” Outubro de 2026.
A Victorino ajuda times de engenharia a desenhar registros de aprovação que nomeiam o aprovador, o horário e os argumentos antes de agentes rodarem sem supervisão: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa