Agentes de IA: uma introdução

“Agente de IA” é hoje o termo mais banalizado do setor. É vendido como mágica, mas por dentro há só um loop simples. Quando você entende esse loop, para de se deixar levar por demos e começa a avaliar com frieza quando um agente faz sentido e quando um script comum é a melhor saída. Este texto é para desenvolvedores que já ouviram a palavra “agente” quinhentas vezes e ainda não sabem dizer em que ele difere de um chatbot. A diferença está em uma única coisa: um agente age, não apenas responde.

O que é um agente, e o que ele não é

Um chatbot recebe texto e devolve texto. Só isso. Não tem acesso ao mundo, não executa ações e não lembra de nada além da janela de contexto da conversa atual. Um agente é mais do que isso. A definição prática que vale guardar: um agente é um LLM, mais ferramentas, mais um loop, mais memória.

• LLM: o cérebro, que decide o que fazer em seguida;
• ferramentas: as mãos (busca, banco de dados, terminal, API);
• loop: o mecanismo que permite dar mais de um passo;
• memória: o que o agente sabe além do prompt atual.

Tire qualquer um desses elementos e aquilo deixa de ser um agente. Um LLM sem ferramentas é um chatbot. Um LLM com ferramentas, mas sem loop, é uma única chamada de função: útil, mas não é um agente. Só o loop, no qual o modelo observa o resultado da própria ação e decide a próxima, transforma um modelo de linguagem em algo que persegue um objetivo.

O loop, o coração do agente

O modelo mental mais simples é o ciclo perceber - planejar - agir - observar. O agente recebe um objetivo, olha para o estado atual, escolhe uma ação, executa, lê o resultado e volta ao início. Repete isso até considerar o objetivo cumprido ou esgotar seu orçamento de passos.

1. Perceber: reunir contexto (o objetivo, os resultados até agora, o estado do mundo);
2. Planejar: decidir qual ferramenta chamar e com quais argumentos;
3. Agir: executar a chamada da ferramenta (quem faz isso é o seu código, não o modelo);
4. Observar: o resultado da ferramenta volta ao contexto como uma nova observação.

Esse loop é enganosamente simples, e é aí que se esconde a maior parte dos problemas em produção. Sem um limite rígido de iterações, o agente pode andar em círculos, chamar a mesma ferramenta dez vezes ou “melhorar” uma solução que funciona até quebrá-la. Um limite de passos e um critério claro de “pronto” não são opcionais: são obrigatórios.

Tool use e function calling

O mecanismo que dá mãos a um LLM se chama function calling ou tool use. Funciona assim: você descreve para o modelo as ferramentas disponíveis, com nome, descrição e esquema de argumentos (geralmente JSON Schema). Em vez de responder com texto, o modelo devolve uma requisição estruturada: “chame search com o argumento query: AI agents”.

Um detalhe crucial que confunde iniciantes: o modelo não executa a ferramenta. Ele só pede que ela seja executada. É o seu código que recebe a requisição, roda a função de verdade, captura o resultado e o coloca de volta no contexto. A fronteira de confiança passa exatamente aqui, e é deste lado, no seu código, que você coloca a validação de argumentos e os limites. Nunca deixe texto gerado pelo modelo ir direto para um eval, um shell ou uma query SQL sem uma camada de controle.

ReAct versus plan-and-execute

Existem duas arquiteturas de loop dominantes, e vale a pena conhecer a diferença.

ReAct (reason + act) intercala pensar e fazer. O modelo raciocina em voz alta enquanto avança, executa uma ação, lê o resultado e raciocina de novo. É reativo e se sai bem em ambientes imprevisíveis, quando não dá para planejar tudo de antemão porque cada passo muda o cenário. A desvantagem: pode ser míope e se perder numa cadeia longa.

Plan-and-execute separa as fases. Primeiro o modelo monta um plano completo (uma lista de passos), depois executa os passos em ordem, replanejando se algo der errado. Oferece mais previsibilidade e sai mais barato: o planejamento acontece uma vez, não a cada iteração. A desvantagem: um plano rígido lida mal com ambientes que mudam mais rápido do que o agente consegue executá-lo.

Minha escolha padrão: comece com ReAct, porque é mais simples de rodar e depurar. Passe para plan-and-execute quando as tarefas ficarem longas e o custo de “pensar” a cada passo começar a doer.

Um agente ou vários

A tentação de dividir um problema entre uma equipe de agentes especializados (pesquisador, programador, revisor, orquestrador) é forte e quase sempre prematura. Multiagente soa elegante, mas acrescenta dois custos reais: a comunicação entre agentes consome tokens, e os erros de um agente se propagam para os outros, muitas vezes sem que ninguém perceba.

• Um agente: o ponto de partida padrão. Mais fácil de rastrear, mais barato e suficiente para a grande maioria das tarefas;
• Vários agentes: recorra a eles quando a tarefa se divide naturalmente em subdomínios paralelos ou quando você precisa de conjuntos de ferramentas e permissões diferentes para papéis diferentes.

Regra prática: não adicione um segundo agente até que um só realmente não dê conta. Na maioria das vezes, “precisamos de multiagente” na verdade significa “nosso único agente tem ferramentas demais e um prompt vago demais”.

Memória: curta, longa, vetorial

A memória se divide em dois tipos, e confundi-los é um erro de design comum.

• Memória de curto prazo é a janela de contexto: a conversa atual, as observações recentes. É rápida, mas limitada, e desaparece quando a sessão termina;
• Memória de longo prazo é o conhecimento que sobrevive à sessão: documentos, histórico, fatos sobre o usuário. Normalmente fica fora do modelo e é carregada sob demanda.

O mecanismo mais comum de memória longa é um banco vetorial. Você transforma o texto em um embedding (um vetor de números) e, na hora da consulta, encontra os trechos mais próximos em significado e os injeta no contexto. Essa é a base do RAG. Cuidado com a armadilha: um banco vetorial não é mágica. Se você o alimentar com lixo, o agente recebe de volta um lixo semanticamente parecido. A qualidade dos seus chunks e metadados decide tudo.

MCP: um padrão comum para ferramentas

Até pouco tempo atrás, cada framework de agentes definia ferramentas do seu próprio jeito. O MCP (Model Context Protocol) é uma tentativa de unificar isso: um protocolo aberto em que um servidor expõe ferramentas, recursos e prompts, e qualquer cliente (agente) pode usá-los sem escrever uma integração do zero.

Por que isso importa para você: você escreve um servidor MCP uma vez e ele se conecta a vários agentes e hosts. Em vez de n integrações para n ferramentas e m agentes, você tem uma única interface compartilhada. Para o ferramental de agentes, é mais ou menos o que o LSP se tornou para os editores de código: um protocolo em vez de um número quadrático de plugins. Em 2026, vale a pena escrever novas integrações de ferramentas para MCP, se você tiver escolha.

Onde os agentes brilham, e onde desmoronam

Agentes são ótimos quando a tarefa exige muitos passos, acesso a ferramentas e tolerância à iteração:

• Pesquisa: busca em várias fontes, síntese, verificação cruzada;
• Programação: ler um repositório, escrever alterações, rodar testes, corrigir;
• Operações: triagem de tickets, tarefas rotineiras com dados, automação de workflows.

E desmoronam de forma igualmente previsível em:

• Horizontes longos: quanto mais passos, maior a chance de o agente perder o objetivo ou travar;
• Acúmulo de erros: se um único passo dá certo 95% das vezes, depois de vinte passos a chance combinada de sucesso cai para menos da metade. Os erros se multiplicam, não se somam;
• Custo: cada iteração é uma chamada ao LLM. Um agente que “pensa” trinta vezes custa trinta vezes mais do que uma única consulta e, às vezes, nem assim termina a tarefa.

Encare esses números como uma estimativa que ilustra o mecanismo, não como um benchmark rigoroso: as taxas reais dependem da tarefa e do modelo. Mas a direção é certa: a falta de confiabilidade cresce com o comprimento da cadeia.

Guardrails e humano no loop

Um agente com acesso a ferramentas pode quebrar algo de verdade: apagar um arquivo, enviar um e-mail, gastar dinheiro. Por isso, guardrails não são um acessório; fazem parte da arquitetura.

• Limites: número máximo de passos, orçamento de tokens, timeout;
• Validação de ferramentas: cada chamada é verificada do lado do código (por exemplo, com um schema) antes que qualquer coisa seja executada;
• Privilégio mínimo: o agente só tem acesso ao que realmente precisa, nunca ao banco de produção “por via das dúvidas”;
• Humano no loop: ações irreversíveis ou caras exigem aprovação humana antes de serem executadas.

Humano no loop não é desconfiança da IA: é o mesmo princípio que você aplica a um deploy em produção ou a uma migração de banco de dados. Quanto mais alto o risco e mais difícil desfazer o efeito, mais perto da decisão um humano deve estar.

Agente ou um script comum

A decisão mais importante acontece antes de você escrever a primeira linha. O modelo mental é simples: se os passos são conhecidos de antemão e não mudam, escreva um script. Um script é mais barato, mais rápido, determinístico e fácil de testar.

Recorra a um agente apenas quando o caminho até o objetivo não é conhecido de antemão, quando cada passo depende do resultado do anterior e o número de ramificações é grande demais para deixar fixo no código. Em outras palavras: um agente é uma ferramenta para a incerteza, não para a repetição. Se você consegue desenhar um fluxograma da tarefa, um script quase sempre será melhor. Se o fluxograma tem cem caminhos e metade deles depende do conteúdo dos dados, aí está um terreno fértil para um agente.

TL;DR

Um agente é um LLM mais ferramentas, mais um loop, mais memória: algo que age, não só responde. O coração é o loop perceber-planejar-agir-observar; o function calling lhe dá mãos, mas quem executa a ferramenta é o seu código, não o modelo. Comece com ReAct e um único agente, deixe um banco vetorial cuidar do conhecimento que fica fora do contexto e apoie-se no MCP para padronizar as ferramentas. Agentes brilham em pesquisa, programação e operações, mas desmoronam em horizontes longos por causa do acúmulo de erros e do custo. Cerque-os de limites e de um humano no loop para ações irreversíveis. E, se os passos são conhecidos de antemão, escreva um script, não um agente.