La especificación MCP 2.0 del 28 de julio, que contábamos el 1 de agosto, elimina las sesiones del servidor: una solicitud HTTP es suficiente para invocar una herramienta. En su resumen semanal, Latent.Space identifica precisamente este paso stateless como el hilo que une los temas de la semana: agentes que se mensajean entre sí, orquestación multi-agente, gestión del estado.

Para quien escala agentes, el estado persistente en el servidor era el cuello de botella invisible. Cada sesión abierta consumía recursos, cada conexión debía ser gestionada y mantenida. Con el protocolo stateless, cien agentes pueden llamar a las mismas herramientas sin que el servidor se convierta en el punto de estrangulamiento.

La semana lo demuestra en la práctica. Claude Code permite que las sesiones intercambien mensajes, y en Codex puedes @-mencionar un thread para encolar un mensaje a otro agente. Son patrones que funcionan solo si la infraestructura subyacente no retiene estado. Latent.Space bautiza esta tendencia como “ley de Zawinski de los agentes múltiples”: cada agente busca expandirse mientras pueda mensajear con otros agentes.

Si quieres probarlo: la especificación MCP 2.0 es pública en el repositorio oficial del protocolo. Compara el flujo basado en sesión de la versión anterior con el HTTP stateless para entender qué cambia en tu arquitectura.

En detalle

El Model Context Protocol (MCP) es el estándar que Anthropic publicó a finales de 2024 para conectar asistentes AI a herramientas externas: bases de datos, APIs, sistemas de archivos, cualquier recurso que un agente deba leer o escribir. En su primera versión, cada conexión entre agente y herramienta abría una sesión persistente en el servidor. El servidor mantenía un registro de quién estaba conectado, qué estaba haciendo, qué estado de conversación había acumulado. Funcionaba bien para un chat, pero se convertía en un problema cuando los agentes se multiplicaban.

El problema del estado. Si tienes diez agentes que llaman simultáneamente al mismo servidor MCP, el servidor debe gestionar diez sesiones activas. Cada sesión ocupa memoria. Si un agente se desconecta sin cerrar la sesión, el servidor queda con una conexión fantasma. Si quieres escalar a cien agentes, el servidor se convierte en el cuello de botella. Es el mismo problema que la web enfrentó años atrás pasando de sesiones del lado del servidor a tokens stateless.

Qué cambia con MCP 2.0. La especificación del 28 de julio elimina el estado del servidor. Una solicitud HTTP contiene todo lo necesario: qué herramienta llamar, con qué parámetros, con qué contexto. El servidor responde y olvida. Sin sesión, sin memoria persistente, sin conexión que mantener. Es la misma diferencia que existe entre una llamada telefónica (abres una línea, la mantienes, la cierras) y un SMS (envías el mensaje, el sistema lo entrega, fin).

Por qué ahora. Los patrones de la semana muestran que los agentes se están convirtiendo en sistemas distribuidos, no en asistentes individuales. Claude Code hace que las sesiones se comuniquen entre sí. Codex permite @-mencionar threads para encolar mensajes a otros agentes. OpenAI documentó en Black Hat cómo sus agentes en entrenamiento descubrieron por sí solos cómo usar un repositorio compartido como tablón para coordinarse. Son ejemplos que van en la misma dirección: agentes que hablan con otros agentes, no solo con un humano. Y para que esto funcione a escala, el protocolo subyacente no puede retener estado.

Latent.Space lo sintetiza todo con lo que llama “ley de Zawinski de los agentes múltiples”, una variación de la famosa ley de Jamie Zawinski sobre el software que se expande hasta que puede leer correo. En el caso de los agentes: cada agente busca expandirse mientras pueda mensajear con otros agentes. MCP 2.0 stateless es la infraestructura que hace posible esta expansión en lugar de ahogarla.

Qué sigue abierto. La especificación está activa, pero la adopción real requiere que servidores y clientes se actualicen. Algunas implementaciones MCP existentes podrían no ser aún compatibles con el nuevo modelo stateless. Y el paso de basado en sesión a stateless desplaza el problema del estado del servidor al cliente: es el agente, o quien lo orquesta, quien debe gestionarlo. El estado no desaparece, cambia de dueño.