Stash - camada de memória persistente para agentes de IA

• Uma camada de memória persistente que mantém o contexto de conversas e tarefas mesmo quando a sessão muda, armazenando observações brutas como episodes e depois acumulando-as como conhecimento estruturado
• Usa uma arquitetura independente de modelo, permitindo conectar Claude, GPT, LLMs locais e até agentes customizados à mesma camada de memória, com armazenamento baseado em PostgreSQL e pgvector
• Cumpre um papel diferente de RAG: em vez de ficar apenas na busca de documentos, acumula novos fatos, relações, metas, falhas e hipóteses a partir das conversas, podendo ser usado junto com RAG
• Com namespace e caminhos hierárquicos, separa conhecimento de usuário, projeto e autoconsciência do agente, enquanto um pipeline de consolidação continua sintetizando facts, relationships, causal links, patterns e contradictions
• Inclui integração nativa com MCP, um modelo próprio baseado em /self e até loops iterativos de pesquisa para transformar agentes sem memória e dependentes de sessão em entidades de trabalho com continuidade de longo prazo

---

Visão geral do Stash

• Uma camada de memória persistente posicionada entre agentes de IA e o mundo externo, fazendo com que o contexto anterior continue disponível mesmo quando a sessão muda
• Armazena observações brutas como episodes e as acumula como conhecimento estruturado, como facts, relationships, patterns, goals, failures e hypotheses
• Não substitui o modelo em si, mas reforça a continuidade, sendo projetado para se conectar a qualquer agente, como Claude, GPT e modelos locais
• Usa PostgreSQL + pgvector como base de armazenamento
• GitHub

Como a memória é organizada

• Usa namespace para separar memórias como conhecimento do usuário, do projeto e autoconsciência do agente
• Cada namespace é composto por caminhos hierárquicos; ao ler /projects, os subcaminhos como /projects/stash e /projects/cartona também são incluídos
• As gravações são feitas apenas em um namespace exato, evitando contaminação de memória
• A memória relacionada ao usuário, a memória do projeto e o autoconhecimento sob /self são mantidos sem se misturar
• Exemplos de estrutura: /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences

Diferença em relação ao RAG

• RAG é mais próximo de uma camada de busca que encontra conteúdo relevante em documentos, sem lembrar nem aprender com a própria conversa
• O RAG só consegue lidar com conteúdo que já existe nos documentos e não consegue criar novo conhecimento a partir da conversa
• Rastreamento de metas, compreensão de intenção, detecção de contradições ao longo do tempo e raciocínio sobre causa e efeito são apresentados como algo fora do escopo do RAG
• O Stash aprende automaticamente com conversas, decisões, sucessos e fracassos, construindo um grafo de conhecimento
• Como busca em documentos e memória de experiências tratam problemas diferentes, RAG e Stash podem ser usados juntos

O que o diferencia da memória de IA existente

• Claude.ai e ChatGPT também têm memória, mas esse recurso está vinculado à própria plataforma e ao próprio modelo
• O Stash funciona de forma independente de modelo, podendo ser conectado também a modelos locais e privados
• A propriedade dos dados fica com o usuário, e o projeto é oferecido como open source
• Inclui itens como consolidação em background, rastreamento de goals e intent, aprendizado com failures, causal reasoning e self-model do agente
• Na tabela comparativa, ChatGPT Memory e Claude.ai Memory aparecem como “notepad”, enquanto o Stash é descrito como “mind”

Problema que ele tenta resolver

• Os modelos de IA atuais até raciocinam bem, mas não têm memória entre sessões, então o usuário precisa repetir sempre o próprio contexto e o histórico do projeto
• Colocar todo o histórico da conversa no prompt toda vez é lento e caro, além de continuar sujeito ao limite da context window
• Falta um mecanismo de transmissão de lições que impeça repetir, na sessão seguinte, tentativas que já falharam
• Como recursos de memória existem apenas como funções exclusivas de algumas plataformas, agentes customizados e LLMs locais acabam começando sem contexto desde o início

Pipeline de consolidação

• Um processo em background continua sintetizando experiências e transformando memória bruta em conhecimento estruturado
• Na etapa Episodes, as observações são armazenadas em modo append-only
• Na etapa Facts, grupos de episodes são sintetizados por um LLM
• Na etapa Relationships, relações entre entidades presentes nos facts são extraídas
• Na etapa Causal Links, pares de causa e efeito entre facts são conectados
• Na etapa Patterns, são derivados padrões abstratos de nível mais alto
• Na etapa Contradictions, são realizados autoajuste e confidence decay
• Com Goal Inference, fatos sobre metas ativas são rastreados automaticamente, revelando progresso e conflitos
• Com Failure Patterns, erros recorrentes são detectados e extraídos como novos fatos, reduzindo a repetição das mesmas falhas
• Com Hypothesis Scan, novas evidências podem confirmar ou rejeitar hipóteses em aberto sem intervenção manual

Integração com MCP

• Funciona de forma nativa com MCP e pode ser conectado a Claude Desktop, Cursor, OpenCode, agentes customizados, LLMs locais e outros clientes MCP
• Pode ser conectado sem SDK e permite usar a mesma camada de memória em qualquer lugar, sem vendor lock-in
• Oferece um total de 28 ferramentas, incluindo remember, recall, forget, init, além de causal links, contradictions e hypotheses
• ./stash mcp execute --with-consolidation inicia junto o servidor MCP via stdio e a consolidação
• ./stash mcp serve --port 8080 --with-consolidation pode subir um servidor SSE para agentes remotos

Self-model do agente

• Ao chamar init, é criada a estrutura base do namespace /self, iniciando a composição do self-model
• Em /self/capabilities, o agente registra o que faz bem para usar isso no planejamento das tarefas
• Em /self/limits, armazena registros de falhas e fraquezas para evitar repetir os mesmos erros
• Em /self/preferences, aprende os modos de operação que funcionam melhor, moldando seu estilo de trabalho no longo prazo

Loop de aprendizado autônomo

• Ao rodar um research loop a cada 5 minutos, ele recupera o contexto atual a partir de memórias passadas, escolhe temas por conta própria, investiga, cria novas conexões, consolida tudo de novo e encerra
• Na etapa Orient, traz contexto passado, metas ativas, hipóteses em aberto e falhas anteriores
• Na etapa Research, o agente faz buscas na web sobre temas escolhidos por ele mesmo
• Na etapa Think, evidencia tensões, lacunas e contradições dentro do que sabe no momento
• Na etapa Invent, cria novos resultados como hipóteses, padrões e descobertas
• Na etapa Consolidate, executa o pipeline para sintetizar episodes brutos em conhecimento estruturado
• Na etapa Reflect + Sleep, registra um resumo da sessão, define o contexto para a próxima execução e então para
• Ver prompt do loop

Compatibilidade com modelos e infraestrutura

• Parte do princípio de uma única configuração de provider usando API compatível com OpenAI tanto para embedding quanto para reasoning
• Afirma oferecer suporte a configurações em nuvem, local e self-hosted, sem vendor lock-in
• Informa que está sendo usado com OpenRouter em ambiente local, permitindo acessar centenas de modelos com uma única chave de API
• Também funciona diretamente com Ollama, permitindo montar uma memória offline com modelos locais como Qwen, Llama e Mistral
• Também cita como compatíveis backends que usam o formato de API da OpenAI, como vLLM, LM Studio, llama.cpp server, Together AI e Groq
• O modelo de embedding padrão é openai/text-embedding-3-small, usando STASH_VECTOR_DIM=1536 nessa combinação
• STASH_VECTOR_DIM só pode ser definido antes da primeira execução; depois da inicialização, alterá-lo exige resetar todo o banco de dados

Informações de implantação e uso

• Fornece uma configuração com Docker Compose para subir Postgres, pgvector e Stash juntos
• O procedimento de execução é apresentado em 3 etapas: clonar o repositório, copiar .env.example para .env, configurar a chave de API e os modelos, e executar docker compose up
• Após a execução inicial, espera-se que Postgres + pgvector estejam prontos, as migrations tenham sido aplicadas, o servidor MCP esteja aguardando e a consolidação em background esteja em execução
• O projeto é disponibilizado sob licença Apache 2.0
• GitHub Repository
• alash3al.com

[GN⁺]

Comentários do Hacker News

• Cliquei achando que finalmente tinham tornado algo como o sistema de memória do Claude.ai portátil, mas não é nada disso
  O que há aqui é só um esquema de store/remember, e o que me pareceu melhor foi a abordagem em que um modelo em segundo plano resume o histórico do chat para criar memória
  Nesse caso funciona muito melhor porque o próprio modelo não precisa escrever a memória diretamente, então apresentar isso como se estivesse no mesmo nível do Claude.ai parece meio misleading
  Eu também sigo procurando um sistema de memória desse tipo para migrar para algo como LibreChat, mas ainda não encontrei, e esse recurso é praticamente o único motivo de eu ainda continuar no Claude.ai
  E, só para constar, esse sistema existe apenas no Claude.ai, não no Claude Code

  • Segundo o recente vazamento do Claude Code, havia algo chamado autoDream, descrito ali como um motor de consolidação de memória em segundo plano: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
  • Eu realmente gostaria de usar essa abordagem
    Minha experiência é o oposto: criei https://github.com/flippyhead/ai-brain principalmente para mim mesmo, e alguns amigos também usam
    Até agora, usar CLAUDE.md para fazer a IA encontrar memórias relevantes e pensar em quando e como armazená-las tem funcionado bem
    Essa abordagem permite criar estrutura por prioridade e deixar notas para o futuro, então parece bem diferente de simplesmente resumir tudo
  • Eu prefiro que o recall automático funcione de forma invisível para o agente
    A criação de memória também funciona bem via tool call, e acho aceitável gerar memórias automaticamente durante a compressão de contexto
    Mas, se a geração for automática, então é preciso consolidação assíncrona, e chamar isso de dreaming me parece um exagero
    Minha implementação está no Elroy.bot, e reuni várias abordagens aqui: https://tombedor.dev/approaches-to-agent-memory/
  • Fico curioso sobre como fazer benchmark disso
    Se você extrai memória em segundo plano, o problema é que fica difícil alinhar bem com o prefix cache
    Mesmo um LOG.md simples em duas camadas (log detalhado de tarefas e aprendizados) + MEMORY.md (registro dos itens promovidos quando o log é cortado) + um stop hook executado no fim do turno já leva bem longe
  • Esse conceito é bem interessante
    Parece uma estrutura em que existem auxiliares por trás do agente que conversa com o usuário, espionando a conversa, anotando fatos importantes ou buscando fatos relacionados no banco e interrompendo com algo como esta memória X parece relevante
    Se tokens fossem grátis, isso pareceria fácil, mas fazer isso de forma eficiente é um problema bem interessante

• Projetos que prometem algo sem praticamente revelar como implementam sempre me parecem um grande sinal de alerta
  Cavando mais, isso é basicamente pg_vector com mcp e duas funções, recall/remember
  No fim, é algo mais próximo de RAG, e dá até para argumentar que a estrutura de dados importa, mas quase todos esses sistemas de memória até hoje funcionaram de forma muito parecida
  Ainda não vi nenhum caso que prove que a busca ficou melhor do que uma busca básica em vector DB

  • O site é bonito, está escrito memory, e o LLM é ruim, mas este produto resolve tudo magicamente
    Se realmente fizer isso, no fim acaba sendo mais ou menos uma vectordb embalada de forma elegante

• Já existe uma review: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
  Muitos outros sistemas de memória para LLM também estão reunidos aqui: https://zby.github.io/commonplace/agent-memory-systems/
  E aqui há um resumo do que eu gostaria de ver nesses sistemas: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

• Esses sistemas de memória para agentes parecem ao mesmo tempo projetados demais e projetados de menos, e dão a impressão de ser meio um beco sem saída
  É difícil imaginar uma realidade em que isso não se desalinhe rapidamente do que os modelos mais novos precisam e não apodreça logo
  Por exemplo, só porque você implementou pagamento uma vez, sessões futuras podem ficar tendendo para pagamento por causa de uma memória como don't use stripe

  • Pior ainda é que o próprio autor quase não dá sinais de ter usado isso de verdade
    Parece uma camada de memória completamente não comprovada, com um site de marketing chamativo e afirmações exageradas, mas sem capturas de uso real
  • Eu vejo isso como um problema de informação e fiz uma pequena ferramenta intencionalmente pensada para não armazenar a maior parte das coisas: https://github.com/skorokithakis/gnosis
    A premissa é simples. O que o LLM já sabe, ele continuará sabendo, então eu não armazeno o que o LLM disse, e o que é relacionado a código deve ficar no próprio código e nos comentários
    Em vez disso, existem coisas que não são nenhuma dessas duas e ainda assim quase nunca são capturadas
    Ao construir algo, muitas vezes o que você decidiu não fazer é mais importante do que o que você realmente fez, e essa ferramenta captura as alternativas descartadas no fim da sessão e os motivos, salvando isso como system knowledge
    No fim, quero registrar informação que não dá para encontrar só com grep no código e que normalmente fica apenas na cabeça dos colegas, e até agora isso tem funcionado bem, embora ainda seja cedo
  • Eu uso um sistema de memória sob medida que evita esse problema transformando cada memória em um espaço de busca por contexto
    Uma memória como don't use stripe só entra no contexto quando o modelo recebe um prompt para fazer algo relacionado a payment processing

• Eu vinha procurando algo assim há tempos e foi bom ver uma conta que já publicava software desde antes do boom de LLMs
  Mas eu gostaria que todo projeto trouxesse algo como um histórico de uso de LLM
  Seria bom ter informações sobre se foi gerado com LLM, e, se foi, quanto, em que etapas foi usado, quão cuidadosamente a saída foi revisada, e se a pessoa sente que a qualidade ficou pelo menos igual ou melhor do que se tivesse feito sozinha
  Não é para desconfiar de uma pessoa específica; eu gostaria que isso existisse em todos os projetos, e pretendo fazer o mesmo

  • Sinceramente, isso soa meio presunçoso
    Ninguém está forçando ninguém a usar esse projeto; basta ler e revisar o código por conta própria e decidir se quer usá-lo ou não
  • A pergunta em si é válida, mas não acho que dê para deixar a resposta apenas na base de autodeclaração
    Não parece provável que muita gente vá admitir honestamente que quase não pensou no design, mal testou e o código ficou ruim
    Talvez o que falte seja um sistema de terceiros para responder esse tipo de pergunta, embora, claro, se ele também for baseado em LLM, pode acabar sendo bem subjetivo
  • Há muitas maneiras diferentes de construir software com LLM
    Hoje em dia, eu toco a maioria dos projetos em torno de vários arquivos Markdown, usando IA para pesquisar primeiro, planejar e acompanhar o progresso da implementação
    A implementação segue o plano, passo a passo, com revisão contínua em cada etapa
    Se eu tivesse que documentar meu workflow, esses arquivos já seriam isso
    99% do código é gerado, mas eu me esforço para que ele seja gerado da forma como eu quero, e muitas vezes sinto que o resultado fica melhor do que se eu tivesse feito tudo sozinho
  • Não vejo por que isso seria importante
    Software bom e software ruim podem ser feitos tanto sem LLM quanto com LLM
    Ninguém pergunta a um carpinteiro se ele usou martelo ou nail gun, nem o que usou no telhado e no deck
    Se não houver uma base de confiança, no fim você mesmo tem que verificar a qualidade ou simplesmente fazer tudo por conta própria; o resto é mais esperança do que outra coisa

• Ainda não encontrei uma memória realmente útil
  Um extremo é deixar só resumos de alto nível, como em agents.md, o que não ajuda muito com detalhes concretos, como se você alterar este elemento, precisa marcar aquele outro como draft
  No outro extremo, abordagens detalhadas demais acabam ignoradas por excesso de minúcia, ou contaminam alterações em outras áreas com detalhes de uma única funcionalidade
  No fim, o que mais funcionou até agora foi não usar memória e selecionar manualmente apenas o contexto importante para aquela sessão/prompt

  • Tenho bastante interesse em memória, mas pelo menos para ferramentas de programação não a considero tão útil
    A source of truth sobre o que o repositório faz e deve fazer continua sendo o próprio repo
    O que você descreveu soa mais como diretrizes de code review, e isso pode ser colocado explicitamente no contexto no momento de uma mudança
    Sistemas de memória são complexos demais para isso e ainda por cima menos precisos
  • Há uma lista de desejos para esse tipo de sistema aqui: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
  • Eu sinto algo parecido
    Fico pensando se um dia esses modelos terão aprendizado contínuo
    Eles já são inteligentes o suficiente, mas a falta de memória real faz com que sejam incômodos de usar
  • As memórias que o Claude criou para mim eram quase todas do tipo remember-to-not-forget, então acabei desativando o recurso

• Para mim, algumas coisas simples têm funcionado bem, no caso de usar o Codex

  1. uma especificação funcional detalhada e sempre atualizada
  2. uma base de código estruturada em vários projetos
  3. código com bons nomes e boa documentação. Nomes de classes, variáveis e funções devem deixar o propósito claro, por mais longos ou engraçados que pareçam, e esse tipo de regra eu coloco nas diretrizes de codificação do Agent.md
     Minha especificação funcional faz o papel de Project.md para o agente
     E, antes de cada code review agentic, eu gero a árvore de diretórios do projeto, junto isso com a base de código em um único arquivo e adiciono um timestamp ao nome do arquivo
     Isso é surpreendentemente importante porque reduz os casos em que o LLM referencia versões antigas e também facilita ver diffs rapidamente sem precisar enviar o git em si
     Até agora, esse workflow simples tem funcionado muito bem mesmo em codebases grandes e complexas
     A eficiência em tokens não é boa, mas simplesmente funciona
     Não é preciso juntar a codebase inteira toda vez; você pode excluir projetos que já terminaram, já foram testados ou não têm relação com o trabalho atual
     Ainda assim, eu os incluo na árvore de diretórios impressa, para que o agente pelo menos saiba que existem e possa pedir arquivos específicos, se necessário
  • Abordagem interessante
    Fiquei curioso sobre como você faz essa mesclagem
    É manual, junta apenas arquivos alterados, ou é um modelo híbrido?

• Memória para LLM parece boa na teoria, mas na prática, quanto maior fica, mais bagunçada se torna, quase tanto quanto trabalhar sem memória
  Como no exemplo da tela inicial, você pode dizer continue trabalhando no meu projeto, mas na realidade é raro alguém tocar um projeto só
  Dá para ter 5 ou 10 projetos na memória, e todos provavelmente faziam sentido quando foram armazenados
  No fim, você acaba tendo que especificar de novo, tipo continue o projeto sass, ganha um pouco de contexto detalhado, mas ao custo de preencher o contexto do LLM e pagar chamadas extras de MCP

  • É verdade, mas isso é uma implementação ingênua demais
    Uma implementação bem feita talvez consiga superar essas limitações
  • No momento em que você começa a especificar em detalhes o que deve ser lembrado, isso já fica quase igual a mandar a IA fazer write/read em arquivos

• Fico pensando se isso não é só para vibecoders que trabalham sozinhos
  Quando há pessoas reais e projetos reais, esse sistema não pode ter a memória completa do projeto, e eu também não tenho essa memória completa
  Se outro PR for mergeado, a memória que eu tenho já fica desatualizada, e o que me importa é só o meu ticket
  Então estou cada vez mais achando que isso talvez não seja uma ferramenta para esse tipo de trabalho colaborativo

• Agora que o custo de fazer software caiu praticamente para quase zero, ainda me surpreende que tentem vender algo assim com um site de marketing vibe-coded
  Quem vai ter tempo de testar isso e esperar semanas ou meses para ver se realmente funciona?
  Não há em nenhum lugar do site uma prova de que isso seja melhor do que RAG, ou melhor do que uma simples pasta de arquivos de memória com grep
  Mesmo assim, só fazem afirmações grandiosas, e a rolagem ainda engasga a 14 fps
  Isso parece algo codado 24 horas atrás e, sinceramente, passa uma sensação de pura preguiça