Un desarrollador comunitario (Claudio Drews) lanzó Memory OS hoy, una pila de memoria de 6 capas bajo licencia MIT que se asienta sobre el framework Hermes Agent de NousResearch. Las capas mapean a propósitos de memoria distintos: archivos workspace (MEMORY.md, USER.md, CREATIVE.md inyectados en el system prompt), historial de sesiones (SQLite + FTS5 búsqueda full-text), hechos estructurados (SQLite + HRR + trust scoring con bucles de feedback), Fabric (extracción de sesiones por LLM, forkeado de Icarus Plugin), base de datos vectorial (Qdrant con vectores coseno 4096-dimensionales más BM25 sparse), y un Wiki LLM auto-curado que se re-ingiere de vuelta en Qdrant. Todo corre localmente vía Docker (Qdrant + Redis + ARQ Worker + Python 3.11+); las llamadas LLM van al provider que Hermes soporte (OpenRouter, OpenAI, Anthropic, Ollama).

La arquitectura es un sistema de recuperación en cascada. En pre_llm_call, cuatro fuentes (Fabric, Qdrant, Sessions, Facts) son consultadas con búsqueda híbrida primero, luego vectores densos, luego léxico, luego SQLite como fallback. La deduplicación por sesión detiene el mismo contexto de aparecer dos veces en una ventana, y un umbral de relevancia filtra antes de que nada alcance el modelo. En post_llm_call y on_session_end, la captura escribe de vuelta en las capas. El olvido es explícito: un escáner de decay semanal envejece entradas stale, y la dedup semántica fusiona memorias casi-idénticas cuando la similitud coseno excede 0,92. El trust scoring (capa 3) mantiene un bucle de feedback que ajusta la credibilidad de fuentes en el tiempo. Lo que falta importa: sin benchmarks publicados sobre calidad de recall, latencia, o ahorros de tokens, y sin resolución formal de conflictos de escritura para consistencia multi-agente. El repo está en github.com/ClaudioDrews/memory-os, recién nacido con pocos commits, desarrollador único. Tratar como scaffolding early-stage para la idea de capas, no como componente production-hardened todavía.

Dos hilos de ecosistema. Primero, la arquitectura es una articulación explícita community-built de lo que la mayoría de los builders de agentes terminan ensamblando ad-hoc: un pipeline de memoria en capas donde propósitos diferentes (contexto del sistema, recall de sesión, almacenamiento de hechos, búsqueda semántica, extracción estructurada, acumulación de conocimiento) obtienen mecanismos distintos en lugar de colapsarse en un solo patrón "vector DB y rezar". Esa capa por capa es la lección de diseño que vale la pena llevar incluso si nunca tocas Memory OS directamente. Segundo, el posicionamiento: Memory OS se contrasta explícitamente con servicios cloud como mem0, Zep, y Letta siendo totalmente local. Eso encaja en la ola más amplia de "quiero la memoria de mi agente en mi disco, no en la base de datos de alguien más," que es una postura legítima para builds privacy-sensitive o air-gapped. El trade-off es operacional: una pila Docker con Qdrant + Redis + ARQ Worker es más infraestructura que llamar mem0 vía API. Para builders decidiendo entre memoria cloud-managed y self-hosted, esto pone una opción real del lado local del ledger, aunque framework-bound a Hermes.

Lunes por la mañana, si ya construyes sobre Hermes Agent: Memory OS vale el probar como drop-in upgrade de la memoria nativa de Hermes, especialmente si tu agente se beneficia de recall semántico a través de historias largas. Corre tu propia evaluación sobre calidad de recall y uso de tokens antes de apostar; sin benchmarks publicados significa que tú eres el benchmark. Si no estás en Hermes, la descomposición de 6 capas es el takeaway, no el código: workspace + sesiones + hechos + extracción + vectores + wiki curado mapea a propósitos distintos que probablemente ya necesitas, por separado, en cualquier stack en el que estés. Si despliegas un agente privacy-sensitive o air-gapped y no quieres un provider de memoria cloud, esta es una opción fresca para evaluar contra alternativas establecidas. Single-developer más few-commits-old significa apóyate con cuidado; el valor ahora es la arquitectura como documentación, no el código como dependencia battle-tested.