Quando NÃO construir um agente de IA

Índice

Publicado em agosto de 2026.

TL;DR: A maioria das ideias de agente de IA é a ferramenta errada para o trabalho. Antes de escrever qualquer código de agente, verifico cinco sinais desqualificantes — um processo instável, baixa frequência, ausência de teste de aprovação/reprovação, uma ferramenta mais simples que já funciona, ou um modo de falha irreversível que não dá tempo de proteger direito. Se qualquer um deles for verdadeiro, não construo. Em vez disso, desço uma escada de alternativas mais baratas, e só volto a um agente personalizado se nada nessa escada resolver.

[Perspectiva do operador] Gerencio mais de 30 agentes em produção para uma marca de consultoria e para o Pickleland, uma instalação de pickleball em Pflugerville, TX. Já matei pelo menos tantas ideias de agente quanto lancei, e quase nenhuma delas morreu porque a ideia era ruim — morreram porque um agente era a ferramenta errada para aquele trabalho específico. Este post é o filtro que aplico antes de “devo construir isso” virar “como eu construo isso”.

A resposta padrão é não

O framework de ROI que uso diz se uma automação se paga em relação ao custo de construção e manutenção. Essa é a segunda pergunta certa. A primeira pergunta é mais simples e é constantemente pulada: isso realmente precisa ser um agente?

“Agente” virou o rótulo padrão para qualquer coisa que envolva um LLM, da mesma forma que “app” virou o rótulo padrão para qualquer coisa que envolvesse uma tela quinze anos atrás. Nem tudo que toca em um modelo precisa de um sistema autônomo permanente, que chama ferramentas, observa gatilhos e toma ações por conta própria. Boa parte do que as pessoas chamam de “construir um agente” é, na verdade, “escrever um prompt muito bom e rodá-lo manualmente” — e isso não é um modo de falha, é frequentemente o estado final correto.

Trato “construir um agente personalizado” como a opção mais cara em uma escada de opções, não como o primeiro degrau. Antes de recorrer a ela, verifico se a tarefa já se desqualifica sozinha.

Cinco sinais de que um agente é a ferramenta errada

Qualquer um destes, isoladamente, geralmente já é suficiente para me deter.

1. O processo ainda não está estável. Se o fluxo de trabalho mudou duas vezes no último mês porque o próprio negócio ainda está descobrindo o que quer, um agente trava a versão de hoje de um processo que está prestes a mudar de novo. Você vai reescrever o prompt, o schema de ferramentas e o conjunto de avaliação toda vez que o processo mudar — o que significa que você está mantendo um agente em vez de tocar um negócio. Rode manualmente até o processo se estabilizar por um trimestre, depois automatize a versão consolidada.

2. Roda raro demais para se pagar. Uma tarefa que acontece duas vezes por ano não acumula execuções suficientes para justificar tempo de construção, tempo de teste e um conjunto de avaliação, não importa quão bem ela funcionasse depois de pronta. Baixa frequência com alto esforço de construção é praticamente o pior quadrante para automação — você paga o custo total da construção e recolhe quase nenhuma da economia.

3. Você não consegue escrever um teste de aprovação/reprovação para ela. Se você não consegue descrever, de antemão, como é uma saída correta a ponto de verificá-la programaticamente, não consegue construir um ambiente de avaliação para ela — e um agente que você não consegue avaliar é um agente que você está pilotando às cegas. Tarefas que são puro gosto pessoal (“isso soa como eu escreveria”) ou puro julgamento sem um critério consistente por trás continuam manuais, ou continuam revisadas por humanos toda vez, o que anula o propósito de automatizá-las.

4. Uma ferramenta mais simples já faz o trabalho. Antes de dimensionar um agente, pergunte o que uma fórmula de planilha, um fluxo de trabalho no Zapier/Make/n8n com uma única etapa de LLM, ou um prompt salvo já resolveriam. Se a resposta honesta for “90% do caminho”, os últimos 10% raramente justificam montar um agente com infraestrutura, monitoramento e custo de manutenção próprios. Já dimensionei agentes para tarefas que uma visualização filtrada e um lembrete de calendário recorrente teriam resolvido igualmente bem.

5. O modo de falha é irreversível e você não tem tempo de construir a proteção direito. Algumas ações — um envio de e-mail em massa, um reembolso, uma publicação pública — não podem ser desfeitas. Portas de aprovação com humano no circuito existem exatamente para isso, mas uma porta feita às pressas que ninguém de fato revisa é pior do que nenhuma automação: ela cria a aparência de supervisão sem a substância. Se você não tem tempo para construir e manter essa porta corretamente, isso é um sinal para desacelerar, não um motivo para pular a proteção.

Se nenhum dos cinco se aplica — o processo é estável, roda com frequência suficiente, você consegue definir o que é correto, nenhuma ferramenta mais simples cobre o caso, e o modo de falha é reversível ou está devidamente protegido —, vale a pena rodar a matemática de ROI sobre ele.

A escada que desço antes de construir

Quando uma tarefa falha em um dos cinco critérios — ou mesmo antes de eu chegar até lá — desço esta lista em ordem, e paro no primeiro degrau que de fato resolve o problema.

1. Simplesmente pergunte ao modelo diretamente. Sem wrapper, sem chamadas de ferramentas, sem infraestrutura permanente. Abra o Claude, cole o contexto, faça a pergunta, use a resposta. Isso resolve mais tarefas pontuais e ocasionais do que as pessoas esperam, porque o instinto de “agente” aparece até para coisas que só precisam acontecer uma vez.

2. Um prompt salvo ou instruções de projeto. Se o mesmo tipo de pedido surge repetidamente, mas cada instância ainda precisa de um humano para reunir as entradas e revisar a saída, salve o prompt como um modelo — instruções de projeto, um conjunto de instruções personalizadas, um trecho reutilizável — em vez de automatizar o gatilho. Você ganha o benefício da consistência de um agente sem a infraestrutura.

3. Uma ferramenta de automação no-code com uma única etapa de LLM. Para tarefas que realmente precisam de um gatilho (um novo envio de formulário, uma nova linha em uma planilha), mas cuja lógica em si é simples, uma ferramenta de fluxo de trabalho com uma chamada de modelo no meio é drasticamente mais barata de construir e manter do que código personalizado. Recorro a isso antes de infraestrutura personalizada sempre que o gatilho é padrão e o volume é baixo a moderado.

4. Um modelo executado manualmente. Alguns processos se beneficiam mais de uma checklist do que de automação, porque o valor está em um humano pensando em cada etapa, não na velocidade. Não automatize o pensamento em tarefas nas quais o pensamento é o ponto principal.

5. Terceirização. Para qualquer coisa com ambiguidade ou julgamento real, na qual você não tem tempo de construir e manter um conjunto de avaliação, uma pessoa — um assistente virtual, um especialista, um provedor de serviço produtizado — costuma ser mais rápido de colocar em funcionamento e mais fácil de corrigir no meio do caminho do que um agente que você ainda está ajustando.

6. Só então: um agente personalizado. Se você desceu a escada e nada nela resolveu — o gatilho exige julgamento real sob carga, o volume é alto demais para tratamento manual ou terceirizado, e ele passa na matemática de ROI —, é aí que um agente construído sob medida, com sua própria pilha de confiabilidade, justifica seu custo de construção.

O teste sombra de duas semanas

Para qualquer coisa na fronteira — passa nos cinco critérios, mas eu ainda não estou confiante — rodo um teste sombra de duas semanas antes de me comprometer com a construção. Eu mesmo faço a tarefa, usando o modelo como copiloto em vez de um sistema autônomo: o mesmo prompt que eu eventualmente daria ao agente, as mesmas entradas, mas leio toda saída antes que ela vá para qualquer lugar.

Duas coisas saem desse teste. Primeiro, se o modelo é de fato bom na tarefa, no padrão de qualidade que preciso — se estou reescrevendo metade da saída na mão, a tarefa não está pronta para automação, independentemente de tudo o mais. Segundo, um conjunto de avaliação de verdade: duas semanas de entradas e as saídas que julguei corretas são exatamente o que um ambiente de avaliação precisa, e geralmente já coletei isso de graça no momento em que decido construir.

O teste sombra também revela casos extremos antes que eles cheguem à produção. É muito mais barato descobrir em um teste manual que 15% das entradas precisam de tratamento especial do que descobrir isso a partir de uma reclamação de cliente depois que o agente já foi lançado.

Uma regra que aplico depois de matar uma ideia

Matar uma ideia de agente não é o mesmo que matar o problema subjacente. Se uma tarefa se desqualifica por enquanto — o processo ainda está mudando, o volume é baixo demais —, anoto o motivo e defino um ponto aproximado de reavaliação (geralmente ligado a um gatilho específico: “reavaliar quando as reservas passarem de 50/semana”, não apenas uma data). Ideias de agente que são descartadas uma vez e nunca revisitadas silenciosamente viram trabalho manual permanente que ninguém se lembra de ter avaliado duas vezes.

A disciplina inversa importa igualmente: uma ideia que passa nos cinco critérios e na matemática de ROI não é automaticamente construída hoje. Ela entra na mesma fila que tudo o mais, classificada contra as automações que já provaram se pagar. Passar no filtro garante a uma tarefa um lugar na fila, não uma isenção de priorização.

Perguntas frequentes

Isso não é só um argumento contra automação?

Não — é um argumento contra recorrer, por padrão, à forma mais cara de automação. A maioria das alternativas na escada acima ainda é automação; elas só são mais leves. Eu rodo dezenas de agentes em produção. O ponto não é evitar construir; é parar de pular direto para “construir um agente personalizado” quando um prompt salvo ou um fluxo de trabalho no-code entrega o mesmo resultado por uma fração do custo de construção e manutenção.

E se a tarefa claramente for crescer em volume depois?

Esse é um motivo legítimo para construir à frente dos números atuais — cubro essa exceção no framework de ROI. Mas isso não anula os cinco sinais acima. Se o processo ainda está instável ou você ainda não consegue definir uma saída correta, o crescimento do volume só significa que você vai manter um agente quebrado em uma escala maior. Resolva a instabilidade e a testabilidade primeiro; a escala é um motivo para construir mais cedo depois que esses pontos forem resolvidos, não um motivo para pulá-los.

Como sei se uma etapa de ferramenta no-code é “boa o suficiente” versus precisar de código personalizado?

Teste primeiro e meça contra seu conjunto de avaliação, mesmo que informal. Etapas de LLM no-code lidam bem com tarefas de propósito único e entrada única. Elas começam a forçar os limites quando você precisa de uso de ferramentas em várias etapas, estado persistente entre execuções, ou lógica condicional que o construtor da ferramenta não consegue expressar de forma limpa. Se você bater nesse limite, isso é um sinal real para migrar para infraestrutura personalizada — não um motivo para começar por ela.

Isso se aplica de forma diferente a ferramentas internas versus voltadas para o cliente?

Os cinco sinais se aplicam da mesma forma, mas o risco é diferente. Uma ferramenta interna com um processo instável só desperdiça o tempo da sua própria equipe quando quebra. Uma voltada para o cliente com um processo instável corrói a confiança de pessoas que não se inscreveram para ser o seu conjunto de avaliação. Aplico uma versão mais rígida do sinal cinco especificamente a automações voltadas para o cliente — a barra para “devidamente protegido” é mais alta quando é um estranho, não um colega, do outro lado de um erro.

Qual é o motivo mais comum pelo qual você mata uma ideia de agente?

O sinal três — ausência de um teste limpo de aprovação/reprovação. É o mais fácil de passar despercebido durante o dimensionamento, porque a tarefa parece bem definida até você tentar escrever, de antemão, como é de fato uma saída correta. Se eu não consigo fazer isso em uma ou duas frases, sei que o agente vai ser inavaliável, o que significa inaprimorável, o que significa que ele ainda não vai ser construído.