Os três pilares para um agente que melhora com o uso

Um agente que você usa por três meses e não está melhor do que no primeiro dia é um agente estático. Ele pode ser útil, pode ter boa qualidade de resposta, mas não está aprendendo nada da sua interação com ele. Para sistemas em produção com uso real, isso é uma limitação séria.

O que separa um agente estático de um que evolui não é o modelo. É a arquitetura ao redor do modelo. Especificamente, três camadas distintas que precisam existir ao mesmo tempo: memória de fatos, skills de domínio, e histórico consultável.

O problema com sistemas puramente baseados em prompt

A forma mais comum de dar "memória" a um agente é colocar tudo no system prompt. Você adiciona instruções, preferências do usuário, contexto do projeto, e espera que o agente se comporte de acordo. Isso funciona até o ponto em que o arquivo fica grande demais, as informações ficam desatualizadas, e o contexto começa a poluir mais do que ajuda.

O segundo problema é estrutural: um sistema que depende do próprio agente para atualizar suas memórias é frágil por design. O modelo pode simplesmente esquecer de criar o arquivo de memória. Pode criar com informações erradas. Pode deixar desatualizar. E memórias desatualizadas num agente são piores do que nenhuma memória, porque o agente age com confiança em informação errada.

Memória quente, memória morna, e o que vai no meio

A separação que funciona bem na prática divide o contexto em camadas por frequência de acesso.

Memória quente é o que está sempre no system prompt: as preferências persistentes do usuário, os fatos mais estáveis sobre o projeto, as diretrizes de comportamento. Esse arquivo tem que ser pequeno e denso. Se virar um dump de tudo que você achou importante, perde o valor.

Memória morna é o que existe mas é carregado sob demanda. Um índice aponta para os arquivos relevantes. O agente decide, na hora da consulta, o que precisa carregar. Isso mantém o contexto eficiente sem perder acesso ao que existe.

O que nenhuma dessas duas camadas resolve bem é conhecimento procedural: como executar um processo específico de domínio, qual foi o aprendizado de uma sequência de tentativas e erros, como abordar uma classe de problema que aparece regularmente. Para isso existe a camada de skills.

Skills: a camada que muda a qualidade operacional

Skill, nesse contexto, não é uma ferramenta que o agente pode chamar. É uma nota de domínio: um procedimento documentado que o agente criou a partir de uma sequência de ações que funcionou. Quando o agente enfrenta um problema que exigiu tentativa e erro, a skill captura o aprendizado para não começar do zero na próxima vez.

O que torna esse mecanismo robusto é quando a criação de skills não depende do humano ou do próprio agente no meio da tarefa. O padrão que aparece nas implementações mais avançadas é um processo em background que avalia periodicamente o que foi feito e extrai skills de forma autônoma, sem bloquear o fluxo principal.

No contexto do Athena, o agente que gera queries SQL para o TOTVS Protheus, o equivalente funcional são os blocos de contexto de consulta que criamos por empresa. Cada empresa no Protheus tem convenções próprias de campos, configurações específicas de módulo, regras de RH que afetam os filtros. Documentar esse conhecimento de forma consultável é o que separa o agente que gera a query certa na primeira tentativa do agente que precisa de correção manual constantemente. A diferença é que, no Athena, esse conhecimento ainda é inserido manualmente. O que sistemas como o Hermes Agent estão tentando resolver é fazer isso acontecer de forma autônoma.

Histórico consultável: o que diferencia "lembra o que fez" de "tem log"

Todo agente tem algum tipo de log de conversa. O problema é que log não é o mesmo que memória consultável.

Um log está lá. Mas se o agente não consegue buscar nesse histórico de forma semântica, o log não muda nada no comportamento. "Eu disse isso duas semanas atrás" não chega ao agente a não ser que você cole na conversa.

A diferença que importa é ter um histórico estruturado em banco consultável por similaridade. Quando uma nova mensagem chega, o sistema busca no histórico de conversas anteriores o que é semanticamente relevante e injeta no contexto antes de chamar o modelo. Isso é o que faz o agente parecer que lembra, porque de fato ele carregou o contexto relevante antes de responder.

O processo assíncrono como diferencial

O que separa as implementações que realmente funcionam das que degradam com o uso é ter um processo de consolidação de memória que não depende do agente se lembrar de executar.

Um processo que roda em background após a sessão, revisa o que foi feito, atualiza os arquivos de memória que ficaram desatualizados, e indexa as novas informações, resolve o problema da memória que apodrece com o tempo. Sem isso, o agente evolui durante um período e depois congela quando ninguém está ativamente mantendo os arquivos.

A combinação de memória quente estável, skills criadas de forma autônoma, e histórico consultável por similaridade é o que torna um agente progressivamente mais capaz. Cada uma das três camadas falha de um jeito diferente se estiver ausente: sem memória de fatos, o agente é inconsistente; sem skills, ele reinventa a roda em todo problema de domínio; sem histórico consultável, ele não tem como usar o que aprendeu nas sessões anteriores.

Qual das três camadas é mais difícil de implementar no domínio onde você trabalha?