Agentes de IA: onde ajudam e onde atrapalham

Construí um "agente" que era um script com passos a mais

Fui montar um agente para classificar tickets de suporte. A versão ambiciosa tinha um loop: o modelo decidia ler o ticket, buscar no histórico, consultar uma base, decidir a categoria e, se não tivesse certeza, recomeçar. Ficou impressionante na demo e instável em produção — às vezes entrava em loops de duas, três iterações desnecessárias, custando token e latência, para chegar onde uma única chamada chegaria. Reescrevi como um script determinístico com exatamente uma chamada ao modelo no fim. Mesma acurácia, metade do custo, zero surpresa. Foi aí que entendi que "agente" virou uma palavra que esconde mais do que explica.

A ideia aqui é dar critérios práticos para decidir quando um agente vale a pena e quando ele só adiciona risco. Como boa parte do que torna um agente útil depende de recuperar a informação certa, leia junto o texto sobre o que são embeddings.

O que é um agente, de verdade

Tirando o marketing, um agente é três coisas: um LLM, um conjunto de ferramentas (tools) que ele pode chamar, e um loop que deixa ele decidir qual ferramenta usar e quando parar. É isso. O modelo recebe um objetivo, escolhe uma ação, vê o resultado, escolhe a próxima, e repete até concluir ou desistir.

A palavra-chave nessa definição é loop. Sem o loop, você tem só uma chamada de LLM com tool use — útil, previsível, barata. Com o loop, você entrega autonomia: o modelo decide a sequência de passos sozinho. Essa autonomia é exatamente o que dá poder e o que dá problema. Quase toda decisão sobre adotar ou não um agente se resume a: o ganho dessa autonomia compensa a imprevisibilidade que ela traz?

Onde o agente genuinamente ajuda

Existe uma família de tarefas em que o loop vale o custo. O padrão comum é: a tarefa é delimitada e o resultado é verificável.

• Triagem e roteamento. Classificar, etiquetar, encaminhar. O espaço de ações é pequeno e o resultado é checável contra uma taxonomia.
• Geração de código com testes. O agente escreve código, roda a suíte de testes, lê o erro, corrige, repete. Aqui o loop brilha porque cada iteração tem um sinal de verdade objetivo — o teste passa ou não passa. A verificação está embutida.
• Pesquisa com citações. Buscar em várias fontes, sintetizar, e citar de onde veio cada afirmação. O loop permite seguir uma pista, e as citações dão como auditar o resultado.

O fio condutor: em todos esses, existe um critério de parada objetivo e um jeito de verificar que o agente acertou. O loop trabalha contra um sinal real, não contra a opinião do próprio modelo sobre estar pronto.

Onde o agente atrapalha

A simetria é direta: o agente vira problema exatamente quando falta o que torna os casos bons. Quatro padrões para evitar:

Autonomia sem fronteira. "Resolva o problema do cliente" sem delimitar o que ele pode fazer é convite a comportamento errático. Espaço de ação aberto multiplica os caminhos para dar errado.

Ações irreversíveis sem confirmação. Deletar dados, enviar e-mail, fazer cobrança, deploy em produção. Se um passo não tem volta, o agente não pode ser o último a decidir sozinho. O custo de uma alucinação aqui não é um token desperdiçado, é um cliente cobrado errado.

Ausência de verificação. Se não existe teste, citação ou checagem externa para validar o resultado, o agente está se autoavaliando — e o modelo é otimista sobre o próprio trabalho. Sem sinal de verdade, o loop só acumula confiança injustificada.

Empilhamento de latência e custo. Cada iteração é uma chamada de modelo: mais latência, mais token, mais chance de erro composto. Um agente de cinco passos é cinco vezes mais lento e caro que uma chamada — e a cada passo o erro do anterior se propaga. Em volume, isso vira uma conta que ninguém previu na demo.

Human-in-the-loop não é opcional

A ponte entre "ajuda" e "atrapalha" quase sempre é onde está o humano. A regra que eu uso: quanto mais irreversível ou mais aberta a ação, mais cedo o humano precisa entrar.

Na prática isso significa desenhar o agente para propor e pedir aprovação antes de executar o passo crítico, não para executar e avisar depois. Para tarefas reversíveis e verificáveis — classificar, rascunhar, pesquisar — o humano pode ficar no fim, revisando o resultado. Para tarefas irreversíveis, o humano fica no meio, aprovando a ação antes de ela acontecer. Tirar o humano do caminho para "ganhar autonomia" é o ponto em que a maioria dos projetos de agente troca confiabilidade por uma demo bonita.

A opinião impopular: a maioria deveria ser um script

Vou ser direto, porque é a lição que mais me poupou tempo: a maioria das coisas vendidas como "agente" deveria ser um script determinístico com uma única chamada de LLM no ponto onde a linguagem natural realmente precisa de interpretação.

# não é um agente; é um pipeline com uma chamada de LLM onde ela é necessária
def classificar_ticket(ticket: str) -> str:
    contexto = buscar_historico(ticket)        # determinístico
    categoria = llm_classificar(ticket, contexto)  # uma chamada
    if categoria not in CATEGORIAS_VALIDAS:     # verificação
        return "revisao_humana"
    return categoria

Repare no que esse código faz: o fluxo é fixo e legível, a busca é código normal, o LLM entra só onde precisa interpretar texto livre, e há uma verificação explícita com fallback para o humano. Você ganha quase todo o valor do "agente" sem a imprevisibilidade do loop. A pergunta que separa os dois é honesta: o seu problema realmente exige que o modelo decida a sequência de passos? Se a sequência é conhecida, escreva a sequência. Reserve o loop para quando o caminho de verdade não pode ser previsto de antemão.

Perguntas frequentes

Qual a diferença entre um agente e uma chamada de LLM com tools?

A chamada com tools é o modelo escolhendo uma ação dentro de um fluxo que você controla. O agente adiciona um loop em que o próprio modelo decide a sequência de ações e quando parar. A diferença é quem controla o fluxo: você ou o modelo. Essa autonomia é o que dá poder e também o que traz imprevisibilidade.

Quando vale a pena usar um agente de verdade?

Quando a tarefa é delimitada e o resultado é verificável por um sinal objetivo: geração de código contra testes, pesquisa com citações auditáveis, triagem contra uma taxonomia fechada. Se existe um critério de parada claro e um jeito de checar o acerto sem confiar só na opinião do modelo, o loop se paga.

Por que agentes ficam caros e lentos?

Porque cada iteração do loop é uma chamada de modelo, com sua latência e seu consumo de token. Um agente de cinco passos é grosseiramente cinco vezes mais caro e lento que uma chamada única, e o erro de um passo se propaga para os seguintes. Em produção, sob volume, esse empilhamento vira um custo que a demo não revela.

Posso deixar um agente executar ações irreversíveis sozinho?

Não sem confirmação humana. Para qualquer ação sem volta — deletar, cobrar, enviar, fazer deploy — o agente deve propor e esperar aprovação, não executar e avisar depois. O custo de uma decisão errada nesses casos não é token desperdiçado, é dano real, e o modelo é confiante demais sobre o próprio trabalho para ser o juiz final.

O que levar disso

Agente é LLM mais ferramentas mais um loop, e o loop é tanto o poder quanto o risco. Ele ajuda quando a tarefa é delimitada e o resultado é verificável — código com testes, pesquisa com citações, triagem contra taxonomia. Atrapalha quando há autonomia aberta, ações irreversíveis sem confirmação, ou nenhuma verificação. Mantenha o humano no caminho na proporção da irreversibilidade. E, antes de construir um agente, faça a pergunta honesta: o problema exige que o modelo decida os passos, ou é um script com uma chamada de LLM disfarçado de coisa mais sofisticada?