Agentes de IA: Entre o Brinquedo Bonito e o Operador Real de Processo

Neste artigo · 10 seções

1. A demo que enche os olhos e o sistema que entrega valor
2. O que é um agente, sem a parte de marketing
3. Quando agente faz sentido (e quando não faz)
4. Limitando o espaço de decisão
5. Auditoria de planos: o passo que diferencia agente brinquedo de operador real
6. Evitando loops e divagações
7. Observabilidade específica de agente
8. Quando substituir agente por workflow
9. Conclusão
10. Insights & Takeaways

A demo que enche os olhos e o sistema que entrega valor

Tem um padrão claro na adoção de agentes de IA. Aparece uma demo nova: o agente recebe um pedido em linguagem natural, navega na web, executa código, escreve relatórios, faz tudo sozinho. Liderança vê o vídeo, time é cobrado pra "fazer algo parecido", e em poucas semanas alguém montou um agente similar internamente.

Aí o agente vai pra ambiente real. Algumas vezes funciona. Mais vezes, falha de formas inesperadas. Entra em loops chamando a mesma tool dezenas de vezes. Decide caminhos que ninguém previu. Toma decisões com efeito colateral irreversível baseadas em interpretação errada do contexto. Custa muito mais token do que o esperado. E, principalmente, é difícil entender por que ele fez o que fez quando precisa explicar pro usuário ou pro chefe.

A diferença entre uma demo de agente e um agente operando processo real em produção é grande, e quase tudo que separa um do outro é engenharia disciplinada de limites. Esse artigo é sobre essa engenharia: quando agente faz sentido, como restringir o espaço de decisão, como auditar planos, como evitar loops, e quando uma máquina de estados clássica é melhor escolha mesmo se o termo "agente" for menos sexy.

O que é um agente, sem a parte de marketing

Um agente, em termos técnicos, é um sistema onde um modelo de linguagem decide, em loop, qual ação tomar a seguir. A diferença entre uma chamada normal a LLM e um agente é o loop. Numa chamada normal, o modelo gera uma resposta e fim. Num agente, o modelo gera uma ação (chamar uma tool, buscar uma informação, perguntar algo), recebe o resultado, decide a próxima ação, e assim por diante até concluir a tarefa.

Esse loop é o que dá ao agente a capacidade de resolver tarefas complexas que exigem múltiplos passos não-pré-determinados. E é também o que torna o sistema imprevisível, caro e difícil de auditar. Cada iteração custa tokens. Cada decisão tem variabilidade. O caminho do início ao fim pode mudar entre execuções idênticas.

Frameworks como LangGraph, CrewAI, AutoGen, e implementações próprias seguem esse padrão básico, com variações em como gerenciam estado, paralelismo entre múltiplos agentes, e ferramentas disponíveis.

Quando agente faz sentido (e quando não faz)

A pergunta que separa uso adequado de overkill é: o espaço de decisão é grande demais pra enumerar?

Se você consegue desenhar um fluxograma com os possíveis caminhos da tarefa, você não precisa de agente. Precisa de uma máquina de estados, ou de orquestração imperativa, ou de um workflow durável (todos discutidos no artigo de orquestração). Esses padrões são mais previsíveis, mais baratos e mais auditáveis.

Agente faz sentido quando os caminhos possíveis são muitos demais pra mapear, e a sequência ideal de ações depende do que vai sendo descoberto durante a execução. Alguns exemplos:

Pesquisa exploratória. "Encontre informações sobre o cliente X em fontes públicas e gere um relatório." O modelo precisa decidir quais fontes consultar, quais palavras-chave buscar, o que aprofundar com base no que já encontrou. Não dá pra prever o caminho.

Resolução de problemas técnicos. "Investigue por que o serviço Y está lento." O modelo consulta logs, métricas, traces, formulando hipóteses e testando-as conforme descobre. Cada descoberta muda o que faz sentido investigar a seguir.

Tarefas longas com sub-objetivos. "Prepare um pitch deck pra esse cliente." Envolve pesquisa, estruturação, geração de texto, ajuste, revisão. A ordem certa depende do que aparece em cada etapa.

Quando a tarefa é estruturada, os passos são previsíveis, ou o efeito de cada ação é alto demais pra deixar nas mãos de um sistema probabilístico, agente é a escolha errada. Workflow tradicional resolve melhor.

A pergunta honesta que vale fazer: "se eu trocasse esse agente por um workflow de 5 passos com cada passo bem definido, o resultado seria pior?" Se a resposta é "não, seria igual ou melhor", o agente é overengineering.

Limitando o espaço de decisão

Mesmo quando agente faz sentido, deixar o modelo decidir tudo é receita pra problema. O design de um agente sério inclui várias formas de restringir o que ele pode decidir.

Lista limitada de tools. Quanto menos tools disponíveis, melhores as decisões do modelo (mesmo princípio do artigo sobre tools). Um agente com 5 tools bem desenhadas funciona melhor que um agente com 30 tools. A tentação é dar acesso a tudo e deixar o modelo escolher; a realidade é que isso degrada qualidade e infla custo.

Tools com escopo restrito. Cada tool faz uma coisa específica, com validação rigorosa. Tool de escrita só permite criar registros em determinado tipo, com determinados campos. Tool de leitura só retorna campos relevantes pra tarefa. Isso é equivalente ao princípio de menor privilégio, aplicado a IA.

Sub-objetivos explícitos. Em vez de dar ao agente um objetivo grande e abstrato, decomponha em sub-objetivos. "Pesquisar fontes" → "Resumir achados" → "Estruturar relatório" → "Revisar consistência". Cada fase tem ferramentas e critérios próprios. O modelo decide dentro da fase, não entre fases. Isso reduz drasticamente o espaço de decisão sem perder a flexibilidade onde ela importa.

Restrições explícitas no prompt. "Você não deve cancelar pedidos sob nenhuma circunstância." "Apenas use as fontes listadas." "Não tome decisões que afetem mais de 100 registros sem confirmação." O modelo segue essas restrições razoavelmente bem quando estão claras no prompt, especialmente se reforçadas com exemplos.

A lição prática: agente não é "deixe o modelo descobrir". É "deixe o modelo decidir dentro do espaço que você definiu como aceitável".

Auditoria de planos: o passo que diferencia agente brinquedo de operador real

Em produção séria, agente não age cegamente. Ele formula um plano antes de executar, e em algumas configurações, esse plano é revisado antes de virar ação.

O padrão básico:

O Revisor pode ser:

Uma chamada ao próprio modelo com prompt focado. "Esse plano cumpre os critérios X, Y, Z? Identifica problemas." Adiciona custo, mas captura erros óbvios.

Um conjunto de regras determinísticas. "Plano não pode ter mais de 10 passos. Não pode incluir tools destrutivas sem confirmação. Não pode buscar dados de outros clientes."

Um humano, em fluxos de alto risco. "Esse agente prepara o plano, humano aprova, agente executa." É o padrão pra qualquer ação com efeito significativo.

Auditar plano antes de executar tem três benefícios:

Detecta erros antes do estrago. Se o agente decidiu deletar 1000 registros como passo 4, o revisor para antes do passo 1 acontecer.

Reduz custo. Se o plano tem 15 passos quando 5 bastariam, replanejar é mais barato que executar 15 passos.

Cria trilha de auditoria explícita. Plano formal pode ser registrado, comparado com execução, e usado em revisão posterior.

Em fluxos onde tempo de resposta é crítico e ações são reversíveis, pular auditoria de plano é aceitável. Em fluxos com ações irreversíveis ou de alto custo, é negligência arquitetural não ter.

Evitando loops e divagações

Loops são o problema operacional mais comum em agentes em produção. O modelo chama a mesma tool várias vezes esperando resultado diferente. Tenta a mesma estratégia repetidamente. Fica revisitando informações já obtidas.

Algumas proteções funcionam:

Limite máximo de iterações. Cada execução de agente tem um número máximo de iterações no loop principal. Algo entre 10 e 30, dependendo da tarefa. Se o agente não concluiu nesse limite, retorna o que tem com sinalização de "não concluí dentro do limite". Sem isso, um loop pode rodar indefinidamente.

Detecção de chamadas repetidas. Se o agente chama a mesma tool com os mesmos parâmetros mais de N vezes, alguma coisa está errada. O sistema pode interromper, sinalizar como anomalia, ou injetar feedback no contexto: "você já tentou isso 3 vezes com o mesmo resultado, considere outra abordagem."

Memória de ações. O agente mantém em contexto a lista do que já fez. Sem essa memória, ele pode repetir ações achando que está em passo novo. Com a memória, o modelo tipicamente respeita e evolui.

Timeout global. Independente de iterações, há um tempo máximo de execução do agente. Se ultrapassou, interrompe.

Limite de custo por execução. Cada execução tem um budget de tokens. Atingiu o budget, para. Isso protege contra explosão financeira em caso de loop não detectado pelos outros mecanismos.

Essas proteções são caras de implementar em comparação a "deixar rodar e ver no que dá". Mas são a diferença entre operação saudável e incidente em horário comercial.

Observabilidade específica de agente

Logs e métricas tradicionais não dão conta de agente. Você precisa rastrear o passo a passo de cada execução pra entender o que está acontecendo.

O log mínimo de uma execução de agente registra:

{
  "execution_id": "exec_abc",
  "objective": "...",
  "steps": [
    {
      "step": 1,
      "thought": "...",
      "action": { "type": "tool_call", "tool": "search", "params": "..." },
      "result": "...",
      "tokens_used": 1247
    },
    {
      "step": 2,
      "thought": "...",
      "action": { "type": "tool_call", "tool": "read_doc", "params": "..." },
      "result": "...",
      "tokens_used": 982
    }
  ],
  "final_answer": "...",
  "total_tokens": 8421,
  "total_duration_ms": 12830,
  "completed": true,
  "termination_reason": "objective_achieved"
}

O campo thought (raciocínio do modelo entre ações) é o mais útil pra debugar. Quando o agente toma decisão estranha, é nesse campo que você descobre o porquê. Sem isso, você só vê as ações e fica adivinhando.

Métricas agregadas que importam: taxa de conclusão por tipo de objetivo, número médio de passos por execução, custo médio por execução, taxa de execução que atinge limite máximo de iterações (sinal de tarefas mal calibradas), distribuição de tools usadas (revela quais são realmente úteis e quais são ruído).

Quando substituir agente por workflow

Não é ofensa baixar a complexidade. Se o agente que você implementou está funcionando mas você percebe que ele segue praticamente o mesmo caminho em 90% dos casos, esse caminho deveria virar um workflow explícito.

Sinais de que workflow é melhor escolha:

A análise dos logs mostra que o agente chama as mesmas tools, na mesma ordem, em quase todas as execuções. Se a sequência é estável, codifique a sequência.

A taxa de aprovação humana de planos é alta (90%+). Se humanos quase sempre aprovam o plano, o plano poderia ser hardcoded e o humano só validar resultado.

O custo por execução é alto demais comparado ao benefício. Workflow é mais barato porque não tem a iteração extra de "modelo pensa, decide, age".

A previsibilidade importa mais que a flexibilidade. Em fluxos críticos, ter sempre o mesmo comportamento é mais valioso que adaptar caso a caso.

Migrar de agente pra workflow não é regressão. É reconhecer que o problema mudou de "espaço de decisão grande" pra "padrão estabelecido", e o padrão estabelecido pede outro tipo de solução.

Conclusão

Agente é uma ferramenta poderosa pra problemas certos. Pesquisa exploratória, investigação aberta, tarefas com sub-objetivos descobertos durante execução. Pra problemas estruturados, pra fluxos críticos, pra ações com efeito alto, agente é overengineering disfarçado de inovação.

A diferença entre agente brinquedo e agente operador real está na disciplina de limites: tools restritas, sub-objetivos explícitos, auditoria de plano, proteções contra loop, observabilidade detalhada, possibilidade de fallback pra humano. Tudo isso parece pesado, mas é o que separa demo de produção.

E uma reflexão final: o termo "autonomia" virou marketing em IA, mas autonomia sem responsabilidade é só descontrole. Um agente que pode tudo é um agente que ninguém quer em produção. Um agente que pode menos, mas dentro de limites bem desenhados, é o que entrega valor sustentável.

Insights & Takeaways

1. Agente faz sentido quando o espaço de decisão é grande demais pra enumerar e a sequência ideal de ações depende do que vai sendo descoberto. Pra tarefas estruturadas, workflow tradicional é melhor escolha.

2. Limitar o espaço de decisão é o que separa agente operacional de agente bagunça: lista pequena de tools, sub-objetivos explícitos, restrições no prompt. "Deixar o modelo descobrir" é receita pra problema.

3. Auditoria de plano antes da execução evita estragos, reduz custo e cria trilha de auditoria. Pode ser feita por modelo, regras determinísticas ou humano, dependendo do risco.

4. Loops são o problema operacional mais comum. Limite de iterações, detecção de chamadas repetidas, memória de ações e budget de tokens são proteções obrigatórias.

5. Quando o agente segue praticamente o mesmo caminho em 90% das execuções, esse caminho virou padrão estabelecido. Migrar de agente pra workflow não é regressão; é reconhecer que o problema mudou de natureza.