Como funcionam os agentes de IA: do LLM ao feedback loop

Digitar uma pergunta no ChatGPT e receber uma resposta é uma coisa. Pedir para um sistema "pesquise os concorrentes da minha empresa, monte uma planilha comparativa e me mande por e-mail" e ver isso acontecer sozinho, em várias etapas, é outra completamente diferente. A segunda é o que hoje se chama de agente de IA, e entender como ele funciona por dentro exige separar seis peças que, juntas, transformam um modelo que só prevê texto em algo que decide, age e corrige o próprio curso.

O que é um agente de IA

Um agente de IA é um sistema construído em torno de um LLM (modelo de linguagem) que consegue executar tarefas de múltiplas etapas de forma autônoma, decidindo sozinho qual ação tomar a cada passo, com base no estado atual da tarefa. A diferença central para um chatbot comum não é o modelo por trás, geralmente é o mesmo, é a arquitetura ao redor dele: memória entre passos, um ciclo de planejamento, acesso a ferramentas e um mecanismo de repetição até a tarefa estar pronta.

Isso muda completamente o tipo de trabalho que o sistema consegue fazer. Um chatbot responde uma pergunta e para. Um agente pode pesquisar, ler o resultado, perceber que falta informação, pesquisar de novo com um termo diferente, organizar tudo e só então entregar a resposta final, sem que o usuário precise mediar cada etapa.

O termo virou um guarda-chuva usado para produtos bem diferentes entre si: agentes de código que editam repositórios inteiros, agentes de navegador que preenchem formulários e clicam em botões, agentes de atendimento que consultam sistemas internos antes de responder um cliente. O que todos têm em comum, apesar da aparência tão distinta, é justamente essa estrutura de seis peças que este artigo detalha. Entender cada peça separadamente é o que permite comparar produtos diferentes de forma justa, em vez de julgar tudo pelo resultado final que aparece na tela.

Vale também demarcar o que um agente não é. Ele não é um sistema com "livre-arbítrio" nem toma decisões fora do escopo que o desenvolvedor definiu, o conjunto de ferramentas disponíveis, os limites de iteração e os critérios de sucesso são todos configurados de antemão. A autonomia de um agente é real dentro desses limites, mas os limites em si continuam sendo definidos por humanos.

LLM: o motor de raciocínio

O LLM é o componente que decide o que fazer a seguir, mas vale desfazer um mal-entendido comum: o modelo não "lembra" nada entre uma chamada e outra. Cada vez que o agente precisa de uma decisão, ele monta um novo prompt inteiro (com histórico, resultados de ferramentas, instruções) e manda para o modelo, que responde de forma stateless, sem memória própria embutida.

O que faz o LLM parecer que está "raciocinando" ao longo de várias etapas é uma técnica chamada chain-of-thought: em vez de pular direto para uma resposta, o modelo é induzido a expor passos intermediários de raciocínio antes de decidir a ação final. Isso melhora bastante a qualidade de decisões complexas, porque o próprio processo de "escrever pensando" ajuda o modelo a não pular etapas lógicas importantes.

Na prática, o LLM dentro de um agente cumpre um papel bem específico: olhar o estado atual (o que já foi feito, o que a ferramenta retornou, qual é o objetivo original) e decidir a próxima ação, seja chamar uma ferramenta, pedir mais informação ao usuário, ou concluir que a tarefa terminou.

Um ponto que costuma surpreender quem está começando: o mesmo modelo, com o mesmo prompt, pode gerar decisões ligeiramente diferentes em execuções distintas. Isso acontece porque a geração de texto em um LLM é probabilística, não determinística, controlada por um parâmetro chamado temperatura. Em agentes que tomam decisões sensíveis (como mover dinheiro ou deletar dados), é comum configurar uma temperatura baixa, para reduzir essa variação e tornar o comportamento mais previsível, ainda que nunca perfeitamente determinístico.

Vale também notar que "o LLM" de um agente raramente é uma única chamada de modelo. Sistemas mais sofisticados usam modelos diferentes para etapas diferentes: um modelo mais barato e rápido para decisões simples de roteamento, e um modelo maior e mais caro só para os passos que realmente exigem raciocínio profundo. Essa divisão de trabalho ajuda a controlar custo sem sacrificar qualidade onde ela importa.

Memória

Como o modelo não guarda nada sozinho, toda a "memória" de um agente é, na verdade, engenharia de contexto: decidir o que colocar de volta no prompt a cada chamada. Existem, na prática, dois tipos:

• Memória de curto prazo: o histórico da conversa ou da execução atual, que cabe dentro da janela de contexto do modelo. Cresce a cada passo do agente, e em tarefas longas pode precisar ser resumida para não estourar o limite de tokens.
• Memória de longo prazo: informação que precisa sobreviver além de uma única execução, guardada fora do modelo, em um banco de dados, um arquivo ou um índice vetorial, e recuperada sob demanda quando relevante. A técnica mais comum para isso é o RAG (retrieval-augmented generation): antes de responder, o sistema busca os trechos mais relevantes dessa memória externa e injeta no prompt.

Um exemplo prático ajuda a fixar a diferença: um agente de programação que lê o código de um projeto guarda o arquivo aberto no momento como memória de curto prazo, mas convenções do time (como "sempre use TypeScript estrito" ou "nunca use a biblioteca X") costumam ficar salvas como memória de longo prazo, em um arquivo de configuração que é recarregado a cada nova sessão.

A janela de contexto de um modelo, por maior que seja, tem um limite físico de tokens, e cada token custa dinheiro e tempo de processamento. Isso obriga quem constrói o agente a tomar decisões constantes sobre o que vale a pena manter na memória de curto prazo e o que pode ser resumido ou descartado. Uma técnica comum é a compactação progressiva: a cada certo número de passos, o próprio agente gera um resumo do que aconteceu até ali, substitui o histórico bruto por esse resumo, e segue a execução com um contexto bem mais enxuto.

Para a memória de longo prazo baseada em RAG, o mecanismo por trás costuma envolver um banco de dados vetorial: cada trecho de informação é convertido em um vetor numérico (embedding) que representa seu significado, e a busca não procura por palavras exatas, procura pelos vetores mais parecidos semanticamente com a pergunta atual. É por isso que um agente com RAG bem configurado consegue encontrar um documento relevante mesmo que ele use palavras completamente diferentes das que o usuário digitou.

Planejamento

Diante de uma tarefa complexa, um agente raramente resolve tudo em uma única chamada ao modelo. O padrão mais usado hoje é o ReAct (Reasoning and Acting), publicado em 2022: o modelo alterna entre "pensar" (raciocinar sobre o que fazer) e "agir" (chamar uma ferramenta), observando o resultado de cada ação antes de decidir a próxima, em vez de tentar prever o plano inteiro de uma vez só.

Existe também o padrão "plan-and-execute", em que o modelo primeiro escreve um plano completo com várias etapas, e só depois começa a executá-las uma a uma. Ele tende a ser mais previsível, mas menos flexível: se uma etapa no meio do caminho falha ou revela informação nova, o agente precisa replanejar, o que nem sempre é tratado de forma automática nesse desenho.

Na prática, a maioria dos agentes de produção mistura os dois: um plano inicial aproximado, revisado a cada poucos passos com base no que realmente aconteceu, em vez de seguido cegamente do início ao fim.

Um exemplo concreto do padrão ReAct em ação: pergunte a um agente "qual o horário de funcionamento da loja mais próxima de mim que tem o produto X em estoque". Um plano rígido, feito de uma vez, provavelmente falharia, porque o agente ainda não sabe quais lojas existem nem quais têm o produto. Com ReAct, o modelo primeiro raciocina ("preciso achar lojas próximas"), age (chama uma ferramenta de busca por localização), observa o resultado, raciocina de novo ("agora preciso checar estoque de cada uma"), age de novo, e só então, com informação suficiente, formula a resposta final. Cada decisão depende do resultado da anterior, o que seria impossível prever em um plano único e fixo.

Também existe a questão de profundidade de planejamento: tarefas simples podem pular a etapa de planejamento explícito e ir direto para a escolha de ferramenta, enquanto tarefas complexas, com muitas dependências entre sub-tarefas, se beneficiam de um plano escrito de forma explícita, às vezes até mostrado ao usuário antes de começar a execução, para que ele possa aprovar ou ajustar o rumo antes de qualquer ação real ser tomada.

Ferramentas

Ferramentas são o que dão ao agente a capacidade de agir no mundo real, além de só gerar texto: buscar na web, rodar código, consultar um banco de dados, enviar um e-mail. O mecanismo técnico por trás disso é o function calling (ou tool calling): o desenvolvedor descreve cada ferramenta disponível, com nome, descrição e um schema dos parâmetros que ela aceita, e o modelo devolve uma resposta estruturada indicando qual ferramenta chamar e com quais argumentos.

O modelo em si nunca executa a ferramenta. Ele só decide e formata a chamada; quem efetivamente roda o código, faz a requisição HTTP ou consulta o banco é o software ao redor do modelo. Essa separação é importante: significa que o mesmo "cérebro" pode ser conectado a ferramentas completamente diferentes sem precisar ser retreinado, só reconfigurando quais funções estão disponíveis no prompt.

O Model Context Protocol (detalhado no artigo anterior sobre MCP) resolve justamente a parte de padronizar como essas ferramentas são descritas e descobertas, para que um agente não precise de uma integração específica para cada serviço externo que ele usa.

Na prática, as ferramentas de um agente costumam se agrupar em algumas categorias recorrentes: busca e leitura de informação (web, documentos, bancos de dados), ação sobre sistemas externos (enviar e-mail, criar um ticket, atualizar uma planilha), execução de código (rodar um script, uma query SQL, um comando de terminal) e comunicação com o próprio usuário (pedir confirmação, fazer uma pergunta de esclarecimento). Um agente bem desenhado normalmente não recebe acesso a todas as ferramentas disponíveis no sistema de uma vez, só o subconjunto necessário para a tarefa em questão, seguindo o mesmo princípio de menor privilégio usado em segurança de sistemas tradicionais.

A qualidade da descrição de cada ferramenta importa mais do que parece. Um nome vago como process_data com uma descrição de uma linha tende a gerar chamadas erradas ou mal formatadas, porque o modelo não tem contexto suficiente para decidir quando usá-la. Descrições específicas, com exemplos de uso e limites claros (o que a ferramenta não faz), reduzem bastante a taxa de erro nessa etapa.

Execução

A execução é a camada de software, geralmente chamada de runtime ou orquestrador do agente, que recebe a decisão do LLM e efetivamente a coloca em prática: chama a API certa, roda o comando, espera a resposta, trata erro se a chamada falhar. É aqui também que entram as camadas de segurança: sandboxing para código gerado pelo modelo, limites de tempo (timeout) para cada chamada, e validação dos parâmetros antes de executar qualquer coisa irreversível.

Um detalhe que gera confusão: nem toda execução é sequencial. Agentes mais sofisticados podem disparar várias ferramentas em paralelo quando elas são independentes entre si, como buscar em três fontes diferentes ao mesmo tempo, o que reduz bastante o tempo total da tarefa comparado a chamar uma ferramenta de cada vez e esperar cada resposta antes de seguir.

A tratativa de erro nessa camada é o que separa um agente frágil de um confiável. Uma chamada de ferramenta pode falhar por dezenas de motivos: a API externa está fora do ar, os parâmetros estão mal formatados, a permissão foi negada, o tempo limite estourou. Um orquestrador bem construído captura cada tipo de falha separadamente e decide o que fazer com ela: tentar de novo automaticamente (com um limite de tentativas, para não repetir uma falha permanente indefinidamente), devolver o erro ao LLM como parte da observação para que ele tente uma abordagem diferente, ou escalar o problema para intervenção humana quando nenhuma das opções automáticas resolve.

Sandboxing merece destaque à parte quando a ferramenta envolve execução de código gerado pelo próprio modelo. Rodar esse código diretamente no mesmo ambiente onde o agente vive é um risco real, então implementações sérias isolam essa execução em um container ou máquina virtual descartável, sem acesso à rede ou a arquivos sensíveis por padrão, liberando só o que a tarefa específica realmente precisa.

Feedback loop

Depois que uma ferramenta executa, o resultado dela não desaparece: ele volta para dentro do contexto, como se fosse uma nova informação que o LLM precisa levar em conta na próxima decisão. Esse ciclo (perceber estado, planejar, agir, observar resultado, atualizar o contexto) se repete quantas vezes forem necessárias até que uma de duas coisas aconteça: o modelo decide que a tarefa está completa, ou o agente atinge um limite de segurança, como um número máximo de iterações ou um tempo total de execução.

Esse limite de iterações não é um detalhe menor. Sem ele, um agente mal configurado pode entrar em um ciclo onde repete a mesma ação sem nunca considerar a tarefa concluída, gastando tokens (e dinheiro) indefinidamente. Por isso, praticamente todo framework de agente sério embute algum tipo de trava: um contador máximo de passos, uma checagem explícita de critério de sucesso, ou a exigência de confirmação humana depois de certo número de tentativas sem progresso.

Vale distinguir dois tipos de parada. A parada "feliz" acontece quando o LLM avalia o estado atual contra o objetivo original e conclui, de forma explícita, que todos os critérios foram atendidos. A parada por limite acontece quando o agente esgota o número de iterações ou o orçamento de tempo/custo permitido sem chegar lá, e nesse caso o comportamento esperado não é simplesmente travar, é reportar ao usuário o que foi feito até aquele ponto e por que a tarefa não pôde ser concluída sozinha.

Um padrão cada vez mais comum em sistemas de produção é o human-in-the-loop: para ações de alto risco (mover dinheiro, deletar dados, enviar uma comunicação pública), o feedback loop inclui uma pausa obrigatória esperando aprovação humana antes de prosseguir para a próxima iteração, mesmo que o agente já tenha decidido, sozinho, que aquela é a ação correta.

O ciclo completo, em diagrama

Juntando as seis peças, o ciclo de um agente de IA fica assim:

O ponto central desse desenho é que a seta de volta não é um detalhe estético: é o que separa um agente de um simples fluxo automatizado de etapas fixas. O agente decide, a cada volta do ciclo, se precisa continuar ou se já cumpriu o objetivo.

Chatbot vs agente

Vale colocar lado a lado, porque a linha entre os dois nem sempre é óbvia para quem usa o produto final:

Aspecto	Chatbot tradicional	Agente de IA
Estrutura da resposta	Uma pergunta, uma resposta	Várias etapas encadeadas até completar um objetivo
Acesso a ferramentas	Raro ou inexistente	Central, via function calling ou MCP
Memória entre passos	Só o histórico da conversa atual	Curto e longo prazo, muitas vezes com busca externa (RAG)
Autonomia de decisão	Baixa, o usuário guia cada troca	Alta, o próprio sistema decide os próximos passos
Critério de parada	Fim da mensagem gerada	Critério de sucesso da tarefa ou limite de iterações

Na prática, a fronteira é um espectro, não uma linha nítida: muitos produtos hoje são chatbots com algumas ferramentas simples plugadas, sem chegar a ter um ciclo de planejamento completo. O termo "agente" tende a ser reservado para sistemas que realmente decidem seus próprios próximos passos, não apenas executam uma função quando o usuário pede explicitamente.

Um teste prático para diferenciar os dois na hora de avaliar um produto: peça uma tarefa que exige pelo menos três etapas dependentes entre si, sem detalhar o passo a passo, só o resultado desejado. Um chatbot tende a pedir mais instruções ou tentar resolver tudo em uma resposta única e superficial. Um agente de verdade quebra o pedido em sub-tarefas, usa ferramentas para resolver cada uma, e só entrega o resultado final depois de completar o ciclo inteiro sozinho.

Exemplo completo

Para tornar tudo isso concreto, vale acompanhar um agente hipotético de pesquisa de mercado recebendo o pedido: "pesquise os 3 principais concorrentes da minha empresa no Brasil e me mande um resumo por e-mail".

Passo 1, planejamento: o LLM decompõe o pedido em sub-tarefas: buscar concorrentes, coletar dados de cada um, sintetizar em um resumo, enviar por e-mail. Esse plano inicial fica guardado na memória de curto prazo da execução.

Passo 2, primeira ferramenta: o agente chama uma tool de busca na web com a query "principais concorrentes [empresa] Brasil". O resultado (uma lista de nomes e links) volta como observação.

Passo 3, feedback e replanejamento: o LLM observa que a busca retornou 5 nomes, mas só precisa de 3. Ele filtra os mais relevantes e decide, para cada um, chamar uma nova ferramenta que extrai dados públicos básicos (porte, principais produtos, presença de mercado).

Passo 4, execução paralela: como os três concorrentes são independentes entre si, o orquestrador dispara as três chamadas de extração ao mesmo tempo, em vez de uma atrás da outra, economizando tempo total.

Passo 5, síntese: com os três conjuntos de dados na memória de curto prazo, o LLM gera o texto do resumo comparativo, já formatado.

Passo 6, última ferramenta: o agente chama a tool de envio de e-mail, passando o resumo gerado como corpo da mensagem.

Passo 7, conclusão: o LLM observa a confirmação de envio, verifica que todos os itens do plano inicial foram cumpridos, e encerra o ciclo, respondendo ao usuário que a tarefa foi concluída.

Repare que, em nenhum momento, o usuário precisou intervir entre um passo e outro. Isso só é possível porque cada uma das seis peças (LLM, memória, planejamento, ferramentas, execução, feedback loop) fez exatamente o papel descrito nas seções anteriores.

FAQ

Um agente de IA sempre precisa de memória de longo prazo?

Não. Tarefas simples, resolvidas em uma única sessão, podem funcionar só com memória de curto prazo (o histórico da execução atual). Memória de longo prazo importa quando o agente precisa lembrar de algo entre execuções diferentes.

Quantas iterações um agente costuma fazer antes de parar?

Varia muito com a complexidade da tarefa e a configuração do framework usado, mas a maioria dos sistemas de produção define um limite explícito, geralmente entre 5 e 25 iterações, para evitar loops sem fim.

Um chatbot com plugins já é um agente?

Depende de quanta autonomia ele tem. Se o usuário precisa pedir explicitamente cada ação, é mais um chatbot com ferramentas. Se o sistema decide sozinho a sequência de ações necessárias para cumprir um objetivo, isso já é comportamento de agente.

O que acontece se uma ferramenta falha no meio da execução?

Depende do orquestrador. Implementações robustas devolvem o erro como parte da observação, e o LLM decide se tenta de novo, tenta uma abordagem diferente, ou reporta a falha ao usuário, em vez de travar o ciclo inteiro.

É possível um agente usar mais de um LLM ao mesmo tempo?

Sim, e é cada vez mais comum. Um modelo menor e mais barato pode cuidar de decisões simples de roteamento, enquanto um modelo maior entra só nas etapas que exigem raciocínio mais profundo, o que ajuda a controlar o custo total da execução sem perder qualidade nas partes que mais importam.

Tirando o jargão, um agente de IA não é uma tecnologia nova isolada, é uma forma específica de organizar peças já conhecidas (um modelo de linguagem, algum tipo de memória, acesso a ferramentas) em um ciclo que se repete até um objetivo ser cumprido. Entender essas seis peças separadamente é o que torna possível diagnosticar por que um agente específico falha, trava em loop ou entrega um resultado incompleto, em vez de tratar o sistema inteiro como uma caixa-preta.