Plugins de memoria en Claude Code: MCP que salvan sesiones

TL;DR: La memoria persistente en Claude Code vive en tres capas: archivos (CLAUDE.md), servidores MCP y plugins especializados. Esta guía explica cuándo usar cada una, cómo montar un servidor MCP de memoria y qué errores evitar si no quieres que el contexto se degrade a la tercera sesión.

El problema: CLAUDE.md no es una base de datos

He visto el mismo patrón en varios proyectos propios: empiezas con un CLAUDE.md limpio, a los dos meses tiene 400 líneas y cada sesión nueva arranca con 8.000 tokens ya consumidos antes de escribir nada. Y, peor, el agente sigue olvidando la decisión que tomaste hace tres días sobre cómo estructurar el CLI.

El fallo conceptual es tratar CLAUDE.md como un vertedero de todo lo que el agente debería recordar. No es su función. CLAUDE.md es el archivo de reglas estables del proyecto, no un registro temporal de decisiones. Si quieres que Claude Code recuerde qué hicisteis ayer, necesitas otra capa.

Esa otra capa existe desde hace meses, pero no siempre está clara: servidores MCP de memoria y plugins que capturan observaciones sesión a sesión. A abril de 2026, herramientas como Engram, claude-mem o Letta MCP ya son lo bastante estables como para usarlas en el día a día.

¿Qué es la memoria persistente en Claude Code?

La memoria persistente es cualquier mecanismo que permite al agente recuperar información de sesiones anteriores sin reinyectarla manualmente en el prompt. En Claude Code se materializa en tres formas distintas:

• Archivos estáticos: CLAUDE.md, AGENTS.md, skills. El agente los lee al inicio.
• Servidores MCP: procesos externos que exponen herramientas como mem_save o mem_search. El agente decide cuándo llamarlas.
• Plugins de captura: piezas que interceptan la conversación y guardan observaciones automáticamente.

La diferencia crítica: los archivos son siempre contexto. Los MCP y plugins son contexto bajo demanda, que el agente consulta solo cuando hace falta.

Tres capas, tres funciones distintas

Esta es la decisión que más gente se salta y luego paga con sesiones rotas. Cada capa sirve para algo distinto:

Capa	Contenido ideal	Coste en contexto	Ejemplo
Archivos (CLAUDE.md)	Reglas estables, convenciones del repo	Alto (siempre cargado)	"Nunca hagas commit sin tests"
Servidor MCP memoria	Decisiones, bugs, preferencias acumuladas	Bajo (solo al buscar)	"Por qué migramos de Pinecone a Qdrant"
Plugin de captura	Historial de sesiones, resúmenes	Medio (depende del plugin)	"Qué hicimos el martes con el módulo auth"

La regla operativa que me funciona: si la información cambia decisiones futuras, va en memoria MCP. Si es una regla que aplica a cada sesión, va en CLAUDE.md. Si es ruido ("ayer editamos el archivo X"), no va a ningún sitio.

Montar un servidor MCP de memoria en 5 pasos

Vamos con Engram porque es el que uso a diario y tiene un protocolo MCP estándar. Para otras opciones como claude-mem o Letta, el flujo es parecido.

1. Instala el servidor MCP. Engram se distribuye como paquete Python. Necesitas Python 3.11+:

# Instala el servidor MCP de Engram desde PyPI
pip install engram-mcp

2. Configura Claude Code para cargarlo. Añade el servidor a tu configuración MCP (~/.claude/mcp.json o el equivalente del plugin):

{
  "mcpServers": {
    "engram": {
      "command": "engram-mcp",
      "args": ["--db", "~/.engram/memory.db"]
    }
  }
}

3. Verifica que las herramientas aparecen. Abre Claude Code y pregunta por las herramientas disponibles. Deberías ver mem_save, mem_search, mem_context.

4. Define cuándo guardar. Esto es lo que la mayoría omite. En tu CLAUDE.md añade una sección breve indicando al agente qué guardar proactivamente:

## Engram Memory
- Guarda con mem_save tras: decisión arquitectónica, bug resuelto, convención establecida.
- Busca con mem_search cuando el usuario diga "acordate", "qué hicimos" o similar.
- NO guardes: cambios triviales, estado temporal, exploración sin decisión.

5. Prueba una sesión de ida y vuelta. Abre una sesión, toma una decisión técnica (por ejemplo, elegir Qdrant sobre Pinecone por coste), cierra. Al día siguiente abre otra y pregunta "¿por qué elegimos Qdrant?". El agente debería usar mem_search y recuperarlo.

Si no lo hace, el problema suele ser que no le has dado instrucciones claras sobre cuándo consultar memoria. Es el mismo patrón que cuando montas skills y subagentes reutilizables: sin reglas explícitas, el agente no usa la herramienta.

Caso real: onboarding de un proyecto freelance

Uso Engram en un proyecto paralelo que toco dos tardes por semana. Sin memoria, cada sesión empezaba con 20 minutos de "a ver dónde lo dejé". Con el servidor MCP configurado, el flujo es:

1. Abro Claude Code y pregunto "¿en qué andábamos la última vez?".
2. El agente llama mem_context y recupera el resumen de la sesión anterior.
3. Si toco un área que tocamos hace semanas, llama mem_search con las keywords del fichero.

El cambio medible: las primeras 15 interacciones de cada sesión se reducen a 3-4. No es magia, es no reexplicar la misma arquitectura cada martes. Este patrón se apoya también en una buena separación de responsabilidades: cada capa (archivos, MCP, plugins) hace una cosa.

En Producción

Rendimiento: los servidores MCP de memoria son procesos locales con SQLite o similar. La latencia de mem_search suele ser inferior a 50ms en bases de hasta 10.000 observaciones. Si superas eso, considera índices FTS5 (Engram los usa por defecto) o backends vectoriales.

Costes: cero en infraestructura porque corre local. El coste real es en tokens: cada mem_search que devuelva 5 resultados añade 500-1.500 tokens al contexto. Si el agente llama mucho a la memoria, revisa la disciplina de guardado.

Escalabilidad de equipo: aquí hay un trade-off honesto. La memoria local es personal. Si queréis memoria compartida, algunos plugins ofrecen backend remoto (Engram con Postgres, claude-mem con Redis), pero aparece el problema de quién decide qué se guarda y la gobernanza se complica. Para equipos, mi recomendación es memoria personal + documentación compartida en el repo.

Privacidad: la memoria captura fragmentos literales de conversaciones. No la uses con clientes que tengan NDAs estrictos sin revisar qué se persiste. Algunas herramientas ofrecen modo "redacted" que elimina valores de variables.

Errores comunes y cómo depurarlos

• Error: "el agente nunca llama a mem_save" → Causa: no hay instrucción explícita en CLAUDE.md → Solución: añade reglas de cuándo guardar, con ejemplos concretos.
• Error: "la memoria crece sin control" → Causa: se guardan observaciones triviales → Solución: limita por tipo de evento (decisión, bug, convención) y revisa la base semanalmente.
• Error: "mem_search devuelve resultados irrelevantes" → Causa: observaciones sin topic_key ni tags claros → Solución: fuerza campos estructurados al guardar (topic, tags, why).
• Error: "el contexto se infla al buscar" → Causa: el agente llama mem_search con queries amplios → Solución: instruye a usar mem_context primero y solo mem_search si falta algo específico.

Este último patrón enlaza con algo que ya comenté en context drift y compaction: la memoria bien usada reduce drift, mal usada lo acelera.

¿Plugin o servidor MCP puro?

La diferencia práctica: un servidor MCP expone herramientas y deja al agente decidir cuándo usarlas. Un plugin (como los que empaqueta el ecosistema de harnesses abiertos para Claude Code) puede inyectar instrucciones automáticas, interceptar hooks y forzar comportamiento.

Para empezar, servidor MCP puro. Es más transparente, más fácil de debuggear y no te ata a un harness concreto. Si más adelante quieres automatización pesada (guardado sin intervención, resúmenes automáticos de sesión), los plugins añaden esa capa encima.

Preguntas frecuentes

¿Puedo combinar CLAUDE.md y un plugin de memoria MCP?

Sí, y es la configuración recomendada. CLAUDE.md para reglas estables del proyecto, el plugin MCP para historia de sesiones y decisiones puntuales. La clave es no duplicar información entre ambos.

¿Qué diferencia hay entre memoria MCP y RAG?

RAG indexa documentos externos para consulta semántica. La memoria MCP almacena el propio historial del agente: decisiones, bugs y convenciones establecidas durante el trabajo. Son capas complementarias, no sustitutivas.

¿Funciona con Codex o Gemini CLI?

Sí. El protocolo MCP es estándar abierto. A abril de 2026, Codex soporta MCP de forma estable y Gemini CLI lo tiene en estado experimental.

Cierre

La memoria persistente deja de ser un truco personal cuando separas capas: CLAUDE.md para reglas, MCP para historia, plugins para automatizar lo repetitivo. El valor real no está en guardarlo todo, sino en guardar lo mínimo que cambia decisiones futuras. Si tu CLAUDE.md supera las 200 líneas, probablemente la mitad debería vivir en memoria MCP.

¿Has montado ya memoria MCP en tu flujo con Claude Code o Codex? Cuéntamelo en Twitter @sergiomarquezp_. En el próximo post voy a entrar en gobernanza de skills compartidas entre varios desarrolladores, que es el problema natural que aparece cuando la memoria personal funciona y quieres subirla un nivel.