Memória de agentes de IA: como criar agentes de IA com contexto persistente

Se tivesse de acompanhar um novo colega até à impressora todas as manhãs durante seis meses, começaria a ficar preocupado. Se ele conseguisse recitar cada ida anterior ao pormenor, mas continuasse a precisar de companhia, a sua memória seria excelente… mas continuaria a ter de se levantar da secretária.

A memória dos agentes de IA tem, atualmente, uma versão desta eterna ida à impressora. O CEO da Letta, Charles Packer, afirma no The New Stack que os benchmarks de memória estão saturados porque medem a recordação, algo que considera resolvido. O problema em aberto é um agente melhorar no seu trabalho através do contexto que guarda, sem qualquer novo treino.

A sua cofundadora, Sarah Wooders, compara-o a começar num emprego novo—os benchmarks entregam ao agente todo o contexto de que precisa—tarefa após tarefa sem relação entre si, o que nada tem a ver com a forma como as pessoas trabalham. Um recém-contratado pode precisar de ser acompanhado até à impressora. Mas, ao fim de três anos, esperaria poder entregar-lhe uma instrução de uma linha sem se levantar da secretária.

É esse o padrão a alcançar, e o objetivo por trás do Brain, o nosso sistema de memória com autoaperfeiçoamento para o Perplexity Computer, que organiza trabalho anterior e correções numa wiki de conhecimento em constante evolução.

Vamos abordar o que um agente deve recordar e como testar se isso o ajuda a fazer um trabalho melhor.

O que é a memória dos agentes de IA?

A memória dos agentes de IA é a informação que um agente retém de interações e trabalhos anteriores, juntamente com os mecanismos para a atualizar e utilizar. O contexto de memória persistente transporta essa informação entre sessões, pelo que fechar uma conversa não significa começar a tarefa seguinte do zero.

A maior parte do que é lançado com esse nome lembra-se do utilizador. As suas preferências, os seus contactos, a sua função, o facto de preferir PDF em vez de PNG. Essa é a metade fácil.

Quando criámos o Brain, o sistema de memória por trás do Perplexity Computer, concentrámo-nos no próprio trabalho. Que abordagem teve êxito? Que fonte desperdiçou vinte minutos? O que teve de corrigir depois de o agente anunciar que tinha terminado? Esse histórico dá à tarefa seguinte um melhor ponto de partida.

O Brain guarda esta informação como ficheiros na sandbox do agente, organizados em três camadas:

• sessions/ contém as transcrições em bruto e os respetivos resumos.
• notes/ contém informação destilada, organizada por tema.
• knowledge/ contém a própria wiki: páginas Markdown interligadas sobre pessoas, projetos e conceitos.

Nada disso melhora por si só. Durante a noite, agentes em segundo plano a que chamamos «Dream» leem as sessões do dia, resumem-nas e reveem a wiki sempre que o panorama mudou. Preparamos e verificamos essas edições antes de as submetermos no Git, para que haja um diff para inspecionar quando algo parecer errado.

Torna o agente melhor no seu trabalho? Na nossa avaliação emparelhada de 30 dias, as sessões com o Brain ativado melhoraram a exatidão em 9,3 pontos percentuais e a recordação em 8,9, utilizando cerca de menos 15% de tokens.

Expandir

Fonte: X

Quais são os tipos de memória agêntica?

Há dois grandes tipos, e a divisão é muito semelhante à que usaria para uma pessoa: o que tem em mente neste momento e o que ainda saberá no próximo mês.

Memória de curto prazo

A memória de curto prazo contém o contexto da conversa ou tarefa atual. O seu pedido, as mensagens recentes, o resultado de uma chamada de ferramenta, o documento que o agente acabou de abrir. Informação suficiente para perceber o que fazer a seguir.

Também verá isto designado por memória de trabalho. Para um LLM, a janela de contexto contém a informação disponível durante uma determinada chamada ao modelo. A aplicação pode manter um estado de tarefa adicional e decidir que partes fornecer em cada passo.

E curto prazo não significa necessariamente descartável. Uma framework pode guardar o estado da conversa e retomá-la amanhã—continua a pertencer a esse tópico. Mas se outra tarefa pode utilizar a informação é uma decisão de design à parte.

Memória de longo prazo

A memória de longo prazo disponibiliza informação entre sessões. O artigo CoALA foi buscar três categorias às ciências cognitivas, dando a quem desenvolve agentes um vocabulário para experiências e conhecimento prático:

• A memória episódica é o que aconteceu: inclui sessões anteriores, os passos que um agente deu, o resultado que obteve. No Brain, sessions/ fornece este histórico através de transcrições em bruto e dos respetivos resumos.
• A memória semântica é o que o agente considera verdadeiro: podem ser factos sobre o utilizador, os seus projetos e o seu mundo, destilados a partir das conversas. A wiki knowledge/ do Brain contém este tipo de informação, com ligações para as provas.
• A memória procedimental é como fazer as coisas: são prompts, fluxos de trabalho reutilizáveis, as Skills que a Perplexity cria para dar aos agentes as instruções e ferramentas de que um trabalho precisa. Talvez já tenha alguma desta memória sem lhe chamar memória.

O trabalho interessante acontece entre as camadas. Uma sessão regista que rejeitou um PNG. A sua instrução para usar PDF torna-se uma preferência que o agente pode levar consigo. Uma correção ao processo de exportação torna-se algo que pode seguir da próxima vez.

Essa conversão, de «isto aconteceu» para «isto é verdade» e para «é assim que fazemos», faz parte do problema de aprendizagem com que começámos, e é aí que as execuções noturnas do agente Dream do Brain concentram o seu esforço.

Imagine que alguém aquece peixe no micro-ondas numa cozinha partilhada. Há queixas, abre-se uma janela. Por fim, aparece um aviso: PROIBIDO PEIXE.

Seis meses depois, o infrator já se mudou, mas o aviso não. Isso é persistência. Pode explicar os tipos de memória através daquilo que perdura:

• A memória de trabalho é aquilo a que vai prestando atenção enquanto prepara o almoço, como a sopa que precisa de ser mexida.
• A memória episódica é o incidente do peixe; o cheiro que seguiu toda a gente até ao corredor.
• A memória semântica é o conhecimento que retirou daí—reaquecer peixe pode deixar um cheiro persistente numa cozinha partilhada.
• A memória procedimental é a instrução que determina o que acontece a seguir. Não aqueça peixe no micro-ondas aqui. O aviso permite que alguém que perdeu o incidente inteiro siga a regra.

Há ainda mais uma distinção, porque muda o que estamos a construir. Um estudo publicado pela primeira vez em dezembro de 2025, Memory in the Age of AI Agents, afirma que curto versus longo prazo não é suficiente—também classifica a memória pela forma:

• Ao nível dos tokens: é o conteúdo explícito que o agente lê. Ficheiros, registos armazenados, fragmentos recuperados.
• Paramétrica: é informação codificada em pesos aprendidos. Atualizá-la exige treino ou métodos de edição do modelo.
• Latente: é informação retida em representações internas sem ser escrita como texto legível.

Aqui, centramo-nos na memória ao nível dos tokens, ou seja, informação armazenada fora do modelo e lida para o seu contexto quando necessário. A wiki em Markdown do Brain é um exemplo.

Expandir

Quando atualizamos uma página, mudamos o que o agente pode ler na tarefa seguinte, mas os seus pesos subjacentes mantêm-se. É esse o argumento de Packer na introdução: melhorar através do contexto que o agente guarda, sem novo treino.

Como funcionam os tipos de memória dos agentes em conjunto?

Um agente pode rever uma tentativa anterior, ver onde errou e carregar as instruções que lhe deu depois. Há vários tipos de memória envolvidos na mesma tarefa, e não precisam cada um da sua vez nem de uma base de dados separada.

Aqui, a persistência determina o que continua disponível depois de a conversa terminar, enquanto a recuperação determina se o agente volta a vê-lo.

No Brain, preservamos esse caminho da lição até às provas. Imagine que pede ao Computer para continuar um projeto da semana passada:

• O índice do Brain indica-lhe que páginas de memória existem e onde as encontrar.
• O Brain abre a página do projeto para ler as decisões e instruções guardadas.
• Se uma nota disser que rejeitou uma abordagem, o agente pode seguir a respetiva citação até à conversa e verificar porquê.

As ligações para páginas relacionadas permitem-lhe consultar as pessoas ou outros projetos envolvidos. O agente fá-lo lendo e pesquisando ficheiros. O grep, por exemplo, permite-lhe encontrar menções a um projeto pelo nome.

Também testámos o que os agentes ganham por conseguirem explorar ficheiros. Num benchmark interno de 150 perguntas sobre documentos financeiros, um agente de exploração com ferramentas de ficheiros padrão atingiu uma pontuação de resposta de 0,627, em comparação com cerca de 0,37 da pesquisa semântica no mesmo corpus.

Expandir

Fonte: X

Como melhorar a memória dos agentes de IA?

Um artigo de maio de 2026 de Orogat e Mansour identifica quatro falhas recorrentes na memória dos agentes: o armazenamento não para de crescer, crenças desatualizadas ficam por rever, a informação é esquecida quando o espaço se esgota e a recuperação lê sem aprender nada com a consulta.

A solução que propõem é deixar de tratar a memória agêntica como armazenamento e tratá-la como um «estado» que evolui através de quatro operações: ingerir, rever, esquecer, recuperar. É essa a nossa lista de verificação para esta secção.

Seja seletivo quanto ao que é recordado

Quando uma memória «má» entra, todos os passos a herdam.

A Workday AI Research testou uma abordagem seletiva em cerca de 1500 memórias candidatas do benchmark LoCoMo, fazendo cinco perguntas antes de guardar qualquer uma delas:

• É útil? É plausível que volte a surgir?
• É fiável? A conversa disse mesmo isto, ou foi o modelo que o preencheu?
• É novo ou já está armazenado?
• É recente?
• É um facto duradouro ou um estado passageiro?

Só a primeira pergunta precisou de uma chamada ao modelo. As outras quatro foram executadas como regras, em menos de 65 milissegundos no total. O método obteve uma precisão 12% superior nas decisões de manter ou descartar, retendo 97% das memórias relevantes.

O fator com maior contributo foi a última pergunta—ao remover a distinção entre informação duradoura e temporária, a qualidade das decisões caiu cerca de 18%.

Reveja a resposta sem perder o histórico

Registe quando um facto passou a ser válido, que fonte o sustenta e o que substituiu. Se as fontes discordarem, mantenha essa discordância visível até haver provas suficientes para a resolver. O documento mais recente também pode estar errado.

O Brain atualiza a wiki com base em documentos de origem, resultados de conectores e correções dos utilizadores. Cada entrada de memória tem uma ligação para a respetiva fonte. Precisamos que o agente encontre a resposta atual e tenha onde procurar se essa resposta parecer suspeita.

Esqueça de propósito

O artigo chama a um dos modos de falha «esquecimento motivado pela capacidade»: a informação é removida para cumprir um limite de armazenamento, e não por ter deixado de ser útil.

De volta à cozinha partilhada. Ao fim de seis meses, ninguém quer saber quem aqueceu o peixe no micro-ondas nem durante quanto tempo a janela esteve aberta. Mas o aviso continua a ter uma função.

Quando a próxima pessoa preparar o almoço, a regra estará disponível. Basta arquivar as queixas.

As verificações de atualidade e de tipo de informação da Workday começam antes do armazenamento, filtrando o que merece tornar-se memória. No Brain, também revisitamos o conhecimento existente à medida que os documentos de origem mudam e os utilizadores fazem correções. Em ambos os casos, é o conteúdo que torna necessária a intervenção.

Faça com que a recuperação alimente a atualização seguinte

O agente recupera um facto, utiliza-o e deixa o armazenamento exatamente como o encontrou. Ora, a menos que o sistema registe o que aconteceu a seguir, nada indica se esse facto ajudou ou se levou o agente a mais um beco sem saída.

Registe o resultado, a fonte e qualquer correção. Quando criámos o Brain, tornámos esse histórico de trabalho parte daquilo que recorda: que abordagem teve êxito, que fonte não levou a lado nenhum e o que o utilizador corrigiu depois de o agente anunciar que tinha terminado. O Brain incorpora essa experiência nas atualizações periódicas da wiki, para que as tarefas posteriores a possam utilizar.

No entanto, nada disto aparece num benchmark de recordação. A forma de saber se o ciclo está a funcionar é dar ao agente uma tarefa que só consegue concluir com memória e contar quantas vezes a conclui, tendo em conta o custo e a latência. É isso que o DolphinBench faz, e é por isso que as pontuações mais altas continuam na casa dos setenta.

Como criar um agente com memória persistente utilizando a Perplexity

A Agent API da Perplexity não inclui um sistema de memória que se mantém a si próprio como o Brain. Preferimos dizê-lo desde já. Mas o que lhe dá são as peças da memória de que precisa: um local para guardar procedimentos, uma forma de transportar contexto entre interações e ferramentas para ler e escrever num armazenamento que controla.

Comece pela memória procedimental

Uma Skill personalizada agrupa instruções, procedimentos e ficheiros de apoio sob um número de versão. Uma equipa de plataforma pode escrever uma única vez as suas verificações de implementação, critérios de reversão e formato de relatório e, depois, fazer com que as aplicações referenciem a mesma Skill. Quando o procedimento muda, a equipa carrega uma nova versão.

Expandir

Fonte: X

Um Perfil vai um nível mais acima. Os Perfis guardam o modelo, as instruções, as ferramentas, as Skills, os conectores e as definições de execução do agente sob um único ID com controlo de versões.

Adicionámos ambos em setembro, juntamente com conectores geridos, para que um administrador de projeto possa configurar uma única vez uma ligação aprovada ao GitHub ou ao Slack e permitir que as aplicações a referenciem, em vez de armazenarem credenciais separadas. Quando o acesso muda, o administrador atualiza a ligação num único local.

Porque é que isto conta como memória? Voltemos, mais uma vez, à cozinha do peixe aquecido no micro-ondas. Quem chegar a seguir pode cumprir o aviso NADA DE PEIXE sem ter presenciado as queixas.

Uma Skill faz o mesmo trabalho para um agente, com espaço para os passos, as exceções e as verificações que não caberiam na porta de um micro-ondas. As Skills ficam escritas, têm controlo de versões e estão disponíveis da próxima vez que a tarefa surgir.

Também usamos Skills para orientar as atualizações de memória do Dream. Mas o que uma Skill não faz é aprender sozinha. As instruções mudam quando é carregada uma nova versão, seja por uma pessoa ou por um processo automatizado.

Se quiser que o agente repare que a verificação de reversão continua a falhar num serviço e se ajuste, isso corresponde ao ciclo de sessões para wiki de que falámos antes.

É preciso reter o que aconteceu, perceber o que deve mudar e disponibilizar a correção da próxima vez. Para isso, são necessárias as duas peças seguintes.

Mantenha a memória de trabalho entre turnos

O agente executa uma verificação de implementação. Pergunta: “Porque é que aquilo falhou?” Uma pergunta de seguimento razoável, desde que o agente ainda consiga ver a que se refere “aquilo”.

A nossa Agent API suporta duas formas de dar continuidade ao contexto da conversa:

• Reproduzir a conversa por conta própria: Inclua as mensagens anteriores no array input do pedido seguinte. Decide o que manter, resumir, ocultar ou descartar antes de o enviar.
• Continuar a partir de uma resposta concluída: Guarde o respetivo ID e passe-o como previous_response_id com a mensagem seguinte. Mantemos o estado da conversa no servidor, para que a sua aplicação não tenha de reenviar os turnos anteriores. Pode continuar a partir da resposta mais recente da cadeia.

A reprodução dá-lhe controlo sobre o que o agente vê, e continuar pelo ID poupa-lhe o trabalho de montar novamente a conversa. Em qualquer dos casos, forneça as novas instruções, ferramentas ou definições de modelo necessárias para a resposta seguinte.

Traga o seu próprio armazenamento episódico e semântico

Esta é a parte que a Agent API deixa a seu cargo.

Uma das vias é a chamada de funções. Define as ferramentas, o agente pede uma chamada e a sua aplicação executa-a e devolve o resultado. Para a memória, um ponto de partida simples é uma operação de leitura antes de o agente agir e uma operação de escrita depois.

Se registar apenas o facto que o agente obteve, continua sem saber se ajudou. Se registar o resultado, a fonte e tudo o que o utilizador corrigiu, tem o início de uma camada episódica.

O nosso suporte para MCP oferece-lhe outra via. Se um servidor MCP remoto compatível expuser as operações de que precisa, o agente pode chamá-las sem que tenha de encapsular cada uma como uma função personalizada.

Os nossos conectores dão ao agente acesso às provas por detrás das memórias. GitHub, Slack, Google Drive, Datadog, Linear e Notion fazem parte do nosso catálogo gerido, e pode adicionar conectores personalizados para sistemas internos.

Por fim, decida quando é que o histórico é revisto e o relato atual é atualizado.

Teste o que sobrevive a uma nova sessão

Agora, feche a conversa. Inicie um novo pedido sem reproduzir as mensagens antigas nem passar previous_response_id, mas dê ao agente acesso ao mesmo armazenamento de memória. Peça-lhe que faça trabalho relacionado sem repetir a correção.

Se o agente precisar do lembrete, ainda não terminou.

Para o agente de implementação, crie alguns testes em torno do que deve ser mantido:

• A correção mantém-se: O agente obtém e utiliza o comando de reversão verificado para o serviço afetado.
• A correção mantém-se no âmbito: Não altera os procedimentos dos outros serviços.
• A nova informação substitui as orientações antigas: Quando o comando muda novamente, o agente utiliza a versão atual e consegue rastrear a alteração até à sua origem.

O nosso guia prático de testes de regressão mostra como guardar os resultados do agente e as provas obtidas, verificá-los face ao comportamento esperado e comparar execuções depois de alterar instruções ou modelos.

Mantenha fixas as versões do modelo, do Perfil e da Skill enquanto compara execuções com e sem memória. Inicie cada comparação a partir de um instantâneo conhecido do armazenamento; caso contrário, um teste pode ensinar ao agente a resposta do seguinte.

Quando algo falhar, guarde o caso. A próxima alteração terá de passar nele.

Ou poupe-se ao trabalho de construir: Brain no Computer

Se o que pretende é o ciclo acabado em vez das peças, isso é o Computer. O Brain funciona por baixo dele, a aprender com quatro fontes: as suas sessões, as ferramentas ligadas, os ficheiros e artefactos que cria e as suas correções. As atualizações em segundo plano do Brain reforçam o que continua válido, reveem o que mudou e assinalam a informação desatualizada.

Não tem de construir esse ciclo por conta própria. Basta fazer o seu trabalho.

A Memória guarda as preferências e os detalhes que partilhou. O Brain liga projetos, pessoas, decisões e trabalho por concluir às provas que os sustentam.

Pode inspecionar o que aprendeu na vista Memória, rastrear as entradas até às respetivas fontes e editá-las ou eliminá-las. O Brain utiliza a sua própria atividade, exclui as sessões anónimas e tem um interruptor próprio.

Expandir

Na Rho, por exemplo, as decisões de um projeto de faturação estavam dispersas pelo Slack, Notion, Jira, Figma e Google Docs. A equipa configurou o Computer para rever as alterações durante a noite, assinalar inconsistências e publicar um resumo matinal no Slack.

O engenheiro de software da empresa, Oktawian Jurkiewicz, reparou que o Computer também estava a criar memória para o projeto. “Não fomos nós que a definimos”, diz. “O Computer descobriu que dados devia guardar de cada fonte.”

A equipa afirma ter reduzido o tempo semanal de reuniões de 2,5 horas para 15 minutos e estima ter poupado 120 horas de trabalho ao longo do projeto de 12 semanas.

As 120 horas são atribuídas a todo o fluxo de trabalho: conectores, execuções noturnas e o resumo no Slack. Quanto do tempo poupado se deveu apenas à memória? Ainda não conseguimos quantificá-lo.

Mas o que podemos aconselhar é que, para a sua própria solução, volte ao teste de há pouco: execute tarefas equivalentes com a camada de memória ativada e desativada e, depois, compare as taxas de conclusão, o custo e o tempo, incluindo o tempo que alguém gasta a corrigir o resultado.

Perguntas frequentes sobre memória de agentes de IA

Os agentes de IA podem ter memória?

Sim. Os agentes de IA podem reter informação entre sessões através de conversas, factos, preferências e procedimentos reutilizáveis armazenados. O sistema tem de obter essa informação quando é relevante e atualizá-la quando as circunstâncias mudam.

O Brain no Perplexity Computer, por exemplo, cria contexto de trabalho a partir de sessões, ferramentas ligadas, ficheiros e correções do utilizador.

Quanta RAM utiliza um agente de IA?

Não existe um requisito único. Se o seu agente chamar um modelo alojado através da Perplexity Agent API, não precisa de carregar esse modelo na sua própria RAM. A sua aplicação e as ferramentas locais continuam a precisar de memória.

A execução de um modelo local é diferente. A quatro bits por parâmetro, oito mil milhões de parâmetros equivalem a cerca de 4 GB de dados de pesos em bruto. A memória realmente necessária é superior quando se inclui a sobrecarga da quantização, o processamento do contexto e o software que executa o modelo.

Qual é a melhor memória para um agente de IA?

A melhor configuração depende do que o agente precisa de levar consigo. Um estado de conversa suporta perguntas de seguimento; os registos episódicos preservam o que aconteceu; a memória semântica guarda o conhecimento atual; a memória procedimental fornece instruções reutilizáveis.

A maior parte do trabalho contínuo beneficia de uma combinação. Para o Brain, utilizamos uma wiki interligada e sustentada por fontes. Para a sua própria solução, teste se a configuração ajuda o agente a concluir tarefas, aplicar correções e retirar orientações desatualizadas.