Seu agente de IA diz que a ferramenta falhou. E se a ação realmente aconteceu?
Curadoria, tradução e análise: Redação Triplo Hub.
Uma chamada de ferramenta retornando um erro não significa necessariamente que a ação falhou.
Isso parece óbvio se você passou um tempo em torno de sistemas distribuídos.
Fica muito mais perigoso quando um agente de IA é a coisa que decide o que fazer a seguir.
Imagine isto:
- Um agente decide fazer um pagamento.
- O pedido de pagamento chega ao provedor.
- O provedor cria o pagamento.
- O tempo de resposta expira.
- O agente recebe um erro.
Do ponto de vista do agente:
PAGAMENTO FALHOU
Do ponto de vista do provedor:
PAGAMENTO ACONTECEU
Agora o agente tem que decidir o que fazer a seguir.
Tentar novamente?
Se ele tentar novamente sem pensar, você pode ter agora dois pagamentos.
Esse é o problema que tenho pensado.
A resposta da ferramenta nem sempre é evidência do efeito
Tendemos a colapsar várias coisas em um único evento:
agente chama ferramenta
↓
tool retorna resultado
↓
agente decide o que aconteceu
Mas sistemas consequenciais nem sempre funcionam assim.
A sequência real pode ser:
agente chama ferramenta
↓
provedor aceita pedido
↓
estado do mundo real muda
↓
resposta é perdida
↓
ferramenta relata um erro
A ferramenta pode ser completamente honesta.
O transporte realmente falhou.
Mas o efeito externo também realmente aconteceu.
Ambos os fatos podem ser verdadeiros ao mesmo tempo.
Isso torna a resposta uma evidência útil sobre a chamada, mas não necessariamente uma evidência autoritária sobre o efeito final.
Idempotência ajuda, mas não responde a toda a questão
A resposta óbvia é a idempotência.
E sim, ferramentas consequenciais devem usar idempotência sempre que o sistema subjacente a apoiar.
Se o mesmo pedido de pagamento for repetido com a mesma chave de idempotência, o provedor não deve criar um segundo pagamento.
Isso previne uma classe muito importante de falha.
Mas o agente ainda tem uma pergunta:
A primeira ação realmente aconteceu?
Antes de decidir se deve tentar novamente, escalar, compensar ou parar, algo precisa estabelecer o estado a jusante.
Isso pode significar:
- ler o estado do provedor;
- verificar um recibo de transação;
- consultar o recurso de forma independente;
- observar o efeito colateral físico;
- reconciliar com outro sistema autoritário.
É aqui que eu acho que os testes de agentes precisam ir além de verificar a saída do modelo ou a resposta da ferramenta.
Existem pelo menos três perguntas diferentes
1. A ação foi permitida?
Este é um problema de autorização.
Este agente pode realizar esta ação contra este recurso sob esta política?
2. A evidência por trás da ação ainda é atual?
Este é o problema que o FreshCtx aborda.
Um agente pode tomar uma decisão correta às 10:01.
A realidade muda às 10:03.
A ação é executada às 10:04.
A razão original não era necessariamente ruim. Ela simplesmente não era mais válida quando a execução aconteceu.
O FreshCtx revalida a evidência declarada imediatamente antes da ação consequencial.
Conceitualmente:
ATUAL
→ prosseguir
RAZÃO_OBSOLETA
→ bloquear
INVERIFICÁVEL
→ bloquear sob a política padrão
Esse é intencionalmente um trabalho estreito.
O FreshCtx não afirma que uma ação autorizada será executada corretamente.
E não afirma que uma resposta da ferramenta prova o que aconteceu depois.
3. O que realmente aconteceu?
Este é um problema de garantia diferente.
Uma vez que a ação cruza a fronteira de execução:
- O efeito ocorreu?
- Ocorreu uma vez?
- O agente relatou a mesma coisa que a realidade mostra?
- Podemos estabelecer o resultado de forma independente?
- Se repararmos o problema, o mesmo caminho de execução agora se comporta corretamente?
Eu não queria continuar expandindo o FreshCtx até que se tornasse um sistema de autorização, plataforma de observabilidade, testador de execução e sistema de auditoria ao mesmo tempo.
Então eu separei o problema.
Isso se tornou o Revera
Revera é o sistema que eu construí para o lado de execução desse problema.
A pergunta que ele tenta responder é simples:
O que o agente de IA realmente executou?
O fluxo de trabalho é aproximadamente:
descobrir ação consequencial
↓
reproduzir execução
↓
observar efeito real
↓
diagnosticar
↓
remediar onde suportado
↓
rerun o caminho exato
↓
produzir evidência
Um princípio de design se tornou especialmente importante:
O sistema sob teste não deve ser a única autoridade sobre se sua própria ação teve sucesso.
Se o agente relata:
PAGAMENTO FALHOU
enquanto uma observação independente estabelece:
PAGAMENTO EXECUTADO
Eu quero que ambos os fatos sejam preservados.
Não um substituindo silenciosamente o outro.
O estado desconfortável é às vezes "não sabemos"
Há outro caso que importa tanto quanto.
Suponha:
- a ferramenta retornou um erro;
- o provedor não pode ser consultado atualmente;
- nenhum recibo autoritário está disponível;
- o efeito pode ter acontecido.
Chamar isso de FALHOU é perigoso.
Chamar isso de SUCESSO é igualmente desonesto.
A resposta mais segura pode ser simplesmente:
INVERIFICÁVEL
ou, dependendo do sistema:
PODE_TER_EXECUTADO
Esse estado muda o que o agente pode fazer a seguir.
Tentar automaticamente de forma cega pode ser exatamente a resposta errada.
Por que o reteste exato importa
Há mais um lugar onde eu acho que o trabalho de segurança do agente muitas vezes para cedo demais.
Uma falha é reproduzida.
Alguém gera um patch.
O código parece correto.
E o problema é marcado como corrigido.
Mas:
patch gerado != correção provada
Para um problema de execução consequencial, eu quero que o caminho reparado realmente execute novamente sob as condições de execução relevantes.
Então observe o que aconteceu.
E também verifique se o comportamento legítimo ainda funciona.
É por isso que o Revera inclui uma etapa de reteste exato em vez de tratar a geração de remediação como o fim do fluxo de trabalho.
FreshCtx e Revera resolvem problemas diferentes
A distinção que uso agora é:
FreshCtx
A evidência ainda é atual antes da ação?
Revera
O que realmente executou, que efeito ocorreu, e a reparação pode ser provada?
O FreshCtx permanece como código aberto.
O Revera é o produto de verificação separado.
Acho que manter essa fronteira explícita torna ambos os sistemas mais úteis.
Eu quero testar o Revera em sistemas externos reais, não apenas exemplos que construímos nós mesmos.
O Revera está ao vivo agora:
Neste
O artigo discute a importância de entender a relação entre erros reportados por ferramentas e a realidade das ações executadas por agentes de IA. Para empresas brasileiras, isso destaca a necessidade de sistemas robustos que garantam a verificação e a validação das ações executadas por agentes, evitando falhas financeiras e operacionais.
