La memoria de un agente se decide en la arquitectura, no en el prompt

MCP nació sin memoria, y no por descuido. Cada llamada a una herramienta a través del Model Context Protocol es una petición con su respuesta: el agente pide, el servidor devuelve y el protocolo no ofrece ningún mecanismo nativo para guardar lo aprendido de una sesión a la siguiente. Esa limitación es el punto de partida de un análisis publicado este lunes 12 de octubre en HackerNoon, cuyo titular resume la tesis: la memoria de un agente es una decisión de arquitectura.

La pieza plantea el paso de los servidores MCP, pensados como herramientas sin estado, a agentes con estado, capaces de retener hechos, decisiones y contexto entre ejecuciones. No es un debate nuevo, pero sí cada vez más práctico. Los equipos que ya tienen agentes en producción se encuentran con que el agente resuelve bien la tarea de hoy y no recuerda nada de la de ayer.

Qué cambia cuando la memoria es arquitectura

Tratar la memoria como un detalle de implementación suele acabar en el mismo sitio: un vector store añadido a última hora, un RAG que recupera fragmentos poco relevantes y un contexto que se llena de ruido. Entenderla como arquitectura significa lo contrario. Antes de elegir modelo o framework hay que decidir qué recuerda el agente, durante cuánto tiempo, quién puede escribir en esa memoria y cómo se recupera.

En la práctica, eso obliga a separar al menos tres capas:

Estado en contexto: lo que el modelo ve en la llamada actual. Es inmediato, pero caro en tokens y desaparece al cerrar la sesión.
Recuperación semántica: búsquedas sobre embeddings para traer documentos o conversaciones pasadas. Útil con volúmenes grandes, frágil si no se cuida qué se indexa.
Memoria persistente estructurada: hechos, decisiones y relaciones guardados en una base de datos o un grafo, con reglas explícitas de escritura y caducidad.

Cada capa tiene costes distintos y falla de forma distinta. Mezclarlas sin criterio es lo que produce agentes que se contradicen o repiten trabajo ya hecho.

MCP como interfaz, no como almacén

El matiz más útil de este enfoque es no pedirle a MCP lo que no es. El protocolo resuelve bien la interfaz, es decir, cómo un agente habla con un sistema externo. La memoria puede exponerse como un servidor MCP más, con herramientas para leer y escribir, pero el diseño del almacén, su esquema y su política de olvido siguen siendo responsabilidad del equipo. Ya hay proyectos que van en esa línea, desde servidores que guardan conversaciones en SQLite o PostgreSQL hasta grafos de conocimiento compartidos entre varios agentes, como recoge este repaso de MemoryLake sobre la capa que le falta a MCP.

Esa separación tiene una ventaja clara: la memoria se vuelve portable. Si vive detrás de una interfaz MCP, la puede consumir Claude Code, Claude Desktop o cualquier cliente compatible sin reescribir la lógica de persistencia.

Por qué importa en el ecosistema Claude

Quien trabaja con Claude Code ya convive con varias formas de memoria aunque no las llame así. Los ficheros `CLAUDE.md` funcionan como memoria declarativa que se carga al inicio de cada sesión. Las skills empaquetan instrucciones y contexto que el modelo invoca bajo demanda. Los subagentes trabajan con su propio contexto y devuelven solo la conclusión, lo que ya es una decisión sobre qué entra en la ventana principal. Y los hooks permiten, por ejemplo, volcar un resumen al terminar una sesión con el evento `Stop`.

La ventana de contexto opcional de 1M tokens de Claude Opus 4.8 puede dar la impresión de que el problema se resuelve a base de capacidad. No es así. Meter más historial en contexto encarece cada llamada y no garantiza que el modelo priorice lo relevante. Una memoria bien diseñada decide qué entra, y eso resulta más barato y más predecible que confiar en que el modelo encuentre la aguja en el pajar.

Para quién es útil

El planteamiento interesa sobre todo a estos perfiles:

Equipos que llevan agentes a producción y necesitan continuidad entre sesiones sin disparar el gasto en tokens.
Desarrolladores de servidores MCP que se preguntan si su servidor debe guardar estado o delegarlo en otro componente.
Responsables técnicos que tienen que justificar dónde viven los datos del agente, quién los ve y cuándo se borran, algo que con el RGPD en Europa no es opcional.

Para proyectos pequeños o tareas de una sola sesión, nada de esto compensa. Un buen `CLAUDE.md` y un contexto limpio bastan.

Nuestra lectura

En los agentes que hemos montado para clientes, los problemas de memoria casi nunca venían del modelo, sino de no haber decidido a tiempo qué debía persistir y qué no. Compartimos la tesis de HackerNoon: conviene diseñar la memoria al principio, con el mismo cuidado que el esquema de una base de datos, porque cambiarla después cuesta bastante más.