Die Session war das Problem

Von Masumi Network | August 2026

Am 28. Juli 2026 hat das Model Context Protocol eine neue Spezifikation veröffentlicht. Die Berichterstattung drehte sich vor allem um die technischen Änderungen. Die wirtschaftliche Konsequenz war weit größer: Die Session war der versteckte Engpass im agentischen Handel.

Das alte MCP verlangte einen Handshake und den Aufbau einer dauerhaften Session, bevor überhaupt nützliche Arbeit beginnen konnte. Für einen Nutzer in einer Konversation funktioniert dieses Modell. Für N-zu-M-Handel, bei dem jeder Käufer jederzeit mit jedem Verkäufer handeln kann, funktioniert es nicht.

Der Handel im Web hat das 1994 gelöst, indem er sich auf zustandsloses HTTP festlegte. Requests wurden in sich abgeschlossen, horizontal routbar und günstig zu skalieren. MCP hat dieselbe Lektion jetzt nachgeholt.

Mit sessionbasiertem MCP hieß Handel im Produktivmaßstab entweder Millionen dauerhafter Sticky-Verbindungen oder ein global geteilter Session-Speicher über alle Replicas hinweg. Beides ist teuer und im Betrieb fragil. Diese Beschränkung erklärt zu einem guten Teil, warum agentische Demos schneller vorankamen als der Produktivbetrieb.

Was sich am 28. Juli geändert hat

Die aktualisierte MCP-Spezifikation streicht serverseitige Sessions. Jeder Request trägt jetzt seine eigene Protokollversion, die Identität des Clients und die deklarierten Capabilities mit sich. Jede Instanz kann jeden Request bedienen. Standard-Load-Balancing funktioniert. Autoscaling funktioniert. Edge- und Serverless-Deployments funktionieren. Internet-native Infrastruktur passt jetzt unmittelbar.

Der Session-Engpass ist weg.

Das Problem, das an seine Stelle tritt

Sessions lieferten früher eine beiläufige Identität. Nach dem Handshake wusste der Server, mit wem er sprach. Im zustandslosen Modell trifft jeder Request kalt ein. Identität und Zustand müssen ausdrücklich auf der Anwendungsschicht mitreisen.

Die AWS-Umsetzungshinweise zur Spezifikation 2026-07-28 sind eindeutig: Warenkorb-IDs, Ausgabenlimits und Kontokontext laufen jetzt über Tool-Parameter statt über den Session-Speicher.

Wirtschaftlich dreht das die Architektur um: Identität ist kein einmaliges Session-Problem mehr, sondern ein Problem pro Transaktion. Agenten müssen bei jedem einzelnen Request nachweisen, wer sie sind und wozu sie berechtigt sind.

Das Rennen um Identität pro Transaktion

Mehrere Ansätze laufen auf Nachweise je Transaktion hinaus: Capability-Tokens, die an einen einzelnen Aufruf gebunden sind, Autorisierungsmodelle mit Task-Geltungsbereich (PAuth), ERC-8004-Identitätsregister und Register für Verifiable Credentials, auf die alle Serverinstanzen zugreifen können.

Unterschiedliche Stacks, gleiche Richtung: Vertrauensentscheidungen wandern hinunter auf die einzelne Transaktion, weil das Protokoll keinen dauerhaften Identitätskontext mehr trägt.

Die naheliegende Schlussfolgerung

In den vergangenen 18 Monaten drehte sich die Branche um Zahlungswege: x402, AP4M, AP2, Stablecoins, programmierbare Wallets und Chargeback-Logik. Der Großteil dieser Arbeit ging davon aus, dass die Identitätsschicht gelöst ist.

Zustandsloses MCP hat gezeigt, dass sie es nicht ist. Die Session war das Stützrad. Sobald es weg war, wurde die Identität eines Agenten pro Request zum begrenzenden Faktor für Handel im großen Maßstab.

Die nächsten Gewinner im agentischen Handel werden nicht nur Geld bewegen. Sie werden Identität und Befugnis eines Agenten in Transaktionsgeschwindigkeit prüfen.

Quellen

• Model Context Protocol Blog - Veröffentlichung der Spezifikation 2026-07-28: blog.modelcontextprotocol.io/posts/2026-07-28/
• AWS Machine Learning Blog - AgentCore Gateway unterstützt MCP 2026-07-28: aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/
• DigitalApplied - Analyse der zustandslosen MCP-Spezifikation 2026-07-28: www.digitalapplied.com/blog/mcp-2026-07-28-stateless-spec-agent-infrastructure-2026