Qué cambió realmente en la especificación del 2026-07-28
Las sesiones han desaparecido en la capa de protocolo
El intercambio initialize/initialized se ha retirado. Los servidores pueden implementar opcionalmente un nuevo RPC server/discover para el descubrimiento de capacidades, pero no es obligatorio. Nada en la ruta de la solicitud asume un saludo previo, y nada en la red vincula una solicitud con la anterior.
La especificación es directa sobre lo que esto significa y lo que no: "Eliminar la sesión a nivel de protocolo no obliga a tu aplicación a ser sin estado. Si tu servidor necesita llevar el estado a través de las llamadas, genera un identificador (handle) explícito desde una herramienta y haz que el modelo lo devuelva como argumento".
Lee eso dos veces. El protocolo te ha devuelto el estado y te ha indicado el mecanismo: un identificador explícito, pasado por el modelo, entendido por tu aplicación. Un identificador es un puntero. Lo que sea que apunte el puntero es la parte que aún tienes que construir.
Qué se añadió en torno a la ausencia de estado
El lanzamiento no es solo una resta:
- Las Solicitudes de múltiples viajes de ida y vuelta (MRTR) permiten que un servidor realice solicitudes de vuelta al cliente a mitad de la ejecución sin una conexión persistente.
- El enrutamiento basado en cabeceras a través de
Mcp-MethodyMcp-Namepermite que las pasarelas filtren y enruten sin analizar los cuerpos JSON. - Los resultados de lista almacenables en caché añaden
ttlMsycacheScopea las respuestas de listado y lectura, para que los clientes puedan almacenar en cachétools/listdurante el tiempo que el servidor lo permita. - Las Tareas pasaron del núcleo experimental a una extensión formal, aportada por AWS, para un trabajo confiable de larga duración con operaciones basadas en sondeo (polling).
- Las MCP Apps se unieron al mismo marco de extensiones formales.
- Ahora se aplica una ventana de depreciación mínima de doce meses, y Roots, Sampling, Logging y Dynamic Client Registration entraron en depreciación.
- Los SDK de Nivel 1 —TypeScript, Python, Go y C#— se enviaron actualizados; el SDK de Rust está en beta.
Ya está activo en Claude
Anthropic lanzó soporte para la nueva especificación en las aplicaciones de Claude, la Plataforma y API de Claude, y Claude Code en la misma fecha, junto con MCP Apps para UI interactiva en conversaciones, autenticación gestionada por empresas alineada con OAuth 2.0/OIDC para proveedores de identidad como Entra y Okta, paneles de observabilidad para conectores publicados y túneles MCP en vista previa de investigación. El directorio de conectores de Claude ahora enumera más de 950 servidores MCP.
En otras palabras, esta no es una especificación que puedas esperar a que pase. Si tu agente habla con Claude Code o con un conector, el núcleo sin estado ya es el suelo sobre el que se apoya.
Por qué la falta de estado no causa ni cura la amnesia de tu agente
Una sesión nunca fue una memoria
Una sesión de MCP duraba lo que duraba una conexión: minutos, a veces segundos. La amnesia de tu agente opera en una escala de tiempo completamente diferente: mañana por la mañana, el próximo sprint, la tercera vez que un compañero de equipo pregunta sobre el mismo cliente. Incluso en el antiguo mundo con estado, cerrar el cliente eliminaba todo lo que la sesión sabía.
El estado de la sesión era contabilidad de transporte. La memoria son las conclusiones acumuladas de tu trabajo. Confundir ambas cosas es la razón por la que los equipos seguían esperando persistencia de una capa que nunca la prometió.
Qué se rompe realmente
Los patrones que realmente dependían del estado de la sesión son más limitados de lo que sugiere el pánico: servidores que acumulaban estado intermedio entre llamadas de herramientas en memoria, cachés derivadas del saludo identificadas por ID de sesión y pasarelas que necesitaban sesiones persistentes (sticky sessions) para mantener a un cliente vinculado a un trabajador. Esos necesitan reestructuración; ahora un servidor remoto puede estar detrás de un balanceo de carga round-robin simple, lo cual es la ventaja.
Lo que no se rompe: cualquier cosa que ya almacenara estado duradero fuera de la conexión. Si tu conocimiento vivía en una base de datos, un almacenamiento de archivos o un servicio de memoria, el 28 de julio no cambió nada sobre tu recuperación de información y simplificó tu despliegue.
Dónde debe vivir la memoria ahora
La respuesta de la especificación —generar un identificador, dejar que el modelo lo devuelva— es correcta pero incompleta. Te dice cómo hacer referencia al estado, no dónde debe vivir el estado, qué forma debe tomar o cómo se supone que cinco agentes diferentes en tres modelos diferentes lo compartan. Esa es la capa que te corresponde ahora, y vale la pena asumirla deliberadamente en lugar de por accidente.
Las soluciones temporales a las que recurren los equipos
Ventanas de contexto más grandes
Los modelos de frontera ahora anuncian ventanas de contexto medidas en millones de tokens, y es tentador tratar eso como memoria. No lo es. Una ventana de contexto es lo que el modelo puede leer en este turno; todavía tienes que decidir qué poner en ella, pagar por esos tokens en cada turno y comenzar de cero la próxima vez. Consulta por qué RAG no es memoria para ver la misma distinción aplicada a la recuperación de información.
La memoria integrada de cada herramienta
Claude, ChatGPT y la mayoría de los marcos de trabajo de agentes ahora incluyen sus propias funciones de memoria. Cada una es genuinamente útil y genuinamente aislada. Lo que tu agente de programación aprendió sobre el pipeline de despliegue no llega al asistente que redacta el informe de incidentes, y nada de eso te sigue cuando diriges una tarea a un modelo más económico.
Un identificador más una base de datos construida por ti mismo
Este es el camino al que apunta la especificación, y para algunos equipos es el correcto. También significa escribir la extracción, el almacenamiento, la clasificación de recuperación, el alcance, la expiración y el control de acceso multiagente, y mantenerlos mientras el protocolo circundante sigue evolucionando. Vale la pena si la memoria es tu producto. Es costoso si la memoria es solo la infraestructura en el camino hacia tu producto.
La solución: dale a tu agente una capa de memoria que sobreviva a cualquier sesión
La versión duradera del consejo de la especificación es colocar la memoria en un servicio que ninguna sesión, reinicio o cambio de modelo pueda llevarse consigo. MemoryLake está diseñado exactamente para esa posición: una capa de memoria en la que tus agentes leen y escriben a través de MCP o la API, independientemente de qué cliente esté conectado en este momento.
Paso 1: Crea una clave de API
Genera una clave y realiza tu primera solicitud en unos 30 segundos. Nada en este paso depende de una sesión, que es precisamente el objetivo.
Paso 2: Sube tus primeras memorias
Arrastra los documentos, imágenes y archivos que tus agentes necesitan constantemente: notas de arquitectura, manuales de procedimientos (runbooks), contexto del cliente, decisiones previas. Este es el estado al que debería apuntar un identificador.
Paso 3: Conecta tu IA y agentes
Dale a Claude, Codex, OpenClaw y a tus otros agentes acceso a esa memoria a través de MCP o la API. Bajo el núcleo del 2026-07-28, cada llamada lleva su propia identidad y llega a la misma memoria: sin enrutamiento persistente, sin sesión que mantener activa. Para una guía paso a paso específica del cliente, consulta cómo añadir memoria a Claude Code; si eres tú quien escribe el servidor, memoria para servidores MCP sin estado cubre el lado del implementador, y memoria para tareas de MCP cubre el trabajo de larga duración.
Qué cambia esto en la práctica
Haz las cuentas de lo que cuesta volver a explicar. Supón que tu contexto permanente (tecnologías, convenciones, prioridades actuales, decisiones ya tomadas) es de 2,000 tokens, y tú o tus agentes lo vuelven a enviar 20 veces al día. Eso equivale a 40,000 tokens diarios, aproximadamente 1.2 millones al mes, gastados en repetir cosas que ya dijiste. La factura de tokens es la parte pequeña; el costo que realmente sientes son los cuatro o cinco minutos de re-contextualización al inicio de cada sesión, y los errores que cometen los agentes cuando nadie se toma la molestia de hacerlo.
Una capa de memoria persistente convierte eso de un impuesto por sesión a una escritura única. También hace que el trabajo multiagente sea coherente: cuando dos agentes comparten una memoria en lugar de una transcripción, el segundo comienza a partir de las conclusiones del primero. Vale la pena leer sobre ese problema por separado en memoria multiagente.
Buenas prácticas para la memoria en un mundo MCP sin estado
Almacena conclusiones, no transcripciones
Los registros sin procesar crecen sin límite y se recuperan mal. Vale la pena conservar: "Elegimos Postgres en lugar de Redis para el historial de chat porque el modo de cola rompió la memoria en proceso". Los cuarenta mensajes que llevaron a eso, no.
Vincula la memoria al trabajo, no a la conexión
Las sesiones han desaparecido; no las reconstruyas por accidente. Delimita el alcance de la memoria a un proyecto, repositorio, cliente o tarea: algo que siga significando lo mismo el próximo mes, independientemente de qué cliente esté llamando.
Depura y versiona deliberadamente
La memoria obsoleta es peor que la falta de memoria, porque los agentes confían en ella. Asigna un propietario y una expiración a los hechos, y registra cuándo una decisión reemplazó a una anterior en lugar de dejar ambas en el conjunto de datos.
Conclusión
Que MCP se volviera sin estado el 28 de julio de 2026 no borró la memoria de tu agente. Terminó con la ilusión de que el protocolo la sostenía. Las sesiones eran transporte, no recuerdo, y la especificación ahora lo dice claramente mientras te entrega el mecanismo —un identificador explícito— y te deja la sustancia a ti.
Los equipos que sentirán este cambio como una mejora son aquellos cuya memoria ya vive fuera de la conexión: despliegues más simples, la misma recuperación de información y agentes que retoman el trabajo donde lo dejó el anterior. Los equipos que lo sentirán como una pérdida son los que contaban con una sesión para recordar por ellos. Construir esa capa una vez es más barato que pagar el impuesto de volver a explicar para siempre.