O que é um agente de IA: definição técnica honesta, sem mística

'Agente' virou a palavra mais distorcida do mercado de IA. Toda startup chama o produto de agente. Todo framework promete agentes. Todo fornecedor jura que seu chatbot evoluiu pra agente. O resultado: dev sênior abre o código e descobre um while em volta de um chat.completions, com dois if de retry. Esse post define agente com rigor técnico, separa do que não é, mostra o que precisa ter pra valer o nome, e termina classificando os arquétipos que aparecem em produção. Sem mística. Engenharia.

A definição que vou defender aqui, baseada na linha de Anthropic (Building Effective Agents, 2024) e Russell & Norvig (AIMA 4ed): agente é um sistema onde um LLM controla autonomamente o próprio fluxo de execução, decidindo quais ferramentas usar, quando usar, e quando parar, com base em observação do ambiente. O controle de fluxo está no LLM, não no programador. Esse é o eixo. Tudo o resto deriva.

1. A diferença que define: control flow no LLM vs no código

Anthropic propôs em 2024 uma distinção limpa que virou referência: workflows vs agents.

Workflow: LLM e ferramentas são orquestrados em caminhos pré-definidos pelo código. O programador escreve a sequência: 'chama LLM A pra classificar, se for tipo X chama tool Y, manda resultado pra LLM B resumir'. O grafo é fixo. O LLM preenche slots, não decide topologia.

Agente: o LLM dirige o próprio loop. A cada iteração ele decide a próxima ação (chamar tool, raciocinar mais, terminar). O programador não sabe de antemão quantos passos vai ter, em que ordem, quais tools serão invocadas. A topologia emerge da execução.

Essa distinção tem consequência prática direta. Workflow é previsível, debugável, barato. Agente é flexível, caro, e exige observabilidade séria. Se o seu problema cabe num workflow, use workflow. Agente é overkill em 70% dos casos onde é usado hoje. A frase é deliberadamente impopular. É verdade.

2. Anatomia mínima: o que precisa existir

Pra um sistema ser agente segundo a definição, ele tem que ter cinco componentes funcionais. Faltou um, não é agente, é outra coisa.

• Modelo: um LLM capaz de tool calling (function calling). Hoje significa Claude 3.5+, GPT-4+, Gemini 1.5+, Llama 3.1+, ou equivalente. Modelo sem tool calling estruturado não vira agente sem hack frágil.
• Tools: funções determinísticas que o LLM pode invocar, com schema declarado. Tool pode ser query SQL, request HTTP, leitura de arquivo, execução de código sandboxed, ou outro agente.
• Loop: estrutura que recebe a resposta do LLM, executa tool se pedida, devolve resultado, e itera. Tem que ter critério de parada (resposta final, budget esgotado, erro fatal).
• Memória de trabalho: representação do histórico da execução acessível ao LLM. Mínimo: lista de mensagens com tool calls e resultados. Avançado: KV cache otimizado, compactação, resumos parciais.
• Runtime/harness: a camada que monta o prompt a cada iteração, parseia resposta, despacha tool, gerencia erro, controla timeout. É onde mora 80% da complexidade real.

Faltam dois e você tem chatbot avançado. Falta o loop com controle no LLM e você tem workflow. Falta tool calling e você tem RAG bonito. Os cinco juntos, e só os cinco juntos, fazem agente.

3. O ciclo: percepção, decisão, ação, observação

O loop interno segue OODA (Observe, Orient, Decide, Act), adaptado.

1. Observação: input inicial do usuário, ou resultado da última ação. Vira mensagem na working memory.
2. Orientação: harness monta o prompt completo (system + history + tools disponíveis) e envia ao LLM.
3. Decisão: LLM gera resposta. Pode ser tool_use (uma ou várias, em paralelo) ou texto final (end_turn).
4. Ação: harness executa as tool calls solicitadas, captura resultado (sucesso, erro, dados retornados).
5. Volta pra (1): resultado vira nova observação. Loop continua até end_turn, budget, ou erro fatal.

O nome chique dessa estrutura é ReAct (Reasoning + Acting), formalizado por Yao et al. em 2022. Hoje toda implementação séria deriva disso. A inovação não está no padrão, está em como cada peça é executada: como gerenciar contexto pra não explodir tokens, como retornar erro estruturado, como paralelizar tool calls independentes, como decidir budget.

4. Tool calling: o que torna possível

Tool calling é o mecanismo que destrava agente. Sem ele, o LLM só gera texto. Com ele, o LLM gera solicitação estruturada de ação, que o runtime intercepta e executa.

O protocolo varia por fornecedor mas a forma é a mesma. Você declara as tools no request:

{
 "tools": [{
 "name": "get_weather",
 "description": "Returns current weather for a city",
 "input_schema": {
 "type": "object",
 "properties": { "city": { "type": "string" } },
 "required": ["city"]
 }
 }]
}

O LLM, em vez de gerar texto, decide chamar a tool e emite:

{
 "stop_reason": "tool_use",
 "content": [{
 "type": "tool_use",
 "id": "toolu_01A09",
 "name": "get_weather",
 "input": { "city": "São Paulo" }
 }]
}

O harness executa get_weather('São Paulo'), captura o resultado, e devolve na próxima iteração como tool_result. O LLM continua o raciocínio com o dado novo. Esse é o mecanismo. Tudo o que se chama agente hoje gira em torno disso.

5. O que NÃO é agente

Pra deixar a definição operacional, lista do que falsamente é vendido como agente:

• Chatbot com prompt grande: LLM responde com texto e o programador parseia. Sem tool calling estruturado, sem loop. Não é agente.
• RAG: pipeline busca docs, injeta no prompt, LLM responde. Fluxo fixo. É workflow, não agente. (RAG pode ser tool dentro de um agente, aí muda.)
• Chain of prompts: A gera, B critica, C reescreve. Mesmo com vários LLMs, se a topologia é fixa, é workflow.
• n8n/Zapier com nó de IA: fluxo determinístico com IA num passo. Workflow.
• Function calling sem loop: você chama LLM uma vez, ele decide uma tool, você executa, devolve a resposta direto pro usuário. Sem iteração. Não é agente, é function-augmented LLM.

O critério único é o controle de fluxo. Se o caminho da execução é decidido em runtime pelo LLM, é agente. Se é decidido em design-time pelo dev, não é.

6. Os arquétipos que aparecem em produção

Quatro padrões cobrem 95% dos agentes reais.

Agente reativo single-turn: um loop curto, poucas iterações, sem planejamento explícito. LLM decide próxima ação baseado só na observação atual. Bom pra tarefas onde o caminho é descobrível incrementalmente (suporte, navegação web, debug). Anthropic chama de 'augmented LLM' no caso degenerado de 1 turn.

Agente com planner: primeira chamada gera um plano (lista de passos). Loop executa cada passo. LLM pode replanejar se um passo falhar. Útil quando a tarefa tem estrutura previsível (research multi-fonte, refactoring de código, preenchimento de formulário multi-página).

Orchestrator-workers (multi-agent): um agente principal decompõe a tarefa, delega sub-tarefas a sub-agentes especializados, sintetiza resultado. Sub-agentes têm context window própria, reduzindo poluição do contexto principal. Padrão usado em Claude Code, Cursor agent mode, deep research da OpenAI.

Evaluator-optimizer: dois LLMs em loop. Um gera solução, outro avalia. Itera até evaluator aprovar ou budget acabar. Útil pra geração de código, tradução, redação técnica, onde qualidade é mensurável e iteração paga.

7. Propriedades que separam agente de brinquedo

Um agente que vai pra produção tem que demonstrar quatro propriedades operacionais. Sem elas, é prova de conceito.

• Convergência: o loop termina em tempo finito na maioria dos inputs. Métrica: percentual de execuções que atingem end_turn dentro do budget definido.
• Idempotência onde importa: tools com side-effect devem ser idempotentes (chave de deduplicação) ou exigir confirmação explícita. Agente vai retentar. É garantido.
• Observabilidade: cada turn registra prompt enviado, resposta recebida, tools chamadas, latência, custo em tokens. Sem trace, debug em produção é adivinhação.
• Failure mode previsível: o que acontece quando tool falha? Quando LLM alucina tool name inexistente? Quando context overflowa? Cada uma dessas tem que ter resposta projetada, não acidental.

8. Custo: a variável que dimensiona viabilidade

Workflow de 1 chamada custa 1x. Agente típico faz 5 a 20 chamadas pra resolver uma tarefa. Custo por execução escala linear no número de turns, e o context cresce a cada turn (cada tool result acumula). Custo total pode ser 50x a 200x um workflow equivalente.

Isso muda a régua de decisão. Agente faz sentido quando: (a) o ganho de qualidade é mensurável e justifica o custo, (b) o problema não é resolvível por workflow no tempo de design, (c) a frequência de execução é baixa o suficiente pra absorver o custo, ou (d) o custo de erro humano é alto o bastante pra pagar a iteração extra.

Não faz sentido quando: tarefa é alta frequência e baixo valor, tem caminho determinístico óbvio, ou o budget de tokens não suporta tentativas múltiplas. 'Tudo agente' é a versão 2026 do 'tudo microservice'. Vai dar errado pela mesma razão.

9. A linha do tempo: por que agentes funcionam agora

A ideia de agente é antiga (década de 80, em IA simbólica). LLMs como base de agente são recentes (2022). Tool calling estruturado virou primeira-classe em 2023 (OpenAI function calling) e maduro em 2024 (Anthropic tool use, structured outputs). Três coisas convergiram pra agentes virarem realidade:

• Modelos com raciocínio de longo horizonte: Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro mantêm coerência ao longo de 20+ turns. Modelos de 2023 perdiam o fio em 5.
• Context windows grandes: 128k a 2M tokens permitem manter histórico inteiro sem compactação agressiva. Em 2022, 4k tokens forçavam workflow.
• Tool calling treinado no pré-treino: modelos modernos foram treinados pra usar ferramentas. Não é prompt engineering, é capability nativa.

10. O reframe pra quem está construindo

Definição operacional final, pra usar em discussão de arquitetura: agente é workflow onde o grafo de execução é decidido em runtime pelo próprio LLM, usando tool calling estruturado, dentro de um loop com critério de parada explícito. Se você não consegue desenhar o agente nessa frase, ou o sistema não é agente, ou a definição que você está usando é diferente da que a indústria está convergindo.

Próximo post desta série vai por baixo dos panos: como exatamente o harness do agente funciona, como gerenciar context que cresce a cada turn, como executar tool calls em paralelo sem race condition, como lidar com tool que falha no meio do loop, e como instrumentar tudo isso pra observabilidade. A definição é o eixo. A implementação é onde tudo dá errado.