A maioria das equipes de IA que busca melhorar o desempenho dos agentes recorre às mesmas alavancas: janelas de contexto maiores, mais documentos e prompts mais inteligentes. Este artigo argumenta que esse instinto está completamente errado. O ingrediente que falta não é mais informação. É controle. Uma camada de controle bem projetada é o que separa um agente que funciona em uma demonstração de outro que funciona em produção.
Dar a um agente de IA mais memória, mais documentos ou uma janela de contexto maior não o torna mais inteligente, apenas mais lento e caro. Os ganhos reais vêm de ensinar o agente a escolher o que precisa e quando precisa, em vez de consumir tudo de uma vez.
A confiabilidade vem do ciclo, não do modelo. A diferença entre um agente que impressiona em uma demonstração e outro que funciona bem em produção não é a qualidade da IA, mas se o sistema verifica o próprio trabalho. Agentes que planejam, agem, observam e verificam cada etapa detectam os próprios erros em vez de errar com confiança.
Hoje, a maioria dos agentes de IA é basicamente um chatbot com etapas extras: não tem mecanismos para saber se está no caminho certo, quando parar ou quando tentar outra abordagem. Adicionar uma camada de controle adequada — critérios claros de sucesso, estado estruturado e verificações de validação — é o que transforma algo com cara de agente em um sistema realmente confiável.
O que você almoçou ontem?
Você provavelmente não repassou todas as lembranças que já teve até chegar a "ontem + almoço". Foi direto para a parte da sua experiência onde esses conceitos estão. Esse é um modelo mental útil para criar agentes:
Uma janela de contexto gigantesca não é memória.
Uma pilha de documentos recuperados não é compreensão.
Uma cadeia de pensamento longa não é confiabilidade.
Esses são os ingredientes. Mas o que faz um agente parecer um agente é o mesmo que impede seu cérebro de percorrer à força todo o histórico da sua vida: controle.
Um estudo recente — Raciocínio com agentes de IA para grandes modelos de linguagem — resumiu (e nomeou) muito bem a mudança que muitos de nós percebemos ao desenvolver sistemas: do raciocínio dentro do modelo para o raciocínio por meio da interação. Este artigo não é um resumo desse estudo. É uma tentativa de traduzir essa mudança em um projeto prático de sistemas:
Se você criar agentes como chatbots com ferramentas, continuará enfrentando os mesmos modos de falha dos chatbots, mas com erros mais caros.
Por algum tempo, nosso roteiro padrão para "tornar o modelo mais inteligente" era basicamente: prompts melhores, cadeia de pensamento, autoconsistência ou melhorias baseadas em amostragem e, talvez, alguma busca.
O ReAct foi um ponto de virada porque tornou natural a sequência "pensamento → ação → observação". Mas observe a restrição implícita: boa parte disso ainda acaba sendo uma "inferência one-shot, mas com mais tokens". O enquadramento do estudo é mais preciso: o raciocínio com agentes de IA enfatiza a expansão da interação durante o teste, transformando a inferência em um processo iterativo no qual modelo, memória e ambiente permanecem no ciclo.
Se você criou ou usou agentes que parecem impressionantes em demonstrações, mas são frágeis em fluxos de trabalho reais, isto é para você.
Vou descrever um padrão que já vi muitas vezes — e do qual eu mesmo certamente criei algumas versões:
Pegue um bom modelo de chat
Adicione algumas ferramentas (busca, consulta a banco de dados e talvez execução de código)
Adicione RAG
Adicione um prompt de sistema: “you are an autonomous agent”
Coloque tudo em um loop while até que pare ou atinja o tempo limite
Parabéns, você criou algo com cara de agente. Mas ele tende a falhar de formas previsíveis:
Contexto inchado: cada observação é acrescentada; os prompts se transformam em camadas arqueológicas.
Uso desorientado de ferramentas: "a ferramenta errada, mas com confiança" se torna o modo de falha padrão.
Sem condições de parada: ele continua porque pode, não porque deve.
Sem disciplina de fundamentação: ele não percebe que está errado, a menos que você o force a verificar.
Memória = histórico do Chat: o que equivale a escrever logs e chamar isso de aprendizado.
É por isso que os "agentes" muitas vezes parecem mágicos em demonstrações e problemáticos em produção. Nossa experiência ao colocar sistemas com agentes de IA em produção também reflete isso: quando você deixa de avaliar um modelo e passa a avaliar um sistema, os modos de falha incluem navegação, uso disciplinado de ferramentas, redução do contexto e projeto de avaliações — não apenas "o modelo respondeu corretamente?".
Então a pergunta passa a ser: o que é um agente intencional?
Para tornar isso menos abstrato, veja um fluxo de trabalho simplificado que a maioria das pessoas consegue imaginar: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Uma implementação comum com "cara de agente" funciona assim:
Recupera imediatamente vários documentos de políticas de companhias aéreas e viagens, mesmo que nenhum deles seja necessário naquele momento.
Chama uma ferramenta de busca, cola uma longa lista de resultados no prompt e "escolhe um".
Faz a reserva cedo demais, sem verificar as restrições de horário de chegada, bagagem, assento e política.
Se falhar, tenta novamente de um jeito um pouco diferente, mas sem saber claramente o que mudou ou o que aprendeu.
O problema não é que o modelo não saiba raciocinar, mas que o sistema não controla o fluxo de trabalho.
Uma versão com mais autonomia trata a tarefa como um processo interativo, com estado e verificações explícitos:
PLANEJAR: reformular as restrições e listar as informações que faltam (por exemplo, "há preferência de aeroporto?"/"uma escala é aceitável?").
AGIR: chamar a busca de voos com uma consulta estruturada (intervalo de datas, restrição de chegada e orçamento).
OBSERVAR: armazenar os resultados em um objeto de estado compacto (os cinco melhores candidatos, com preço, chegada e escalas), não em um enorme bloco de texto colado.
ATUALIZAR: refinar a consulta se as restrições não forem atendidas (por exemplo, "chegar antes das 18h é restritivo demais — ampliar o horário ou aumentar o orçamento?").
VERIFICAR: executar validadores ("chegada < 18h", "preço ≤ £900", "em conformidade com a política", "seleção de assento disponível").
PARAR: somente quando a API de reservas retornar uma confirmação e todos os validadores forem aprovados.
A mudança é sutil, mas decisiva. A recuperação é condicional, não automática; o contexto é gerenciado, com estado estruturado em vez de acumulado; e a verificação faz parte do ciclo, em vez de ficar a cargo do usuário. Troque "reservar um voo" por "criar uma ordem de compra", "emitir um reembolso", "alterar uma configuração de produção" ou "entregar um PR", e a história será a mesma: quando o agente pode agir, o ciclo importa mais do que o prompt.
O estudo citado acima organiza o raciocínio com agentes de IA em três camadas: fundamental (planejamento, uso de ferramentas e busca), autoevolutiva (feedback e memória) e coletiva (coordenação entre vários agentes).
Mas a ideia mais profunda é esta: o raciocínio se torna o princípio organizador do planejamento, da tomada de decisões e da verificação — não apenas da geração de uma cadeia de pensamento plausível. Isso parece abstrato até você relacionar a ideia às mudanças na sua arquitetura. Há três pontos fundamentais a lembrar:
Um bom agente não deve tratar a recuperação como algo que "sempre deve ser feito". Recuperar é uma decisão, não um reflexo.
Esta é uma heurística prática:
Se o sistema recupera informações a cada interação, você não criou um mecanismo de recuperação, mas um imposto sobre o contexto.
Isso aparece o tempo todo no trabalho real. Ao depurar um incidente de produção, você não despeja todos os logs no contexto; decide quais métricas ou logs buscar em seguida com base na hipótese atual. Isso é "recuperação com agentes de IA". Veja um padrão mais concreto:
Decida se precisa recuperar informações
Se sim: formule uma consulta, busque, examine e extraia
Se as evidências entrarem em conflito, busque novamente
Só então sintetize
É também nesse ponto que o "RAG com agentes de IA" começa a se diferenciar do RAG tradicional: a recuperação se torna uma etapa deliberada do raciocínio, não uma fase padrão do pipeline.
Quando você deixa de avaliar "um modelo" e passa a avaliar "um sistema", o acompanhamento e o rastreamento do estado passam a importar.
A esta altura, o setor já reconhece de forma mais explícita a importância da observabilidade nos fluxos de trabalho de agentes. Por exemplo, o Agents SDK da OpenAI vem com rastreamento integrado e um painel Traces que registra as execuções do agente (gerações, chamadas de ferramentas, transferências, proteções e eventos personalizados), justamente para que você possa depurar e auditar passo a passo o que aconteceu.
Isso não é algo apenas "desejável". É a diferença entre um sistema que você consegue depurar e outro que só consegue avaliar pela intuição.
Na minha opinião, a parte mais prática do estudo é a franqueza com que ele trata o feedback. Ele divide o feedback em três regimes: feedback reflexivo (gerar → criticar → revisar), adaptação paramétrica (aprender por ajuste fino/RL) e feedback orientado por validadores (tentar novamente até passar na validação).
A maioria das equipes deveria começar pelo feedback orientado por validadores, porque ele é simples e eficaz. Se você puder criar qualquer validador que faça testes unitários, confira o schema, aplique regras ou restrições de negócio ("nenhum reembolso acima de X sem escalonamento") ou verifique a factualidade ("citações obrigatórias"), poderá transformar a saída não determinística do modelo em algo realmente confiável.
Uma das mudanças antes imprevisíveis é simples: no universo dos agentes, a confiabilidade muitas vezes vem mais do ciclo do que do modelo.
Esta é a disciplina de ciclo mais simples que encontrei para melhorar o comportamento de forma consistente sem treinamento:
Trabalhe em etapas: Planejar → Agir → Observar → Atualizar;
Após cada ação, resuma a observação em 1 a 3 tópicos;
Pare quando os critérios de sucesso forem atendidos ou o orçamento for atingido; retorne o melhor resultado conhecido e as incertezas restantes.
Não se trata de fazer o modelo produzir respostas longas. Trata-se de tornar o sistema compreensível e forçar o "contato com a realidade" em cada etapa. Um exemplo bastante familiar para quem trabalha com engenharia é a fundamentação em ciclo fechado no estilo de CI:
Planejar: propor uma lista de alterações
Agir: executar testes/lint
Observar: analisar as falhas
Atualizar: corrigir e tentar novamente
Algumas perguntas que costumam revelar agentes criados por acaso:
"Meu agente decide o que recuperar ou eu sempre recupero tudo?"
Se a recuperação for incondicional, você pagará em latência, custo, diluição do contexto e maior risco de o lixo que entra virar lixo que sai.
"Meu agente consegue perceber que está errado?"
Se o único sinal de feedback do agente for "o usuário fica irritado", você está fazendo RL à custa do sofrimento humano. Um ciclo de novas tentativas orientado por validadores é a forma mais simples de colocá-lo em contato com a realidade.
"É possível gravar na memória? Ela melhora com o tempo?"
Se sua "memória" apenas acrescenta o histórico do chat, você está basicamente escrevendo logs. A forma como o estudo enquadra a memória é importante: ela se torna um contexto que cresce dinamicamente e que os agentes refinam com o tempo — não apenas uma transcrição.
Os logs informam o que aconteceu; a memória informa o que fazer na próxima vez. O histórico do Chat é uma transcrição. A memória é uma política em evolução sobre o que vale a pena levar adiante.
Um ponto de partida prático é uma pequena tabela de "lições aprendidas", organizada por tipo de tarefa, ferramenta e modo de falha, com registros do que funcionou e do que evitar. O objetivo não é criar um grafo de conhecimento perfeito. O objetivo é criar um comportamento cumulativo: memória e feedback transformam agentes que eram "assistentes sem estado" em sistemas que melhoram com o tempo.
É tentador lançar mais agentes sobre o problema, mas isso costuma multiplicar o trabalho de coordenação. Um bom padrão de "equipe mínima viável":
Coordenador: decompõe e atribui tarefas
Executor: faz chamadas de ferramentas e alterações
Crítico/avaliador: verifica correção e risco
Responsável pela memória: registra e organiza lições
Se você não consegue explicar a responsabilidade de cada agente, provavelmente ainda não precisa de vários agentes.
Se realmente aceitarmos a mudança de paradigma, provavelmente deixaremos de colocar tudo nos prompts, tratar falhas como resultados finais e avaliar agentes como se fossem chatbots. E passaremos a tratar os agentes como o que são: sistemas de software nos quais a linguagem é o plano de controle — e a confiabilidade vem do ciclo.
Antes de adicionar outro modelo, adicione outro ciclo de avaliação. Antes de recuperar tudo, torne a recuperação condicional. Coloque um validador em produção antes de colocar dez. Trate a memória como decisões de política, não como um banco de dados. E, ao adotar vários agentes, comece com dois, não com vinte. Isso não são regras, mas os padrões que sobreviveram à produção.