La specifica MCP 2.0 del 28 luglio, che raccontavamo il 1° agosto, toglie le sessioni dal server: una richiesta HTTP basta per invocare uno strumento. Nel suo riepilogo settimanale, Latent.Space identifica proprio questo passaggio stateless come il filo che tiene insieme i temi della settimana: agenti che si messaggiano fra loro, orchestrazione multi-agente, gestione dello stato.

Per chi scala agenti, lo stato persistente sul server era il collo di bottiglia invisibile. Ogni sessione aperta consumava risorse, ogni connessione doveva essere gestita e mantenuta. Con il protocollo stateless, cento agenti possono chiamare gli stessi strumenti senza che il server diventi il punto di soffocamento.

La settimana lo dimostra sul campo. Claude Code permette alle sessioni di scambiarsi messaggi, e in Codex puoi @-mentionare un thread per accodare un messaggio a un altro agente. Sono pattern che funzionano solo se l’infrastruttura sottostante non trattiene stato. Latent.Space battezza questo trend “legge di Zawinski degli agenti multipli”: ogni agente cerca di espandersi finché può messaggiare con altri agenti.

Se vuoi provarci: la specifica MCP 2.0 è pubblica sul repository ufficiale del protocollo. Confronta il flusso session-based della versione precedente con quello HTTP stateless per capire cosa cambia nella tua architettura.

Nel dettaglio

Il Model Context Protocol (MCP) è lo standard che Anthropic ha pubblicato a fine 2024 per collegare gli assistenti AI a strumenti esterni: database, API, file system, qualsiasi risorsa che un agente debba leggere o scrivere. Nella sua prima versione, ogni connessione tra agente e strumento apriva una sessione persistente sul server. Il server teneva traccia di chi era connesso, cosa stava facendo, quale stato di conversazione aveva accumulato. Funzionava bene per una chat, ma diventava un problema quando gli agenti diventavano molti.

Il problema dello stato. Se hai dieci agenti che chiamano contemporaneamente lo stesso server MCP, il server deve gestire dieci sessioni attive. Ogni sessione occupa memoria. Se un agente si disconnette senza chiudere la sessione, il server resta con una connessione fantasma. Se vuoi scalare a cento agenti, il server diventa il collo di bottiglia. È lo stesso problema che il web ha affrontato anni fa passando dalle sessioni server-side ai token stateless.

Cosa cambia con MCP 2.0. La specifica del 28 luglio toglie lo stato dal server. Una richiesta HTTP contiene tutto ciò che serve: quale strumento chiamare, con quali parametri, con quale contesto. Il server risponde e dimentica. Niente sessione, niente memoria persistente, niente connessione da mantenere. È la stessa differenza che c’è fra una chiamata telefonica (apri una linea, la mantieni, la chiudi) e un SMS (mandi il messaggio, il sistema lo recapita, fine).

Perché adesso. I pattern della settimana mostrano che gli agenti stanno diventando sistemi distribuiti, non singoli assistenti. Claude Code fa comunicare le sessioni fra loro. Codex permette di @-mentionare thread per accodare messaggi ad altri agenti. OpenAI ha documentato al Black Hat come i suoi agenti in training abbiano scoperto da soli come usare un repository condiviso come bacheca per coordinarsi. Sono esempi che vanno nella stessa direzione: agenti che parlano con altri agenti, non solo con un umano. E perché questo funzioni a scala, il protocollo sottostante non può trattenere stato.

Latent.Space sintetizza il tutto con quella che chiama “legge di Zawinski degli agenti multipli”, riff della famosa legge di Jamie Zawinski sul software che si espande finché può leggere la posta. Nel caso degli agenti: ogni agente cerca di espandersi finché può messaggiare con altri agenti. MCP 2.0 stateless è l’infrastruttura che rende questa espansione praticabile invece di soffocarla.

Cosa resta aperto. La specifica è live, ma l’adozione reale richiede che server e client si aggiornino. Alcune implementazioni MCP esistenti potrebbero non essere ancora compatibili con il nuovo modello stateless. E il passaggio da session-based a stateless sposta il problema dello stato dal server al client: è l’agente, o chi lo orchestra, che deve gestirlo. Lo stato non sparisce, cambia padrone.