Matei um agente em produção semana passada. Substituí por 30 linhas de Python. O script é mais rápido, mais barato, nunca alucina, e durmo melhor. Esta é uma história sobre quando não usar agentes de IA, contada por alguém que os constrói para viver.
O hype dos agentes tem um ponto cego. Todo mundo escreve sobre como construir agentes. Quase ninguém escreve sobre quando um agente é a ferramenta errada — e essa é a habilidade mais útil, porque recorrer a um loop de raciocínio quando você precisava de um loop for é o erro mais caro em todo esse espaço.
O sinal: a tarefa é determinística?
Aqui está meu primeiro filtro. Se o mesmo input sempre deveria produzir o mesmo output, você não quer um agente. Quer código.
Parsear um CSV para JSON. Renomear arquivos por um padrão. Chamar uma API e reformatar a resposta. Validar que cada registro tem um campo de email. Essas são determinísticas. Um agente vai fazê-las, claro, mas lentamente, caro, e com probabilidade não nula de decidir "melhorar" seu schema sem ser pedido. Um script as faz em milissegundos de graça, da mesma forma todas as vezes.
A regra de ouro: agentes são para tarefas onde o caminho é desconhecido. Se você pode escrever os passos, escreva os passos. Não pague um modelo para redescobri-los em cada execução.
Onde os agentes realmente se pagam
Agentes brilham quando a tarefa tem ambiguidade genuína que requer julgamento em tempo de execução. "Olha esse teste falhando, descubra por quê, corrija-o." "Leia este ticket de suporte bagunçado e roteie-o." "Dados esses três enfoques meio quebrados, escolha um e termine." O caminho se ramifica com base no que o agente descobre. Você não pode pré-escrever porque não sabe o que vai encontrar.
Essa é a linha divisória. Caminho desconhecido, julgamento em tempo de execução, input nebuloso. Se sua tarefa tem os três, agente. Se não tem nenhum, script. Os casos interessantes são no meio, e é onde as pessoas erram — elas veem um pouco de ambiguidade e recorrem ao loop de raciocínio completo quando um script com uma única chamada LLM no meio teria bastado.
O híbrido geralmente é a resposta
Meu padrão favorito não é "agente" ou "script". É um script que faz uma chamada de modelo focada onde o julgamento realmente mora.
# Não é um agente. É um pipeline com um cérebro em um ponto.
rows = parse_csv(path) # determinístico
for r in rows:
r["category"] = classify(r) # uma chamada LLM, output estruturado
write_json(rows) # determinístico
A chamada classify faz a parte nebulosa — lendo texto livre e categorizando-o. Tudo ao redor é código normal. Sem loop multi-turno, sem dança de chamadas de ferramenta, sem agente decidindo explorar seu sistema de arquivos. Você obtém o julgamento do modelo exatamente onde precisa e em nenhum lugar que não. Isso é mais barato que um agente em uma ordem de magnitude e você pode realmente testá-lo.
O custo de um loop que você não precisava
Vamos falar de dinheiro, porque as contas são reais. Um agente que faz loops — lê, pensa, chama ferramenta, observa, pensa de novo — reenvia o contexto crescente a cada turno. Uma tarefa que leva oito turnos pode reprocessar toda sua conversa oito vezes. Vi uma tarefa agêntica "simples" queimar mais tokens do que toda a base de código em que estava trabalhando, porque ficava relendo arquivos que já havia lido.
Para uma tarefa determinística, isso é desperdício puro. Você pagou por raciocínio que a tarefa não precisava. Multiplique isso por um cron job rodando de hora em hora e você construiu um incinerador de dinheiro que um comando sed teria substituído.
Latência e confiança, os custos mais silenciosos
Há também o que não aparece na fatura. Agentes são lentos. Um loop de raciocínio com chamadas de ferramenta leva segundos a minutos. Se você colocar isso em um caminho crítico de usuário — digamos, validando uma submissão de formulário — você tornou seu produto parecendo quebrado para economizar escrever uma regex.
E confiança. Um script que está errado está errado previsivelmente; você corrige o bug e está corrigido para sempre. Um agente que está errado está errado criativamente, diferente cada vez, e "consertar" significa ajustar um prompt e rezar. Para qualquer coisa onde a correção é inegociável — movimentação de dinheiro, auth, deleção de dados — quero código que possa ler e um teste que possa executar, não um modelo que só posso empurrar levemente.
Minha checklist real
Antes de deixar uma tarefa ser um agente, ela tem que passar em todos esses:
- O caminho genuinamente varia com base no que encontramos em tempo de execução.
- Um humano precisaria de julgamento, não apenas seguir regras, para fazê-lo.
- O input é suficientemente bagunçado que o código não consegue parseá-lo de forma confiável.
- A estranheza ocasional no output é sobrevivível.
Falha em algum? Provavelmente é um script, ou um script com uma única chamada LLM embutida.
A verdade desconfortável
O impulso de tornar tudo um agente vem em parte de empresas de ferramentas te vendendo agentes. Claro que o framework de agentes quer que cada problema seja um problema de agente. Esse é o modelo de negócio.
Seu trabalho é mais estreito e mais honesto: resolva o problema com o mínimo de maquinaria que funcione. Às vezes é um sistema multi-agente sofisticado. Frequentemente é um arquivo Python que você poderia ter escrito em 2015. O movimento sênior é saber qual, e não ser orgulhoso demais para lançar o chato. Meu script de produção não tem loop de raciocínio. Também não me alertou nem uma vez.