Leonardo Peron5 min de leitura
Um agente que responde produz texto. Alguém lê, decide e age — e se a resposta estiver errada, o pior que acontece é perder tempo. Um agente que executa produz efeito: o registro existe, o status mudou, o e-mail saiu. Dali em diante não há revisão possível, porque o mundo já é outro.
A escada de autonomia está em sugerir ou decidir, e o que o agente tem permissão de fazer está em segurança de agente de IA. Este texto trata do que muda na engenharia da ação depois dessas duas decisões.
Reversível ou confirmada
A pergunta que ordena o resto é por ação: dá para desfazer, e a que custo?
Criar um rascunho é reversível: apaga. Mudar um status é reversível se o histórico guarda o anterior, e deixa de ser no instante em que ele dispara outra coisa — um e-mail, uma fatura, uma reserva de saldo. Mandar mensagem para cliente não é reversível de jeito nenhum: o destinatário leu.
A regra que sai daí é chata e funciona: ação irreversível passa por confirmação; ação reversível pode seguir sozinha. Com uma ressalva: reversibilidade não é teórica, vale dentro da janela em que alguém olharia. Um lançamento estornável até o fechamento só é reversível se a conferência acontecer antes dele.
Vale desconfiar da ação que parece pequena. "Mudar o status para concluído" é uma linha de código e pode disparar uma régua de cobrança, uma pesquisa de satisfação e uma baixa de estoque. O que decide o degrau não é a ação: é o que ela dispara.
O registro precisa dizer quem mandou fazer
Quando uma pessoa altera um cadastro, o sistema grava o nome dela. Quando um agente altera, o padrão preguiçoso é gravar "sistema" — e daí em diante ninguém responde por que aquele campo mudou.
O registro precisa de três nomes, não de um. Quem pediu: a pessoa que conversou, abriu o chamado, mandou a mensagem. O que executou: o agente, identificado, com a versão da instrução que estava valendo. Quem autorizou: a alçada aplicada ou a pessoa que confirmou, quando houve confirmação. Sem o primeiro, uma ação disparada por um pedido mal-intencionado é indistinguível de uma legítima. Sem o terceiro, não existe alçada — existe a aparência dela.
E precisa guardar a intenção, não só o resultado: o que o agente entendeu que deveria fazer, com quais parâmetros. Quando a ação sai errada, interessa saber se ele entendeu errado ou executou errado — são consertos diferentes.
Ele vai tentar duas vezes
Este é o ponto que mais quebra projeto e o menos antecipado, e não é sobre IA: é chamada de rede com um componente não determinístico na frente.
A repetição vem de três lugares. A chamada expira sem resposta e a camada que executa tenta de novo, sem saber se a primeira funcionou. O agente lê o resultado, não reconhece a confirmação e repete por conta própria. E o próprio pedido chega duas vezes: alguém mandou "confirma" duas vezes, o webhook reenviou, alguém liberou o lote à mão.
A defesa é a de qualquer integração, e fica do lado de quem executa, nunca do lado do modelo: cada ação carrega uma chave estável, derivada do caso e não do momento, e a segunda execução com a mesma chave devolve o resultado da primeira em vez de agir de novo. É idempotência, e o desenho completo — inclusive por que verificar antes de inserir tem corrida — está em o mesmo evento duas vezes.
Instruir o modelo a não repetir não resolve: é pedir garantia a quem não pode dar. A chave resolve, e sem depender de comportamento.
A ação que sai pela metade
Um pedido em linguagem natural quase nunca é uma ação: é várias. "Cancela esse pedido e avisa o cliente" são duas escritas em dois sistemas, e não existe transação entre eles. Vai acontecer de a primeira funcionar e a segunda falhar, e a ordem importa: o aviso que saiu antes do cancelamento que não aconteceu é pior que o inverso.
Duas decisões contêm o estrago. A primeira é ordenar por reversibilidade: o que não volta atrás acontece por último. A segunda é que a execução incompleta vire item de fila, com o que já foi feito registrado, em vez de uma exceção que morre no log — a mecânica é a de a fila que ninguém olha.
O que precisa estar arrumado antes
Uma lista fechada de ações. O que não está nela não existe. Ferramenta que aceita comando genérico transforma qualquer erro de leitura em qualquer ação possível.
Pré-condição verificada na hora da execução, não quando o caso entrou na fila. O estado mudou desde então.
Um modo de simulação. Rodar o fluxo inteiro produzindo a lista do que faria, sem fazer. É o que permite medir antes de ligar, e o que a maior parte dos projetos descobre não ter depois de precisar.
O processo desenhado antes. Boa parte do que se pede como agente que executa é automação de processo com regra determinística, e a decisão anterior — ler a tela ou usar a interface do sistema — está em RPA ou integração por API.
A checagem
Liste as ações que o agente pode executar. Para cada uma, escreva em uma linha: o que ela dispara além dela mesma, como se desfaz, em quanto tempo alguém perceberia se saísse errada, e qual chave impede a segunda execução.
A ação sem resposta para a última coluna vai ser executada duas vezes — é questão de volume, não de sorte. E aquela em que "como se desfaz" for "não se desfaz" e "em quanto tempo alguém perceberia" for uma semana está no degrau errado, ainda que nunca tenha dado problema.