¿Otro MCP de memoria? Esa no es la memoria que buscas

Estaba considerando construir mi propio sistema de memoria para Claude Code después de unos asuntos iniciales fallidos con MCPs de memoria. En terapia nos animan a pensar sobre cómo pensamos. Una discusión sobre metacognición en un mundo completamente ajeno disparó una idea en mi mundo de trabajo.

El ecosistema de Claude Code está inundado de soluciones de memoria. Claude-Mem, Memsearch, Agent Memory MCP, Cognee, SuperMemory: hay uno nuevo cada semana. Todos hacen más o menos lo mismo: capturar lo que el agente hizo durante una sesión, comprimirlo, guardarlo en una base de datos SQLite o en un vector store y luego volcar los fragmentos relevantes de vuelta en la ventana de contexto la próxima vez.

---

Navegación rápida

Salta directamente a lo que buscas:

La tendencia es memoria | Qué falla en los plugins de memoria | Lo que de verdad necesitaba | Qué son los hooks de Claude Code | Cómo funciona | El problema del sube y baja | Seguimiento de refuerzo | Cómo empezar | A qué estar atento

La tendencia es memoria. ¿Pero es tan simple?

Siempre que estoy trabajando, destilo la sesión en una arquitectura de documentación resumida —lo obvio como claude.md— pero luego documentos extensos sobre arquitectura, esquema de datos, lógica: un área de documentación cuidadosamente gestionada que mantiene la versión actual del proyecto detallada a fondo para consumo del LLM. Para una nueva rama de trabajo podrías simplemente instruirlo para que se familiarice desde la documentación. Un poco como darle un diario para leer antes de empezar a trabajar.

Si la memoria fuera el problema real, las empresas de IA ya lo habrían resuelto. Anthropic, OpenAI, Google: no es que les falten ingenieros, ¿verdad? Los modelos ya aprenden de nuestras entradas, colectivamente, a lo largo de millones de conversaciones. Pero tenemos que esperar a la siguiente release del modelo para beneficiarnos de eso. Y aun así, es genérico. Los patrones de todo el mundo promediados juntos, no los tuyos.

¿Qué falla en los plugins de memoria?

El problema fundamental de los plugins de memoria no son los datos obsoletos ni el coste hinchado de tokens (aunque son problemas reales). Es que tratan la ventana de contexto del agente como un archivador. Cuando empieza una sesión nueva, vuelcan una pila de contexto pasado en el prompt que podría no estar ya actualizada.

Es ese género de problema lo que hace que siempre haya encontrado la memoria algo poco fiable para los errores habituales —sintaxis al ejecutar un script .py—, ese tipo de cosas. Tendrías que instruirlo para que actualizara o leyera algo de la memoria. Claude lo leería, lo reconocería y luego haría exactamente lo mismo tres llamadas a herramienta más tarde. No porque la memoria fuera mala. Sino porque el agente no siente esa información como siente, por ejemplo, un error de sintaxis en las narices.

Hay un término para esto en la literatura de investigación: el «Passive Librarian Problem» (Problema del Bibliotecario Pasivo). El sistema de memoria espera a que el agente decida buscar, extrae un montón de texto y lo vuelca en el contexto. Pero el agente tiene que saber qué olvidó para poder pedirlo. Lo cual es, obviamente, un poco una paradoja.

Lo que de verdad necesitaba

Necesitaba metacognición. Claude necesitaba pensar sobre cómo estaba pensando y Propriocepción: algo más cercano a un sistema nervioso, una conciencia en tiempo real y de bajo nivel del estado operacional. No «esto es lo que hiciste mal el martes pasado», sino «estás dando vueltas en círculos» o «he cometido un error de sintaxis».

No evitas chocar contra las paredes porque algún «Collision Detection Module» escriba un informe sobre un impacto reciente. Las evitas porque tu sistema nervioso te da feedback inmediato, de baja latencia y no verbal sobre dónde está tu cuerpo y qué hay alrededor. Hay un nombre para esto en filosofía: la Extended Mind Thesis (Clark y Chalmers, 1998), la idea de que la cognición no solo ocurre en el cerebro, ocurre en el bucle entre un sistema y su entorno. No vas a chocar contra una pared y, en el contexto de caminar por la calle, no necesitas saber por qué.

Así que construí Metacog. Es un plugin de Claude Code que corre como un par de hooks. Sin dependencias y unas 400 líneas de JavaScript.

¿Qué son los hooks de Claude Code?

Si no estás familiarizado con el sistema de hooks de Claude Code (yo no lo estuve durante mucho tiempo), aquí va la versión corta. Los hooks son comandos de shell que Claude Code ejecuta automáticamente en momentos específicos durante una sesión. No son servidores MCP y no necesitan estar corriendo todo el tiempo. Se disparan, hacen lo suyo y ya está. Piensa en ellos como event listeners del comportamiento del agente.

Hay varios hook events, pero los dos que hacen funcionar Metacog son:

PostToolUse se dispara después de que el agente usa cualquier herramienta: Read, Write, Bash, Grep, lo que sea. Si quieres monitorizar lo que el agente está haciendo en tiempo real, este es tu hook. Metacog lo usa para ejecutar los cinco sentidos propioceptivos después de cada llamada a herramienta.

UserPromptSubmit se dispara cuando envías un mensaje. Metacog lo usa para inyectar reglas de comportamiento aprendidas al inicio de cada sesión: el digest de refuerzo que transporta lecciones de sesiones anteriores.

Lo práctico de los hooks es el formato de salida. Un hook se comunica con Claude escribiendo JSON a stdout:

{
  "continue": true,
  "suppressOutput": false,
  "systemMessage": "This message appears in the agent's context"
}

Si un hook no saca nada y sale limpiamente, es completamente invisible. Coste cero de tokens. Latencia cero. Esto es lo que hace a los hooks fundamentalmente distintos de los servidores MCP para este tipo de trabajo: pueden ser totalmente silenciosos cuando no hay nada que reportar, que es la mayor parte del tiempo.

Metacog se instala vía npx como un par de hooks de Claude Code. El instalador lo gestiona todo: registra ambos hooks, resuelve las rutas de los scripts y actualiza tus ajustes. Un comando: npx @converly/metacog --install

Cómo funciona

Dos hooks. Uno se dispara después de cada llamada a herramienta (ese es el sistema nervioso), el otro se dispara una vez por sesión (el inyector de refuerzo). Cuando todo está normal, ambos producen cero salida y cuestan cero tokens. Cuando algo va mal, una señal corta se inyecta en el contexto del agente. No un comando: solo conciencia. El propio razonamiento del agente decide qué hacer con ella.

Los cinco sentidos

Acabé construyendo cinco sensores propioceptivos, cada uno apuntando a un punto ciego específico con el que seguía tropezando con agentes de programación:

O2 - Tendencia de contexto. El agente no puede ver su propia ventana de contexto llenándose. Este es su punto ciego más crítico: el overflow de contexto dispara la compactación, que borra el trabajo en curso y causa esos bucles infinitos de reintento tan desesperantes. O2 trackea la velocidad de tokens: lo rápido que se consume el contexto comparado con la línea base. Cuando pica (tres lecturas de archivo grandes seguidas, por ejemplo), el agente recibe una señal.

Chronos - Conciencia temporal. Los agentes no tienen sentido del tiempo. Ninguno en absoluto. Una tarea de 45 minutos se siente idéntica a una de 2 minutos. Chronos trackea el tiempo de reloj y el conteo de pasos desde la última interacción del usuario. Después de 15 minutos o 25 llamadas a herramienta sin un mensaje del usuario, el agente recibe un empujón.

Nocicepción - Fricción de errores. Los errores individuales son visibles para el agente, pero el patrón de fallo repetido no lo es, y ahí está el problema realmente grave. Tres errores similares consecutivos dispara una señal. El mismo error repetido significa que está atascado. Errores distintos significa que está explorando. Esa distinción importa mucho.

Espacial - Radio de impacto. El agente solo ve el archivo que está editando ahora mismo. No tiene visión periférica de cómo los cambios se propagan por el resto del codebase. Después de una escritura de archivo, Metacog cuenta cuántos otros archivos importan el módulo modificado. Si son 14 archivos, el agente debería probablemente saberlo antes de empezar a refactorizar.

Vestibular - Diversidad de acciones. El agente puede entrar en bucles silenciosos —repitiendo las mismas búsquedas, leyendo los mismos archivos, ejecutando los mismos comandos— sin darse cuenta de que va en círculos. Vestibular lo detecta y rompe el bucle.

Tres capas de respuesta

Capa 1: Propriocepción: siempre activa, coste casi cero. Calcula los cinco sentidos después de cada llamada a herramienta. La mayoría de turnos: completamente silenciosa. Solo se dispara cuando los valores se desvían de la línea base.

[Proprioception]
Context filling rapidly - 3 large file reads in last 5 actions.
Consider summarising findings before proceeding.

Capa 2: Nocicepción: se dispara cuando los umbrales de la Capa 1 se vuelven críticos. Esta es la respuesta de dolor. Fuerza un cambio cognitivo con intervenciones escaladas. Primera vez: cuestionamiento socrático («Enuncia la suposición con la que estás operando. ¿Qué la refutaría?»). Segunda vez: instrucciones directivas. Tercera vez: avisa directamente al usuario.

[NOCICEPTIVE INTERRUPT]
You have attempted 4 similar fixes with consecutive similar errors.
Before taking another action:
1. State the assumption you are currently operating on
2. Describe what read-only action would falsify that assumption
3. Execute that investigation before writing any more code

Capa 3: Seguimiento de refuerzo: la pieza inter-sesión. Esta es la parte con la que más satisfecho estoy, y salió de un fallo que me costó diagnosticar una eternidad.

El problema del sube y baja

Así que me topé con este problema realmente frustrante cuando intenté añadir aprendizaje inter-sesión usando time-decay estándar.

Hay un paper de Experiential RL (arxiv 2602.13949) que muestra cómo reflexionar sobre los fallos en tiempo de entrenamiento mejora el rendimiento del agente hasta en un 81 %. Así que construí un sistema que detectaba patrones de fallo, grababa reglas para prevenirlos e inyectaba esas reglas en la siguiente sesión. Y funcionó. Durante un tiempo.

Pero luego las reglas empezaron a desaparecer.

El problema es que el time-decay ingenuo castiga activamente el éxito. Si el agente aprende «no reintentar el mismo error tres veces» y luego deja de reintentar el mismo error, el sistema de decay ve que la regla se vuelve obsoleta —sin detecciones recientes, debe de ser irrelevante— y la poda. Así que el agente olvida la regla. Y entonces el comportamiento regresa, la regla se dispara otra vez, la confianza sube, el comportamiento mejora, la regla decae otra vez. Sube y baja.

Cuanto mejor funciona la regla, más rápido la mata el sistema. Eso no es aprendizaje. Es una oscilación.

Seguimiento de refuerzo: arreglar el sube y baja

Para arreglar el sube y baja, tuve que invertir el modelo de decay por completo.

Cuando el sistema nervioso detecta un patrón de fallo, registra una detección: el problema ocurrió. Pero cuando un patrón conocido no se dispara durante una sesión en la que su regla estaba activa, eso no es nada. Es evidencia de que la regla funciona. El sistema registra una supresión junto a la detección original. Ambas cuentan como evidencia. Ambas aumentan la confianza.

Las reglas que suprimen con éxito su fallo objetivo se ven reforzadas por su propio éxito. Solo las reglas realmente inactivas —patrones que no han estado activos en absoluto durante 60+ días— decaen. Y aun así, lentamente.

Y eso es lo que hace a esto distinto de un plugin de memoria. No está reproduciendo lo que ocurrió la semana pasada. Está siguiendo qué funciona, qué no, y construyendo confianza a lo largo del tiempo sobre reglas que de verdad previenen los fallos que has sufrido. Tus patrones. Tus modos de fallo. Tus proyectos. No los de los demás promediados juntos.

Cómo fluyen los datos en la práctica

Cuando empieza una sesión nueva, el hook UserPromptSubmit compila todos los aprendizajes (globales y de proyecto) en un digest corto y lo inyecta como system message. También escribe un archivo marcador con los IDs de patrón que se inyectaron: así es como el sistema sabe qué reglas estaban «activas» durante la sesión.

Durante la sesión en sí, el hook PostToolUse se dispara después de cada llamada a herramienta, registrando acciones en una ventana flotante de 20 elementos. Silencioso cuando es normal. Señales cuando es anormal. Aquí no ocurre aprendizaje: es pura propiocepción.

Cuando empieza la siguiente sesión, el sistema lee el marcador de patrones activos de la última vez, ejecuta los detectores contra el estado de la sesión anterior y registra qué ocurrió. Los patrones que se dispararon se registran como detecciones. Los patrones que no se dispararon pero estaban en el conjunto activo se registran como supresiones. Ambos se persisten en un archivo JSONL.

Alcance por proyecto

Los aprendizajes viven en dos niveles. Global (~/.claude/metacog-learnings.jsonl) cubre patrones que aparecen por todas partes. Por proyecto (<project>/.claude/metacog-learnings.jsonl) cubre patrones específicos de un codebase. En la compilación, ambos se mezclan: las entradas de proyecto tienen precedencia. Así, un patrón que solo aparece en un repo construye evidencia para ese repo en concreto, sin contaminar el conjunto global.

Cómo empezar

Un comando:

npx @converly/metacog --install

Eso es todo. El instalador registra ambos hooks en tus ajustes de Claude Code. Sin edición manual de configuración, sin rutas de archivo hardcoded. Para una instalación por proyecto (patrones específicos de un codebase), añade --project.

Metacog corre silenciosamente a partir de ese momento. Solo verás salida cuando algo sea anormal.

A qué estar atento

1. No esperes resultados inmediatos. El seguimiento de refuerzo necesita unas cuantas sesiones para construir evidencia. La capa propioceptiva funciona desde la primera llamada a herramienta, pero el aprendizaje inter-sesión necesita tiempo para calibrarse.

2. El sentido espacial puede ser lento en codebases muy grandes. Ejecuta detección de imports basada en grep, que es rápida en la mayoría de proyectos pero puede añadir latencia en monorepos con miles de archivos. Puedes desactivarlo en la configuración si lo necesitas.

3. Es solo para Claude Code. Metacog usa el sistema de hooks y plugins de Claude Code, así que no funcionará con Claude Desktop, Cursor ni otros clientes. Es por diseño: el sistema de plugin hooks es lo que hace posible el silencio a coste cero de tokens. Cuando no hay nada que reportar, los hooks salen limpiamente y no cuestan nada.

4. La interrupción nociceptiva puede sentirse agresiva. Cuando se dispara, le dice literalmente al agente que pare y reflexione. A algunas personas les resulta brusco. Pero siendo honestos, si el agente ha cometido cuatro errores similares consecutivos, ser educado al respecto no le ayuda a nadie.

Metacog es open source bajo Apache 2.0. Cero dependencias. El código fuente es la distribución.

GitHub: converly/metacog

---

Artículos relacionados