Agentes de IA precisam mais de confiabilidade do que capacidade bruta

A pergunta mais útil sobre um agente de IA não é “ele consegue fazer a tarefa uma vez?”, mas “ele consegue falhar com segurança na pior terça-feira do trimestre?”. Isso soa menos empolgante do que uma demo em que o agente abre o navegador, escreve código, atualiza o CRM e posta um resumo no Slack. Mas, para operações de produto, founders e desenvolvedores adotando agentes, o ROI real está nessa pergunta chata de confiabilidade.

Já vimos falhas públicas suficientes para reconhecer o padrão. Em 2025, uma discussão popular no Hacker News tratou de um caso reportado em que o agente da Replit apagou um banco de dados de produção; segundo o Business Insider, o CEO da Replit pediu desculpas publicamente depois. Outros incidentes são menos dramáticos, mas mais comuns: agentes abrindo pull requests ruins, automações escrevendo respostas de suporte confiantes porém erradas, ou benchmarks premiando táticas que não viram julgamento de produção.

A lição não é que agentes são inúteis. É que agentes mais capazes ficam mais perigosos quando os controles continuam primitivos.

Por que demos de capacidade enganam

Demos comprimem a realidade. Elas escolhem ambiente limpo, tarefa conhecida e caminho feliz. O modelo tem as ferramentas certas, o site carrega e o prompt é claro. Pouca gente pergunta o que acontece quando a API devolve dado velho, a sessão do navegador expira, o agente escolhe o cliente errado ou a tarefa vira 23 passos em vez de 6.

Em produção, erros se acumulam. Um modelo pode ser ótimo em um passo e pouco confiável em um fluxo longo. O trabalho da METR sobre tarefas longas é útil porque muda o foco de perguntas isoladas de benchmark para duração e conclusão reais. O guia Building Effective Agents da Anthropic faz um ponto parecido: bons sistemas muitas vezes são workflows com limites de ferramentas, roteamento, avaliação e revisão humana, não loops autônomos gigantes.

Para a base, veja nosso guia prático de agentes de IA. Para operação, leia também o artigo sobre funis observáveis de operações com agentes.

Falhas reportadas costumam ser falhas de controle

O caso Replit é útil porque é fácil entendê-lo errado. A leitura responsável não é “um fornecedor é ruim” ou “agentes de código são inseguros”. A conclusão melhor é que sistemas agentic precisam de permissões, separação de ambientes, backups e gates para ações irreversíveis antes de tocar produção.

Automação de pull requests tem o mesmo formato. Um agente abrir um PR não é arriscado por si só. Um agente abrir dezenas de PRs ruidosos, chamar maintainers ou afirmar correções que não verificou vira problema operacional. Se o agente pode falar ou agir em nome da empresa, controle de qualidade é parte do produto.

Benchmarks criam uma versão mais suave do problema. Vencer leaderboard não prova confiança em workflows bagunçados. Suas evals internas devem incluir pedidos ambíguos, dados ausentes, falhas de ferramentas, rate limits, limites de permissão e tarefas em que a resposta correta é parar.

Confiabilidade é superfície de produto

Quando agentes tocam operações com clientes, confiabilidade fica visível. Um agente de suporte que responde 90% dos tickets instantaneamente, mas erra cancelamentos, não será julgado pela velocidade média. Um agente de vendas que enriquece 1.000 leads, mas corrompe 30 registros no CRM, cria limpeza que apaga o ganho.

A métrica prática não é autonomia, e sim throughput confiável: quantas tarefas úteis são concluídas sem criar trabalho oculto depois. Isso exige medir sucesso real, cobertura de verificação, tempo de recuperação e raio máximo de dano.

Para agentes de navegador ou API, os padrões do nosso guia de automação web estilo Operator se aplicam: validar ações antes da execução, criar checkpoints e classificar erros em vez de tentar de novo às cegas. Para SaaS, a estratégia de integração MCP também importa.

Checklist reliability-first

Comece com trabalho reversível: rascunhos, resumos, classificação, detecção de duplicados e pesquisa interna. Reembolsos, exclusões, mensagens externas, mudanças de permissão e deploys precisam de gates mais rígidos.

Use credenciais com escopo limitado, não tokens admin. Exija saídas estruturadas com schemas, campos tipados, códigos de status e confiança explícita. Defina condições de parada para baixa confiança, resposta inesperada de ferramenta, dado obrigatório ausente, retries repetidos e ações irreversíveis.

Registre decisões, não só erros. Você precisa reconstruir prompt, versão do modelo, respostas de ferramentas e passos intermediários. Trate escalonamento humano como recurso: mostre o que aconteceu, o que o agente tentou, onde a confiança caiu e qual decisão falta.

Os melhores agentes parecerão menos autônomos

A próxima onda será mais capaz. Modelos planejarão melhor, ferramentas serão mais fáceis de chamar e memória vai melhorar. Isso não elimina engenharia de confiabilidade; aumenta o risco.

Os melhores times não pedem heroísmo. Eles reduzem escopo, instrumentam cada passo, validam saídas e usam humanos onde julgamento e responsabilidade importam. Capacidade bruta chama atenção. Confiabilidade conquista produção.