Como Garantir que Agentes de IA Funcionem de Verdade em Produção

Vinoth Govindarajan, engenheiro do OpenAI especializado em infraestrutura de dados, traz uma perspectiva importante: agentes de IA não falham só porque o modelo tem alucinações. Os maiores problemas em produção vêm de questões muito mais fundamentais, de design de sistema.

O Problema Real: Sucesso Silencioso

Imagine isto: um usuário pede ao assistente para lembrar de um reembolso de cliente. O sistema responde que vai guardar essa informação. Tudo parece estar funcionando. Mas nos bastidores, o registro nunca foi salvo na memória do agente.

Esta é a falha mais perigosa que existe. Um crash deixa claro que algo deu errado. Um "sucesso silencioso" é uma mentira: a interface diz que funcionou, o usuário vê uma resposta, mas o sistema esqueceu. Quando o agente precisa dessa informação depois, vai trabalhar com dados incompletos e confiante demais.

O Modelo da Harness: Controle em Torno da IA

Pense em um carro. O motor importa, mas ninguém compra apenas vendo cavalos de potência. Você se importa com a direção, freios, painel, caixa de câmbio. Agentes de IA são iguais. O modelo é o motor. Mas a "harness" — o sistema ao redor do modelo — é o que dá controle.

O contrato de produção é simples:

• O modelo propõe
• A harness compromete
• Um comprovante prova que aconteceu

O modelo pode sugerir uma chamada de ferramenta, uma mensagem, um comando. Mas não deve ser a fronteira de produção. A harness é quem decide se a proposta vale, se a mudança é ordenada, se a autoridade é válida, se o resultado pode ser provado.

Três Princípios Que Importam

1. Dona do Estado

Cada fato que o agente vai usar depois precisa de um dono e um caminho de recuperação. Não é um dono humano — é o sistema cuja memória persistente vira a verdade para o próximo turno.

Por exemplo:

• Um evento de calendário pertence ao sistema de calendário
• O status de um ticket pertence ao sistema de ticketing
• Uma preferência do usuário pertence à memória
• Uma volta de conversa pertence ao log de transcrição

Se o agente depende de um fato depois, você deve ser capaz de recuperar ele. Se o caminho de upload falha silenciosamente, o próximo turno pode parecer coerente mas estar errado.

Há um padrão clássico: o sistema mostra como "entregue" e continua atualizando o timestamp. A próxima vez que acorda, vê trabalho pendente e pula. A harness nem percebe que é apenas um sinal interno de liveliness que virou trabalho visível ao usuário.

A lição: nomeie o dono de cada fato e torne a recuperação possível.

2. Ordene as Mudanças

Concorrência é boa. Interleaving acidental não é.

Dois cenários diferentes carregam o mesmo estado, modificam coisas diferentes, salvam. Nenhum dos dois está errado. Mas como não há serialização ao redor do ciclo ler-modificar-salvar, a última gravação apaga a primeira mudança.

O padrão correto:

• Serialize escritas do mesmo processo com filas
• Proteja escritas entre processos com locks

Não estamos falando de zero concorrência — isso seria muito lento. Você pode:

• Paralelizar leituras
• Rodar subtarefas em paralelo
• Deixar ferramentas buscar evidência independente de forma paralela
• Rodar muitas sessões ao mesmo tempo

O invariante é estreito mas crítico: um caminho ordenado de commit por estado mutável.

Isso importa porque a experiência do usuário é um reflexo da ordem. Se a ordenação está quebrada, o agente parece esquecido. Se as lanes ficam presas, o agente parece morto. Se a conclusão é tratada como log em vez de entrega, o agente parece confuso.

3. Limite o Trabalho

Em produção, silêncio não pode ser neutro. Nenhuma chamada de ferramenta, lane, carregador ou stream tem tempo infinito.

Um exemplo: o log tem uma chamada de ferramenta, mas nunca chegou o resultado dela. O processo pode ter sido morto, a conexão caiu, o timeout disparou antes do retorno. Para o usuário, o assistente está lento ou travado. Para o sistema, não há evento terminal para seguir em frente.

Cada limite precisa de um fim: sucesso, falha, timeout, máximo de tentativas.

• Lease dá prazos a execuções e ferramentas
• Watchdog transforma trabalho travado em falha visível do agente
• Interrupt dá ao usuário ou operador um caminho de recuperação fora do loop travado
• Receipt registra um estado terminal, então o próximo passo não tem que adivinhar

Em demos, a API retorna, o navegador responde, o stream termina. Em produção, alguma fronteira fica quieta. A harness deve dar ao modelo um evento terminal claro para raciocinar sobre.

Quando Chat Vira Ação: Autoridade

Aprovar não é clicar um botão. É um objeto com escopo.

O modelo pode solicitar uma chamada de ferramenta. Mas não deve ser a fronteira. A harness decide se a solicitação é permitida e pode virar realidade. A fronteira é: quem está agindo, sob qual escopo, com quais argumentos, por quanto tempo, com qual prova?

Aprovação precisa de forma:

• Ator
• Sessão
• Ferramentas
• Argumentos
• Tempo de vida
• Resultado

Se algum desses cai durante transporte, a harness não sabe mais o que foi realmente aprovado.

Há um segundo padrão: capacidade desabilitada que ainda está registrada como ativa. A superfície de política diz "não permitido", mas a superfície de runtime ainda a oferece ao modelo. Significa que o modelo pode ver e solicitar algo que o operador pensava ter desabilitado.

O padrão correto: identidade do solicitante, capacidade e autoridade de execução precisam convergir antes do modelo ver o prompt. Senão, política é só decoração, não é uma fronteira.

Se você quer auto-aprovação para tudo, rode tudo dentro de um sandbox. Depois disso, é execução segura. O resultado fica registrado no comprovante.

A lição: o modelo pode solicitar, mas a harness decide. Privilégio mínimo estreita a superfície de ferramentas. Credenciais com escopo garantem que a identidade certa é usada na ação. Aprovação e auditoria decidem o que acontece antes e depois.

Prova: O Sucesso Visível Importa

Mesmo se a ferramenta diz sucesso, a borda visível ao usuário pode discordar. Um testa código, um comprovante prova a realidade.

Há um exemplo nítido: ferramenta reporta sucesso, usuário não vê nada renderizado. A mensagem da ferramenta dizia "envio bem-sucedido". Os metadados mostravam entrega ao cliente WebChat ou TUI. Mas o usuário não viu a mensagem. Isso não é um pequeno desvio — é falha de produção pura.

Por isso, prova deve atravessar a borda visível ao usuário. O agente em produção não precisa apenas de uma transcrição. Precisa de evidência — o mesmo limite que o usuário vê cruzado.

No Dia a Dia

Estes princípios vêm de bugs reais em sistemas como OpenClaw. Não são novos para engenheiros de sistemas distribuídos — já conhecem idempotência, retries, locks, ordem. O que muda é onde a falha senta com agentes. O modelo escolhe ferramentas dinamicamente, ao redor de um planejador probabilístico. O contexto pode ser reconstruído diferente a cada turno. Eventos chegam de usuários, timers, webhooks, sub-agentes ao mesmo tempo.

As falhas são familiares. O cenário do agente as torna mais fácil de disparar e mais duro de explicar. A harness transforma preocupações confiáveis conhecidas em limites explícitos ao redor do comportamento não determinístico.

O grande insight: hoje que X pode virar ação, não é mais só "o modelo respondeu corretamente?" A pergunta muda para três questões de produção:

• Quem dono do estado? Qual pipeline de memória ou workflow é o dono?
• Quem ordenou? Qual deles registrou primeiro — transcrição, sessão, memória, record de workflow?
• Quem pode provar? Não o que o modelo pretendeu, não o que disse. O que a borda visível persistiu.

Estas não são perguntas de modelo. São perguntas de produção.