Quando usar agente de IA: o teste dos 3 minutos

Metade dos "projetos de IA" que eu revisei em 2026 se resolviam com um if e um SELECT. A outra metade virou agente porque o time queria dizer que tinha IA.

Não é uma piada de LinkedIn. É o padrão. Chega uma demanda, alguém fala "isso é caso de agente", e seis semanas depois existe um orquestrador com quatro tools, um vector store, um loop de reflexão e um bug que ninguém consegue reproduzir. O problema original era classificar ticket em seis filas. Ninguém parou três minutos pra perguntar quando usar agente de IA de verdade e quando qualquer outra coisa resolvia.

Este post é o freio de mão. Quatro perguntas, três minutos, e no fim você sabe se o que está na sua frente pede um if, uma query, um prompt, um fluxo determinístico ou um agente de verdade. Com cinco casos reais e o veredito de cada um.

TL;DR

• O que é: um teste de 4 perguntas pra decidir o menor mecanismo que resolve o problema, antes de escrever a primeira linha.
• A escada: if → query → prompt → fluxo determinístico → agente. Você desce um degrau só quando o de cima falha.
• A regra da casa (e da Anthropic): "recomendamos encontrar a solução mais simples possível, e só aumentar a complexidade quando necessário" (Building effective agents).
• O placar: de 5 casos reais que chegaram rotulados como "agente", 1 era agente.
• O custo de errar pra cima: Gartner projeta que mais de 40% dos projetos de agentic AI serão cancelados até o fim de 2027 por custo, valor de negócio indefinido ou controle de risco insuficiente.

Quando usar agente de IA: as 4 perguntas do teste dos 3 minutos

Quatro perguntas. Cerca de 45 segundos cada. Se você levou mais de três minutos, você não está testando o problema: está construindo argumento pra justificar o que já queria fazer.

Você responde na ordem. O primeiro sim encerra o teste e define o mecanismo. Não continue descendo por curiosidade.

P1 — A regra cabe num if?

Pergunta operacional: o critério de decisão é enumerável, estável e escrito em algum lugar?

Se as condições estão num contrato, numa política interna, numa tabela de faixas ou numa regra fiscal, elas são determinísticas por definição. Cobrança após 5 dias de atraso. Frete grátis acima de R$ 199. Bloqueio de conta com 3 chargebacks. Isso não é "decisão complexa": é regra de negócio, e regra de negócio auditável tem que morar em código que você consegue ler numa PR.

Se a resposta é sim, acabou. Um if bem nomeado com teste unitário é mais confiável, mais barato e mais rápido de mudar que qualquer prompt.

P2 — A resposta já está no seu banco?

Se o que o usuário quer é recuperação ou agregação de dado estruturado que você já tem, o mecanismo é uma query.

"Quanto vendemos por região no último trimestre" não é um problema de IA. É um GROUP BY. O que costuma acontecer é o time confundir a pergunta em linguagem natural com a resposta: a parte difícil é gerar o número, e o número está no Postgres. A linguagem natural, se for mesmo necessária, é uma casca fina por cima — e uma casca fina não justifica um agente.

Se a resposta é sim, acabou. Query, cache e um endpoint.

P3 — É uma transformação de linguagem, uma vez só?

Classificar. Extrair. Resumir. Reescrever. Traduzir. Comparar dois textos.

Se a tarefa é pegar um texto ambíguo, produzir uma saída e pronto, você precisa de uma chamada de LLM com schema fechado. Não de um agente. A própria Anthropic é explícita: "para muitas aplicações, otimizar chamadas únicas de LLM com retrieval e exemplos in-context costuma ser suficiente".

Uma chamada. Entrada, saída, fim. Se o resultado vem torto, o problema quase sempre é engenharia de contexto, não falta de autonomia. E se o que te assusta é o modelo devolver JSON quebrado, esse medo tem solução conhecida: structured output com schema, não parser defensivo.

Se a resposta é sim, acabou. Um prompt versionado, com eval, e você dorme à noite.

P4 — O caminho muda em runtime?

Essa é a pergunta que separa fluxo de agente, e é a única que importa de verdade.

Pega um papel. Tenta desenhar o grafo inteiro de execução antes de rodar: passo 1, passo 2, esse ramo aqui se a nota for baixa, esse outro se o cliente for enterprise. Conseguiu desenhar tudo? Então é um fluxo determinístico. LLM pode estar em três caixinhas do grafo, e ainda assim é um fluxo — porque quem decide a ordem é o seu código.

Só é agente quando o próximo passo depende do que o modelo descobriu no passo anterior, e você não consegue enumerar as trajetórias de antemão. É a definição operacional da Anthropic: "workflows são sistemas onde LLMs e ferramentas são orquestrados por caminhos de código predefinidos; agentes são sistemas onde LLMs dirigem dinamicamente seus próprios processos e uso de ferramentas".

E tem um segundo filtro colado nesse, que quase todo mundo pula: você consegue verificar automaticamente se deu certo? Agente sem sinal de verificação não é autonomia, é aposta com o dinheiro da empresa. Se não existe teste, checagem de invariante, confirmação de API ou humano no loop capaz de dizer "esse resultado está certo", você não tem um agente — tem um gerador de trabalho pra outra pessoa.

O teste é só o filtro de entrada; depois que o problema passa nele de verdade, começa a parte difícil, que é tool calling, structured output, roteamento, memória, grounding, tracing, evals e a conta de custo fechando. É essa lista que a gente abre ao vivo no AI Engineering Lab 3ª Edição, dias 19 e 20 de setembro, das 9h às 13h, online: dois dias de arquitetura de agente com o erro aparecendo na tela e sendo debugado na hora.

if vs. query vs. prompt vs. fluxo vs. agente

A escada, com o critério de corte de cada degrau:

Repara na última coluna. Ela é o preço real, e não aparece na estimativa de ninguém. É ela que decide a disputa de automação determinística vs. agente de IA na prática, não a elegância da arquitetura.

Um if tem dois caminhos. Você testa em cinco minutos e nunca mais pensa nisso.

Um agente tem espaço de trajetória. Você não testa "o resultado": você testa o comportamento sob variação, o que exige dataset de casos, rubrica, judge, trace por execução e um teto de gasto. Isso não é frescura de engenheiro chato — é o que separa um agente que roda em produção de uma demo que impressionou na reunião de terça.

E tem o meio-termo que quase ninguém considera: o fluxo determinístico com LLM dentro. Você fixa a ordem dos passos em código e usa o modelo só onde tem ambiguidade de linguagem. Aí, se em algum ponto o fluxo precisa escolher entre três caminhos, isso vira um problema de classificação de intenção com política de fallback explícita — que é um degrau inteiro mais barato e mais auditável que entregar a decisão pro loop.

5 casos reais e o veredito de cada um

Todos chegaram rotulados como "agente". Nomes trocados, escopos preservados.

Caso 1 — "Agente de triagem de tickets"

O pedido: classificar o ticket de suporte em uma de seis filas e atribuir prioridade.

O teste: P1 não (o critério é o conteúdo em texto livre, não uma regra). P2 não. P3 sim — é transformação de linguagem, uma vez só, com saída fechada.

Veredito: uma chamada de LLM com schema. Sem loop, sem tool, sem memória.

// 1 chamada. Enum fechado com 6 filas + "indefinido" como saída de escape.
$saida = $llm->structured(
    schema: TriagemSchema::class,   // fila: enum, prioridade: enum, confianca: float
    system: $this->politicaDeFilas, // a política, versionada, não improvisada no prompt
    input : $ticket->corpo,
);

if ($saida->confianca < 0.7 || $saida->fila === 'indefinido') {
    return $this->paraFilaHumana($ticket);  // fallback explícito, não silencioso
}

$ticket->update(['fila' => $saida->fila, 'prioridade' => $saida->prioridade]);

Repara no if da linha do fallback. É ele que faz o sistema ser operável: você tem um número (confianca) e uma rota de escape declarada. Aquele mesmo número vira a métrica que decide, meses depois, se isso um dia precisa virar outra coisa.

Caso 2 — "Agente de relatório mensal"

O pedido: um resumo mensal de vendas na caixa de entrada da diretoria, "com IA analisando os dados".

O teste: P1 não. P2 sim — todo número pedido estava em três tabelas do banco.

Veredito: query + template. O único pedaço que sobrou pra IA foi o parágrafo de leitura em prosa no topo do e-mail, e mesmo esse recebe os números já calculados pelo SQL, prontos, no prompt. O modelo redige; ele não conta.

Essa separação não é preciosismo. Modelo de linguagem errando aritmética em relatório de diretoria é o jeito mais rápido de queimar a credibilidade de IA dentro da empresa por dois anos. Deixa a soma com o Postgres.

Caso 3 — "Agente de cobrança"

O pedido: decidir quem cobrar, quando cobrar e por qual canal.

O teste: P1 sim, na primeira pergunta. As regras estavam escritas no contrato do cliente: faixas de atraso, canais permitidos, janelas de horário, exceções por tipo de plano.

Veredito: if + cron. E aqui o argumento nem é de custo, é de risco. Cobrança tem consequência jurídica e precisa ser reproduzível: alguém, um dia, vai perguntar por que aquele cliente recebeu aquela mensagem naquele dia. "O modelo decidiu" não é uma resposta que sobrevive a uma auditoria.

Regra com efeito legal mora em código determinístico. Sempre.

Caso 4 — "Agente de onboarding"

O pedido: responder dúvidas de funcionário novo sobre o manual interno, as políticas de RH e o processo de reembolso.

O teste: P1 não. P2 não (a resposta está em PDF, não em tabela). P3 quase, mas o conteúdo não cabe no prompt. P4 não — o grafo cabe no papel: recuperar trechos → montar contexto → responder citando a fonte → se não achou, dizer que não achou.

Veredito: fluxo determinístico de três passos, com RAG. Três passos fixos. Zero autonomia. E o ganho real aqui não é "inteligência": é grounding, que é o que corta alucinação de verdade obrigando a resposta a citar o documento de origem.

Antes de assumir que precisa de RAG, aliás, vale passar pelo critério entre fine-tuning, RAG e prompt — o degrau errado nessa escolha também custa semanas.

Caso 5 — "Agente de reembolso" (esse passou)

O pedido: resolver pedidos de reembolso ponta a ponta. Ler a solicitação, consultar a política aplicável, checar o histórico do pedido, verificar se o produto voltou, decidir, executar o estorno e comunicar o cliente.

O teste: P1 não (existe política, mas ela tem exceções que dependem de contexto: atraso da transportadora, recorrência do cliente, estado do item). P2 não. P3 não (são vários passos com estado). P4 sim — a ordem das checagens depende do que aparece: se o rastreio mostra extravio, o caminho é um; se o produto foi entregue e recusado, é outro; se o cliente já teve dois reembolsos no trimestre, é outro. E, crucialmente, dá pra verificar: o estorno acontece ou não, o valor bate ou não, a política citada existe ou não.

Veredito: é agente mesmo. Um de cinco.

E é aqui que a conversa fica adulta, porque agente não é o fim do trabalho, é o começo. Se você chegou nesse degrau, vale revisitar a definição honesta do que é um agente de IA — modelo, ferramentas, memória e orquestração, os quatro blocos — e depois decidir quanto da stack (LangGraph, Mem0, LangChain, MCP) você realmente precisa, que costuma ser bem menos do que o Twitter sugere.

O custo de errar pra cima (e por que ninguém mede)

A pergunta de quando não usar IA custa caro justamente porque é assimétrica.

Errar pra baixo é visível. Você entrega uma regra burra, o usuário reclama na primeira semana, você corrige. Dói rápido e barato.

Errar pra cima é invisível. O agente funciona. Ele demonstra bem. Ele impressiona na sprint review. E o custo aparece devagar, em quatro camadas que ninguém colocou na estimativa:

Latência. Um if responde em microssegundos. Um agente encadeia chamadas sequenciais, e o p95 não é a soma das médias — é a soma das caudas. A Anthropic escreve isso sem rodeio: "sistemas agênticos frequentemente trocam latência e custo por melhor performance na tarefa, e você deveria considerar quando essa troca faz sentido".

Custo por execução. O loop reenvia o histórico a cada passo. O que era uma chamada vira oito, e cada uma carrega o contexto acumulado das anteriores. É por isso que a conta de token de agente não cresce linear com o uso — e por que a fatura real merece ser aberta camada por camada antes de virar surpresa no fim do mês.

Superfície de operação. Tracing por execução. Dataset de casos. Eval com rubrica. Guardrail de gasto. Política de retry idempotente. Fallback humano. Nada disso é opcional em produção, e nada disso apareceu no card do Jira que dizia "criar agente de X".

Custo de mudança. Esse é o pior. Mudar um if é uma PR de três linhas com teste. Mudar o comportamento de um agente é mexer em prompt, reavaliar o dataset inteiro, descobrir que a mudança melhorou dois casos e quebrou outros cinco, e negociar qual regressão é aceitável. Você trocou "editar uma regra" por "renegociar um comportamento estatístico".

Ninguém mede porque não existe alerta pra isso. Não tem métrica de "complexidade desnecessária" no Datadog. O sintoma agregado aparece longe: a Gartner estima que só cerca de 130 dos milhares de fornecedores que se dizem agênticos são reais, e chama o resto de agent washing — rebranding de assistente, RPA e chatbot sem capacidade agêntica de fato. Do lado de quem compra, o relatório do MIT NANDA sobre o estado da IA nas empresas em 2025 encontrou cerca de 95% das organizações sem retorno de negócio mensurável, apesar de dezenas de bilhões investidos.

Não leia isso como "IA não funciona". Leia como o que é: a maior parte do dinheiro foi gasta um ou dois degraus abaixo do necessário na escada.

O que fazer quando a pressão vem de cima

Nada disso resolve o problema político. Você faz o teste, dá if, e o diretor quer poder dizer que a empresa tem IA. Isso é real e não adianta fingir que não é.

Três movimentos que funcionam melhor que discurso técnico.

1. Não brigue com a palavra. Brigue com o escopo.

Discutir se "isso é agente ou não" é uma briga de nomenclatura que você não ganha e não precisa ganhar. Entregue o resultado que foi pedido, no menor mecanismo que resolve, e deixe a área de negócio chamar do que quiser. Se dizer "assistente inteligente de triagem" compra três semanas de paz e evita seis de overengineering, é um bom negócio.

2. Entregue a versão determinística primeiro, instrumentada.

Uma sprint, não seis semanas. Determinístico, com fallback explícito e log de tudo que ele não conseguiu resolver. Isso te dá duas coisas ao mesmo tempo: valor em produção agora, e o dado que vai decidir o próximo passo — em vez de opinião.

-- A métrica que decide se um dia isso vira agente.
-- Fallback alto e subindo = o grafo fixo não cobre mais a realidade.
SELECT
    date_trunc('week', criado_em)                                        AS semana,
    count(*)                                                             AS total,
    count(*) FILTER (WHERE resultado = 'fallback_humano')                AS caiu_pra_humano,
    round(100.0 * count(*) FILTER (WHERE resultado = 'fallback_humano')
                / nullif(count(*), 0), 1)                                AS pct_fallback
FROM execucoes_triagem
WHERE criado_em > now() - interval '90 days'
GROUP BY 1
ORDER BY 1 DESC;

3. Escreva a linha de corte antes, não depois.

Registre num ADR, na wiki, no README, onde for — mas por escrito, com número e data. Algo assim:

## ADR-014: triagem de tickets sem agente

Decisão: 1 chamada de LLM com schema fechado + fallback humano.
Alternativa descartada: agente com tools de CRM e busca.

Vira agente quando (qualquer um):
- pct_fallback > 20% por 3 semanas seguidas; OU
- o fluxo passar a exigir ação em sistema externo cujo caminho
  não dá pra enumerar (ex.: abrir exceção de política caso a caso).

Revisão: 01/12/2026.

Isso muda a natureza da conversa. Você deixa de ser "o dev que não quer fazer IA" e passa a ser quem definiu o critério objetivo de quando fazer. É a mesma lógica de escolher paradigma de trabalho por contexto em vez de por moda, que já destrinchamos na tabela de decisão entre agentic code, vibe coding e SDD.

Ah, e um alerta de bom senso: nada disso vale como desculpa pra não aprender. O motivo pra não construir agente aqui é que este problema não pede. Quando aparecer o problema que pede — e ele aparece — você precisa saber construir. São duas competências diferentes: saber decidir e saber executar. Faltar qualquer uma custa caro.

FAQ rápido

Se eu já tenho o agente pronto, jogo fora?

Não necessariamente. Mede primeiro: latência p95, custo por execução resolvida e taxa de acerto contra um dataset de casos reais. Depois compara com a versão determinística equivalente. Se o agente não ganha em nenhuma das três, o refactor pra fluxo fixo costuma se pagar em um trimestre — e você reaproveita os prompts e as tools.

Onde entra o "fluxo determinístico com LLM"? Isso não é meio-agente?

Não. A diferença é quem decide a ordem. No fluxo, é o seu código: o grafo está escrito e você consegue desenhá-lo antes de rodar. No agente, é o modelo, em runtime. Um fluxo pode ter cinco chamadas de LLM e continuar sendo determinístico do ponto de vista de controle.

Meu problema tem entrada em texto livre. Isso já não obriga a usar agente?

Não. Texto livre obriga a usar LLM, o que é o degrau P3. Entrada ambígua e caminho de execução variável são coisas independentes: dá pra ter linguagem natural na entrada e um grafo totalmente fixo depois dela. É exatamente o caso da triagem de tickets.

Como eu explico esse teste pro time sem parecer o chato do "não"?

Inverte o enquadramento. Não é "vamos evitar IA": é "vamos gastar o orçamento de complexidade onde ele rende". Todo time tem um teto de complexidade que consegue operar bem. Queimar esse teto num problema que era if significa não ter fôlego pro problema que era mesmo agente.

Conclusão

Quatro perguntas. if, query, prompt, fluxo, agente. O primeiro sim encerra.

De cinco casos que chegaram com a palavra "agente" no título do card, um era agente. Essa proporção não é anedota minha — é a mesma direção que Gartner e MIT apontam com amostra grande: dinheiro gasto um ou dois degraus abaixo do necessário.

O sinal de maturidade em engenharia de IA não é conseguir construir um agente. Qualquer um monta um loop com tools num fim de semana. O sinal é olhar um problema e conseguir dizer, em três minutos e sem se enganar, que ele não precisa de um.

E quando precisar — porque vai precisar — você já sabe onde procurar o próximo passo: o que é de fato um agente de IA e, na hora de escrever o código, qual paradigma de trabalho cabe no seu contexto.