Pesquisadores propõem forma de agente de IA aprender com correções entre sessões

O problema que quem mantém agente em produção já cansou de ver

Quem construiu um agente de IA baseado em LLM para uso interno ou para cliente final conhece o padrão: o usuário corrige um comportamento ("não envie e-mail sem confirmar antes", "sempre use o formato de data DD/MM") e, na sessão seguinte, o agente comete exatamente o mesmo erro. A correção não persiste. O usuário vira professor eterno do próprio assistente.

Um paper publicado em 5 de novembro de 2026 no arXiv, assinado por Nima Vahdat e Pashootan Vaezipoor e aceito no NeurIPS 2026 Workshop on Personalized, Aligned, Long-Term Memory for AI Systems (PALM), nomeia o problema com precisão: os sistemas de memória de agente que existem hoje tratam principalmente fatos (preferências do usuário, entidades, histórico de conversa), não conhecimento procedural, ou seja, o "como fazer" que uma correção ensina.

Como o Forge Decision Context grava e aplica correções

O sistema proposto no paper se chama Forge Decision Context (forge_dc). A ideia central tem três passos, descritos no abstract do trabalho:

1. Capturar sinais comportamentais: correções explícitas feitas por humanos e falhas de chamadas de ferramenta que o próprio agente identifica (self-assessed tool-call failures).
2. Compilar esses sinais em diretivas imperativas, que o paper chama de RULE directives, basicamente instruções curtas e diretas em vez de texto narrativo solto na memória.
3. Injetar essas diretivas exatamente nos pontos de decisão onde elas se aplicam, em vez de jogar tudo no contexto a cada chamada.

O paper não publica a sintaxe exata das diretivas RULE, mas a lógica descrita sugere algo equivalente, em espírito, a isto (exemplo ilustrativo, não extraído do paper):

RULE[tool=send_email, trigger=before_call]:
  require_user_confirmation = true
  reason: "correção registrada em 2026-10-14"

A diferença para um sistema de memória tradicional é que a regra não é "lembrada" como um fato solto que o modelo precisa reinterpretar toda vez. Ela é anexada ao ponto exato da decisão (antes de chamar send_email, por exemplo), então o agente não precisa varrer um histórico inteiro para descobrir se aquela regra se aplica.

O benchmark DC-Bench e os números que sustentam a comparação

Para medir isso, os autores criaram o DC-Bench, um benchmark com 71 cenários distribuídos em nove dimensões comportamentais, construído a partir de traces reais de execução de agentes, rodados em um ambiente determinístico com ferramentas simuladas (mocked-tool environment). Determinístico aqui importa: significa que o mesmo cenário produz o mesmo resultado a cada rodada, o que permite comparar sistemas de memória de forma justa, sem o ruído de uma ferramenta real que responde diferente a cada chamada.

O forge_dc foi avaliado contra quatro abordagens predecessoras nesse benchmark. Os resultados reportados no abstract:

Compliance aqui mede se o agente, numa nova sessão, de fato segue a correção que já tinha recebido antes. Subir de 55% para 95% é a diferença entre um sistema que ainda erra quase metade das vezes e um que acerta quase sempre. E o ganho de tokens não é um detalhe cosmético: é o que, multiplicado por volume de chamadas em produção, define o custo real de manter o contexto do agente ao longo do tempo.

Cinco estágios, da memória de fatos até a diretiva comportamental

O paper organiza as cinco abordagens comparadas (as quatro predecessoras mais o forge_dc) como uma progressão de cinco estágios. Segundo os autores, os sistemas mais fortes dessa progressão compartilham duas escolhas de design:

• Representar a memória comportamental como diretivas explícitas (regras imperativas), não como texto livre que o modelo precisa reinterpretar.
• Entregar essa memória nos pontos de decisão exatos onde ela se aplica, não em um bloco genérico de contexto no início da conversa.

Os autores resumem os achados identificando representação, ativação e posicionamento (onde na pipeline de decisão a regra é injetada) como os três eixos centrais de design para aprendizado comportamental persistente. É uma forma de dizer que não basta guardar a correção: importa como ela é formatada e em que momento exato ela chega ao modelo.

O que muda para quem mantém agente em produção

Para quem está construindo agente com LangChain, com um framework próprio ou com a API de um provedor de LLM, o recorte prático do paper é direto: sistemas de memória que empilham fatos soltos no contexto (o padrão hoje em muita stack de RAG aplicada a memória de agente) tendem a esbarrar em dois limites ao mesmo tempo, compliance baixa e custo de token alto, porque o modelo precisa receber e reprocessar um bloco grande de histórico a cada chamada para tentar inferir se alguma regra antiga se aplica.

A proposta de separar correção de fato comum, compilar em regra imperativa e injetar só no ponto de decisão certo ataca os dois problemas ao mesmo tempo: menos token por chamada (logo, menos custo por chamada) e mais aderência à regra (logo, menos retrabalho do usuário corrigindo o mesmo erro). Em um agente que roda milhares de chamadas por dia, a diferença entre 55% e 95% de compliance se traduz em volume real de correções manuais evitadas, e a redução de 10x em tokens por consulta se traduz em uma fração do custo de contexto por chamada à API do modelo.

O que ainda não dá para saber a partir do que foi publicado

O abstract e a submissão do arXiv não trazem link de código aberto, nem detalham a sintaxe exata das diretivas RULE, nem especificam com qual modelo de linguagem o forge_dc foi testado. O trabalho tem 12 páginas e foi aceito em um workshop (PALM, do NeurIPS 2026), não no programa principal da conferência, o que normalmente indica resultado ainda em estágio inicial de validação, não um sistema pronto para produção.

Para quem quer acompanhar de perto, o caminho é ler o PDF completo no arXiv (arXiv:2611.08644) antes de tentar reproduzir a arquitetura, já que o resumo público não cobre os detalhes de implementação necessários para repetir o experimento. O ganho de compliance e de economia de token é promissor, mas por ora é resultado medido pelos próprios autores em benchmark próprio, não algo validado de forma independente por terceiros.

Fonte: arXiv cs.AI