Stash - Capa de memoria persistente para agentes de IA

• Una capa de memoria persistente que mantiene la continuidad de conversaciones y contexto de trabajo incluso cuando cambia la sesión; guarda observaciones crudas como episodes y luego las acumula como conocimiento estructurado
• Usa una arquitectura independiente del modelo, por lo que Claude, GPT, LLM locales y agentes personalizados pueden conectarse a la misma capa de memoria; el almacenamiento funciona sobre PostgreSQL y pgvector
• Cumple un rol distinto al de RAG: no se limita a recuperar documentos, sino que acumula hechos, relaciones, metas, fallas e hipótesis surgidas de la conversación, y puede usarse junto con RAG
• Separa la memoria de usuarios, proyectos y autoconocimiento del agente mediante namespaces y rutas jerárquicas, y con un pipeline de consolidación sigue sintetizando facts, relationships, causal links, patterns y contradictions
• Incluye integración nativa con MCP, un modelo de sí mismo basado en /self e incluso bucles iterativos de investigación para convertir agentes sin memoria entre sesiones en actores de trabajo con continuidad a largo plazo

---

Resumen de Stash

• Una capa de memoria persistente situada entre los agentes de IA y el mundo exterior, que permite conservar el contexto previo aunque cambie la sesión
• Guarda observaciones crudas como episodes y las acumula como conocimiento estructurado, como facts, relationships, patterns, goals, failures e hypotheses
• No reemplaza al modelo en sí, sino que refuerza la continuidad, y está diseñado para poder conectarse a cualquier agente, como Claude, GPT o modelos locales
• Usa PostgreSQL + pgvector como base de almacenamiento
• GitHub

Cómo se organiza la memoria

• Usa namespace para separar memorias como las de usuarios, proyectos y autoconocimiento del agente
• Cada namespace se compone de rutas jerárquicas; si se lee /projects, también se incluyen subrutas como /projects/stash y /projects/cartona
• Las escrituras se registran solo en un namespace exacto para evitar la contaminación de memoria
• La memoria relacionada con usuarios, la memoria de proyectos y el autoconocimiento bajo /self se mantienen separadas y sin mezclarse
• La estructura de ejemplo incluye /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences

Diferencias con RAG

• RAG se parece más a una capa de recuperación que busca contenido relevante en documentos, y no recuerda ni aprende de la conversación en sí
• RAG solo puede trabajar con contenido que ya está dentro de los documentos, y no puede crear conocimiento nuevo a partir de la conversación
• El seguimiento de metas, la comprensión de intención, la detección de contradicciones a lo largo del tiempo y el razonamiento sobre causa y efecto se presentan como capacidades fuera del alcance de RAG
• Stash aprende automáticamente de conversaciones, decisiones, éxitos y fracasos, y va construyendo un grafo de conocimiento
• La recuperación de documentos y la memoria de experiencias resuelven problemas distintos, así que RAG y Stash pueden usarse juntos

Qué lo diferencia de otras memorias para IA

• Claude.ai y ChatGPT también tienen memoria, pero esa función está atada a su propia plataforma y su propio modelo
• Stash funciona de forma independiente del modelo y también puede conectarse a modelos locales y privados
• La propiedad de los datos permanece del lado del usuario y se ofrece como open source
• Incluye elementos como consolidación en segundo plano, seguimiento de goals e intent, aprendizaje de failures, causal reasoning y self-model del agente
• Según la tabla comparativa, ChatGPT Memory y Claude.ai Memory se clasifican como “notepad”, mientras que Stash se describe como “mind”

Problema que busca resolver

• Los modelos de IA actuales pueden razonar bien, pero no tienen memoria entre sesiones, así que el usuario tiene que volver a explicar su contexto y el de su proyecto cada vez
• El método de meter siempre historiales largos de conversación dentro del prompt es lento y costoso, y además sigue sujeto al límite de la context window
• Falta un mecanismo para transmitir lecciones que impida repetir en la siguiente sesión intentos fallidos del pasado
• Las funciones de memoria solo existen como capacidades exclusivas de algunas plataformas, por lo que agentes personalizados y LLM locales terminan empezando sin contexto desde cero

Pipeline de integración

• Un proceso en segundo plano sigue sintetizando experiencias para convertir la memoria cruda en conocimiento estructurado
• En la etapa de Episodes, las observaciones se guardan en modo append-only
• En la etapa de Facts, grupos de episodes se sintetizan con un LLM
• En la etapa de Relationships, se extraen relaciones entre entidades a partir de los facts
• En la etapa de Causal Links, se conectan pares de causa y efecto entre facts
• En la etapa de Patterns, se derivan patrones abstractos de nivel superior
• En la etapa de Contradictions, se realiza autocorrección y confidence decay
• Con Goal Inference, se rastrean automáticamente hechos relacionados con metas activas y se exponen avances y conflictos
• Con Failure Patterns, se detectan errores repetidos y se extraen como nuevos facts para reducir la repetición de la misma falla
• Con Hypothesis Scan, nueva evidencia puede confirmar o descartar hipótesis abiertas sin intervención manual

Integración con MCP

• Funciona de forma nativa con MCP y puede conectarse con Claude Desktop, Cursor, OpenCode, agentes personalizados, LLM locales y otros clientes MCP
• Puede conectarse sin SDK y permite usar la misma capa de memoria en cualquier entorno sin vendor lock-in
• Ofrece un total de 28 herramientas, incluyendo desde remember, recall, forget e init hasta causal links, contradictions e hypotheses
• Con ./stash mcp execute --with-consolidation se puede iniciar junto con la consolidación un servidor MCP por stdio
• Con ./stash mcp serve --port 8080 --with-consolidation se puede levantar un servidor SSE para agentes remotos

Modelo propio del agente

• Al llamar a init, se crea la estructura base del namespace /self y comienza la construcción del modelo propio del agente
• En /self/capabilities, el agente recuerda en qué tareas es bueno y usa eso para planificar trabajo
• En /self/limits, guarda historial de fallas y debilidades para evitar repetir los mismos errores
• En /self/preferences, aprende las formas de operar que mejor le funcionan y así forma su estilo de trabajo a largo plazo

Bucle de aprendizaje autónomo

• Si se ejecuta un research loop cada 5 minutos, el sistema recupera el contexto actual desde memorias previas, elige por sí mismo un tema para investigar, crea nuevas conexiones, vuelve a consolidar y luego termina
• En la etapa de Orient, recupera contexto pasado, metas activas, hipótesis abiertas y fallas anteriores
• En la etapa de Research, el agente realiza búsquedas web sobre un tema que él mismo eligió
• En la etapa de Think, expone tensiones, vacíos y contradicciones dentro de lo que sabe actualmente
• En la etapa de Invent, produce nuevos resultados como hipótesis, patrones y descubrimientos
• En la etapa de Consolidate, ejecuta el pipeline para sintetizar episodes crudos en conocimiento estructurado
• En la etapa de Reflect + Sleep, deja un resumen de la sesión, prepara el contexto para la siguiente ejecución y luego se detiene
• Ver prompt del loop

Compatibilidad con modelos e infraestructura

• Parte de una sola configuración de provider que usa una API compatible con OpenAI tanto para embeddings como para razonamiento
• Indica soporte para configuraciones en la nube, locales y self-hosted, y afirma que no hay vendor lock-in
• Señala que actualmente se usa conectándolo localmente con OpenRouter, lo que permite acceder a cientos de modelos con una sola API key
• También funciona directamente con Ollama, y permite montar una memoria offline con modelos locales como Qwen, Llama y Mistral
• También figuran como compatibles backends que usan el formato de la API de OpenAI, como vLLM, LM Studio, llama.cpp server, Together AI y Groq
• El modelo de embeddings por defecto es openai/text-embedding-3-small, y en esa combinación se usa STASH_VECTOR_DIM=1536
• STASH_VECTOR_DIM solo puede configurarse antes de la primera ejecución; si se cambia después de inicializar, hace falta reiniciar toda la base de datos

Información de despliegue y uso

• Se ofrece una configuración con Docker Compose para levantar juntos Postgres, pgvector y Stash
• El procedimiento de ejecución se presenta en tres pasos: clonar el repositorio, copiar .env.example como .env, configurar API key y modelos, y ejecutar docker compose up
• Tras la primera ejecución, se espera que Postgres + pgvector estén listos, que se apliquen las migraciones, que el servidor MCP quede en espera y que la consolidación en segundo plano esté corriendo
• El proyecto se publica bajo licencia Apache 2.0
• GitHub Repository
• alash3al.com

[GN⁺]

Opiniones de Hacker News

• Hice clic pensando que por fin habían hecho algo como el sistema de memoria de Claude.ai pero portable, y para nada era eso
  Lo que hay aquí es simplemente un enfoque de store/remember, y lo que a mí me pareció mejor fue el enfoque donde un modelo en segundo plano resume el historial de chat para crear memoria
  En ese caso funciona mucho mejor porque el modelo no tiene que escribir la memoria por sí mismo, así que presentarlo como si estuviera al nivel de Claude.ai me parece algo engañoso
  Yo también he seguido buscando un sistema de memoria de ese estilo para moverme a algo como LibreChat, pero todavía no encuentro uno, y casi la única razón por la que sigo en Claude.ai ahora mismo es esa función
  Por cierto, ese sistema solo está en Claude.ai, no en Claude Code

  • Según el reciente leak de Claude Code, existía algo llamado autoDream, descrito ahí como un motor de consolidación de memoria en 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
  • De verdad me gustaría probar ese enfoque
    Mi experiencia ha sido justo la contraria, así que hice https://github.com/flippyhead/ai-brain principalmente para mí, y unos cuantos amigos también lo usan
    Hasta ahora, hacer que la IA busque memorias relevantes mediante CLAUDE.md y piense cuándo y cómo guardarlas ha funcionado bastante bien
    Este enfoque permite construir estructura según prioridades y también dejar notas para el futuro, así que se siente bastante distinto a simplemente resumirlo todo
  • Yo prefiero que el recall automático funcione sin que el agente lo vea
    La generación de memoria también funciona bastante bien como tool call, y me parece bien generar memoria automáticamente durante la compresión de contexto
    Pero si va a ser automática, sí hace falta una consolidación asíncrona, y llamarle dreaming me parece un poco exagerado
    Mi implementación está en Elroy.bot, y reuní varios enfoques aquí: https://tombedor.dev/approaches-to-agent-memory/
  • Me da curiosidad cómo se benchmarkea eso
    Si extraes memoria en segundo plano, el problema es que cuesta hacer que encaje bien con la prefix cache
    Incluso una LOG.md simple de dos niveles (registro detallado de trabajo y aprendizajes) + MEMORY.md (registro de elementos promovidos cuando el log se recorta) + un stop hook que corre al final de cada turno puede llevarte bastante lejos
  • El concepto es bastante interesante
    Se siente como si hubiera asistentes detrás del agente que habla con el usuario, escuchando la conversación, anotando hechos importantes o buscando hechos relacionados en la DB, y luego interrumpieran con un esta memoria X parece relevante
    Si los tokens fueran gratis, parecería fácil, pero hacerlo de manera eficiente es un problema bastante interesante

• Un proyecto que promete cosas sin revelar casi nada de cómo está implementado siempre me parece una gran red flag
  Si escarbas más, básicamente es pg_vector con mcp y dos funciones, recall/remember
  Al final se parece más a RAG, y aunque puedes argumentar que la estructura de datos importa, casi todos estos sistemas de memoria que han salido hasta ahora han funcionado de manera muy parecida
  Todavía no he visto ningún caso que demuestre que la recuperación realmente mejoró más allá de una búsqueda básica en vector DB

  • El sitio se ve bien, dice memory, y te pinta que los LLM son malos pero que este producto lo resuelve mágicamente
    Si de verdad hace eso, entonces al final igual se acerca bastante a un vectordb presentado de forma elegante

• Ya hay una reseña: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
  Aquí también están reunidos muchos otros LLM memory systems: https://zby.github.io/commonplace/agent-memory-systems/
  Y aquí está resumido lo que se le puede pedir a este tipo de sistemas: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

• Estos agent memory systems parecen sobreingenierizados y al mismo tiempo insuficientemente diseñados, y se ven bastante como un callejón sin salida
  Me cuesta imaginar una realidad en la que no terminen desalineados con lo que necesitan los modelos más recientes y se echen a perder rápido
  Por ejemplo, si una vez implementaste pagos, luego una memoria como don't use stripe podría hacer que varias sesiones futuras se inclinen una y otra vez hacia el tema de pagos

  • Peor aún, casi no hay señales de que el propio autor lo haya usado realmente
    Es una capa de memoria completamente no probada, y da la impresión de una web de marketing vistosa con afirmaciones exageradas y sin capturas reales
  • Yo veo esto como un problema de información, y por eso hice una utilidad pequeña que está pensada para no guardar la mayoría de las cosas: https://github.com/skorokithakis/gnosis
    La premisa es simple. Lo que el LLM ya sabe, lo seguirá sabiendo, así que no guardo lo que diga el LLM, y lo relacionado con el código debe quedar en el código y los comentarios
    En cambio, hay cosas que no son ninguna de esas dos y que aun así nunca quedan capturadas
    Cuando construyes algo, muchas veces lo que decidiste no hacer importa más que lo que sí hiciste, y esta utilidad al final de la sesión captura alternativas descartadas y las razones, y las guarda como system knowledge
    Al final lo que quiero es conservar información que no puedes encontrar solo con grep en el código, sino que normalmente solo existe en la cabeza de tus compañeros, y hasta ahora ha funcionado bastante bien, aunque todavía es temprano
  • Yo uso un sistema de memoria a medida hecho por mí, y evito este problema convirtiendo todas las memorias en espacios de búsqueda por contexto
    Una memoria como don't use stripe solo entra al contexto cuando el modelo recibe un prompt para trabajar en algo relacionado con payment processing

• Llevo tiempo buscando algo así, y me da gusto ver que la cuenta ha publicado software desde antes del boom de los LLM
  Aun así, me gustaría que los proyectos incluyeran algo como un historial de uso de LLM
  Me gustaría saber si fue generado con LLM, y si sí, cuánto se usó, en qué etapas, qué tan cuidadosamente se revisó la salida, y si sienten que la calidad fue al menos igual o mejor que haciéndolo solos
  No es por sospechar de una persona en particular; me gustaría que fuera algo común a todos los proyectos, y yo también pienso hacerlo

  • La verdad, eso suena un poco entitled
    Nadie te está obligando a usar este proyecto; puedes leer y revisar el código por tu cuenta y decidir si te sirve o no
  • La pregunta en sí es válida, pero no creo que se pueda dejar que la responda solo la autodeclaración de la persona involucrada
    No me imagino a mucha gente admitiendo honestamente que casi no pensó el diseño, que casi no hizo pruebas y que la calidad del código no es muy buena
    De hecho, tal vez haría falta un sistema de terceros que intentara responder ese tipo de preguntas, aunque claro, si también está basado en LLM podría ser bastante subjetivo
  • Hay muchísimas formas distintas de construir software con LLM
    Yo últimamente llevo la mayoría de mis proyectos alrededor de varios archivos Markdown, usando IA primero para investigar, planear y seguir el avance de la implementación
    La implementación se hace por etapas según el plan, y en cada etapa sigo revisando
    Si me pidieras documentar mi workflow, esos archivos serían justamente eso
    El 99% del código es generado, pero me preocupo por que se genere de una forma que me deje satisfecho, y muchas veces siento que el resultado incluso es mejor que si lo hubiera hecho yo solo
  • No me queda claro por qué eso sería importante
    Se puede hacer buen software y mal software tanto sin LLM como con LLM
    No le preguntas a un carpintero si usó martillo o nail gun, ni qué usó para el techo y qué para la terraza
    Si no hay una base de confianza, al final igual tienes que verificar la calidad tú mismo o hacerlo por tu cuenta, y cualquier otra cosa se parece más a una esperanza optimista

• Todavía no he encontrado una memory realmente útil
  Una opción deja solo resúmenes de alto nivel como agents.md, así que no ayuda mucho con detalles concretos, por ejemplo algo como si modificas este elemento, también debes marcar aquel como draft
  Por otro lado, un enfoque demasiado detallado se pasa de específico, termina siendo ignorado, o contamina cambios en otras áreas con detalles de una sola funcionalidad
  Al final, lo que mejor me ha funcionado hasta ahora ha sido sin memoria, eligiendo manualmente solo el contexto importante para esa sesión o prompt

  • Me interesa bastante el tema de la memoria, pero al menos para herramientas de programación no me parece tan útil
    La fuente de verdad sobre qué hace un repositorio y qué debería hacer sigue siendo el propio repo
    Lo que estás describiendo se parece más bien a lineamientos de code review, y ese tipo de cosas se pueden meter de forma explícita en el contexto en el momento del cambio
    Comparado con eso, un sistema de memoria es demasiado complejo y además menos preciso
  • Aquí hay una wishlist para este tipo de sistemas: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
  • Yo siento algo parecido
    Me pregunto si algún día estos modelos tendrán continual learning
    Ya son lo bastante inteligentes, pero como no tienen memoria real, se sienten incómodos de manejar
  • Casi toda la memoria que me generó Claude era del tipo remember-to-not-forget, así que terminé desactivando la función

• A mí me han funcionado bastante bien algunas cosas simples, con herramientas basadas en Codex

  1. Una functional specification detallada y siempre actualizada
  2. Una base de código estructurada en varios proyectos
  3. Código bien nombrado y documentado. Los nombres de clases, variables y funciones, por largos o ridículos que se vean, tienen que dejar claro su propósito, y ese tipo de reglas las pongo en las guías de codificación de Agent.md
     Mi functional spec hace para el agente el papel de Project.md
     Y antes de cada agentic code review genero el árbol de directorios del proyecto, luego lo convierto en un solo archivo junto con la base de código, y le agrego un timestamp al nombre del archivo
     Esto resulta sorprendentemente importante porque reduce la probabilidad de que el LLM haga referencia a una versión vieja, y además sirve para ver diffs rápido sin tener que mandar git
     Hasta ahora este workflow simple me ha funcionado bastante bien incluso en codebases grandes y complejas
     No es eficiente en tokens, pero simplemente funciona
     Tampoco hace falta combinar toda la base de código cada vez; puedes dejar fuera proyectos que ya terminaron, ya fueron probados o no tienen relación con lo que estás haciendo ahora
     Aun así, sí los incluyo en el printed directory tree, para que el agente al menos sepa que existen y pueda pedir archivos específicos si los necesita
  • Es un enfoque interesante
    Me da curiosidad cómo haces esa fusión
    Quisiera saber si es manual, si solo fusionas archivos cambiados o si es algo mixto

• La LLM memory suena bien en teoría, pero en la práctica, mientras más crece, más desordenada se vuelve, casi tanto como trabajar sin memoria
  Como en el ejemplo de la portada, puedes decir sigue trabajando en mi proyecto, pero en la vida real rara vez estás en un solo proyecto
  Puede haber 5 o 10 en memoria, y probablemente todos tenían sentido cuando se guardaron
  Al final de todos modos tienes que volver a especificar algo como sigue con el proyecto de sass, y a cambio de un poco de contexto detallado terminas llenando el contexto del LLM y pagando además el costo de más MCP calls

  • Es cierto, pero eso es una implementación naive
    Una implementación bien hecha podría superar ese tipo de limitaciones
  • En el momento en que empiezas a especificar exactamente qué hay que recordar, en la práctica ya casi no hay diferencia con hacer que la IA escriba/lea archivos

• Esto me hace pensar si está hecho solo para vibecoders que trabajan solos
  Cuando trabajas con gente real en proyectos reales, este sistema no puede tener memoria del proyecto completo, y yo tampoco la tengo
  Si se mergea otro PR, los recuerdos que yo tenía ya quedan viejos de inmediato, y a mí lo único que me importa es mi ticket
  Cada vez siento más que esto quizá no es una herramienta para ese tipo de trabajo colaborativo

• Ahora que el costo de hacer software básicamente ya está cerca de cero, me sorprende que todavía intenten vender algo así con una web de marketing vibe-coded
  No sé quién tendría tiempo de probar una cosa de estas y esperar semanas o meses para confirmar si realmente funciona
  En ninguna parte del sitio hay evidencia de que sea mejor que RAG o simplemente que una carpeta de archivos de memoria con grep
  Y aun así está llena de afirmaciones grandiosas, además de que el scroll va trabado a 14fps
  Esto se ve como algo programado hace 24 horas y, siendo sinceros, me parece demasiado flojo