Zum Inhalt springen
Archiv 06. Aug. 2026

Google macht MCP zustandslos: Warum Agenten-Infrastruktur jetzt erwachsenere Web-Prinzipien bekommt

Google hat am 5. August 2026 einen ungewoehnlich nuetzlichen Infrastruktur-Post veroefentlicht: Scaling AI Agent Infrastructure with the MCP Stateless updates. Auf dem Papier geht es um das neue Model Context Protocol 2026-07-28. Fuer menzel.works ist die wichtigere Nachricht aber groesser als ein Protokoll-Update. Agentische Infrastruktur soll sich ploetzlich viel mehr wie normales Web verhalten: stateless, ueber Header routbar, cachebar und ohne versteckte Session-Last in der Transportebene.

Genau deshalb halte ich das Thema fuer blogtauglich. Viele Agenten-Debatten haengen noch immer an Modellen, Tool-Listen oder Demos. Googles Aufhaenger zeigt dagegen eine tiefere Verschiebung: Die naechste Reifestufe von Agenten entscheidet sich nicht nur an Intelligenz, sondern an der Betriebsfaehigkeit der Schicht darunter.

Was Google konkret hervorhebt

Google beschreibt das MCP-Update ausdruecklich als Schritt zu horizontaler Skalierung, serverless Deployments und standard round-robin load balancing. Das ist ungewoehnlich klar formuliert. Statt laenger laufender bidirektionaler Spezialverbindungen setzt der neue Stand auf einen stateless core, in dem jede Anfrage alle noetigen Metadaten selbst mitbringt.

Die dazu passende MCP-Spezifikation vom 28. Juli 2026 nennt die Kernpunkte ebenfalls sehr offen:

  • kein `initialize`/`initialized`-Handshake mehr und kein `Mcp-Session-Id` als Pflichtschicht im Transport,
  • `server/discover` als optionale Discovery statt festem Sitzungsaufbau,
  • `Mcp-Method` und `Mcp-Name` als Standard-HTTP-Header fuer Routing, Metering und Policies,
  • Multi Round-Trip Requests (MRTR) fuer interaktive Nachfragen ohne dauerhaft offen gehaltene Streams,
  • Cache-Hinweise wie `ttlMs` und `cacheScope` fuer Listen- und Ressourcenantworten,
  • Tasks als offizielle Erweiterung fuer laenger laufende Arbeit.

Das klingt technisch, ist aber praktisch ziemlich wichtig. Denn hier wird nicht bloss ein Detail modernisiert. Hier wird die Grundannahme veraendert, wie Agenten-Tooling im Netz haengen soll.

Die eigentliche Nachricht: Agenten verlieren ihre Sonderrolle im Betrieb

Bisher fuehlten sich viele MCP- und Agentensysteme noch wie Spezialinfrastruktur an. Laufende Sessions, gehaltene Streams, impliziter Zustand, parserlastige Gateways, viel Sonderlogik fuer Routing und Hochverfuegbarkeit. Das funktioniert fuer Demos und kleine Teams. Es skaliert aber schlecht, sobald mehrere Instanzen, Policies, WAFs, Observability und normaler Plattformbetrieb ins Spiel kommen.

Genau dort setzt der neue Stand an. Wenn laut MCP-Blog jede Anfrage auf jeder Instanz hinter einem simplen Round-Robin-Balancer landen kann, dann verschiebt sich Agenten-Infrastruktur einen grossen Schritt in Richtung normaler Web-Architektur. Das ist fuer mich die wichtigere Botschaft als einzelne neue Header oder RPC-Namen.

Das passt auffaellig gut zu Linien, die auf menzel.works bei Google zuletzt schon sichtbar waren. Bei session-aware Load Balancing fuer Echtzeit-Agenten ging es darum, dass Live-Agenten neue Routing- und Lastmodelle brauchen. Bei Model Routing in der API Gateway wanderte die Modellwahl tiefer in die Infrastrukturschicht. Und bei der Interactions API als Agentenplattform wurde klar, dass Google Agenten laengst nicht mehr nur als Modellaufruf denkt. Das MCP-Update zieht diese drei Linien jetzt auf Protokollebene zusammen.

Warum Header, Cache und MRTR mehr sind als Protokollkosmetik

Die drei interessantesten Punkte sind fuer mich nicht zufaellig genau die trockensten.

Erstens: Header-basiertes Routing. Wenn `Mcp-Method` und `Mcp-Name` im HTTP-Header stehen, muessen Gateways nicht mehr JSON-Bodies aufreissen, um Traffic zu verstehen. Das ist betriebsnahes Denken. Ratenbegrenzung, Autorisierung, WAF-Regeln und Observability koennen viel normaler ansetzen.

Zweitens: Cachebarkeit. Laut Spezifikation sollen `tools/list`, `prompts/list`, `resources/list` und verwandte Antworten nun deterministisch und mit `ttlMs` plus `cacheScope` ausgeliefert werden. Das ist kein Luxusdetail. Wer Agenten produktiv betreibt, will nicht bei jeder kleinen Abfrage komplette Tool- und Ressourcenverzeichnisse neu holen.

Drittens: MRTR statt dauerhaft offener Gegenrichtung. Tools koennen waehrend eines Calls weiter Rueckfragen stellen oder Bestaetigungen einholen, ohne dass dafuer eine dauerhafte bidirektionale Session am Leben gehalten werden muss. Genau das macht interaktive Freigaben und laenger laufende Workflows sauberer anschlussfaehig an normale HTTP-Betriebsmodelle.

Zusammengenommen lautet die Botschaft: Agentische Interaktivitaet bleibt erhalten, aber sie wird transportseitig viel weniger exotisch.

Warum das fuer Coding- und Workflow-Themen wichtig ist

Fuer reine Chat-Nutzung kann man so ein Update leicht uebersehen. Fuer Teams, die mit Coding-Agenten, Browser-Agenten, internen Tools oder laenger laufenden Automatisierungen arbeiten, ist es deutlich relevanter. Dort entscheidet sich Stabilitaet oft nicht am Modell selbst, sondern an Fragen wie:

  • Laeuft der Traffic ueber normale Load Balancer oder nur ueber Spezialruntimes?
  • Kann ich Genehmigungen, Rückfragen und fehlende Parameter ohne fragile Dauerverbindungen abbilden?
  • Wie gut lassen sich Tools, Listen und Ressourcen cachen?
  • Wo setze ich Policies, Limits und Messpunkte an?

Genau deshalb hat der Schritt auch Folgen fuer Coding-Workflows. Sobald Agenten nicht nur antworten, sondern Werkzeuge entdecken, Rueckfragen stellen, Aufgaben weiterreichen und laenger laufende Arbeit koordinieren, wird Transportdisziplin selbst zu einem Produktmerkmal. Die bessere Agentenerfahrung entsteht dann nicht nur aus mehr Reasoning, sondern aus weniger Infrastruktur-Reibung.

Spannend ist auch, was verschwindet

Ich finde fast noch aufschlussreicher, was die Spezifikation aktiv zurueckbaut. `initialize`/`initialized` verschwindet als Pflichtstart. `Mcp-Session-Id` faellt auf Protokollebene weg. Roots, Sampling und Logging werden in der bisherigen Form deprecated. Das sieht zunaechst wie Verlust aus. In Wirklichkeit ist es oft ein Zeichen, dass ein Standard erwachsener wird.

Wenn ein Protokoll Sitzungen, Streams und Zusatzmechanik nicht mehr heimlich voraussetzt, koennen Plattformteams es viel normaler behandeln. Genau das ist die Art von Reifung, die spater unspektakulaer wirkt, aber ueber Produktionsfaehigkeit entscheidet.

Wo ich trotzdem vorsichtig waere

Natuerlich ist damit nicht ploetzlich jedes Agentensystem automatisch simpel. Ein stateless Protokoll macht die Anwendung nicht zwangslaeufig stateless. Auch die MCP-Maintainer sagen selbst: Wenn ein Server ueber Aufrufe hinweg Zustand braucht, soll er explizite Handles oder andere sichtbare Mechanismen verwenden, statt versteckten Transportzustand vorauszusetzen.

Genau darin steckt auch die neue Verantwortung. Ein Teil der Komplexitaet verschwindet nicht, sondern wird sichtbarer und sauberer modelliert. Das ist gut fuer Betrieb und Debugging, aber es nimmt Teams nicht die Arbeit ab, ihre Agentenablaeufe bewusst zu designen.

Und noch etwas: Nicht jeder Agent wird dadurch sofort problemlos horizontal skalieren. Voice-, Browser- und Echtzeit-Szenarien behalten ihre eigene Runtime-Haerte. Aber genau deshalb ist die neue Richtung wichtig. Sie reduziert den Teil der Komplexitaet, der nur aus historischer Transportlogik kam.

Mein Fazit

Google macht mit seinem MCP-Post vom 5. August 2026 keinen Modell-Launch gross, sondern etwas Langfristigeres: Agenten-Infrastruktur soll sich mehr wie das restliche Web verhalten.

Die eigentlich starke Nachricht lautet fuer mich deshalb nicht bloss: MCP ist jetzt stateless. Die staerkere Nachricht lautet: Agentische Systeme werden gerade aus der Spezialzone herausgezogen und an normale Infrastrukturprinzipien angeschlossen. Routbarkeit, Cachebarkeit, Policies, Load Balancing und interaktive Rueckfragen muessen nicht mehr gegeneinander arbeiten.

Wenn sich diese Richtung durchsetzt, dann werden sich in den kommenden Monaten nicht nur Modelle vergleichen lassen. Dann wird sichtbarer, welche Anbieter Agenten wirklich als belastbare Softwaresysteme denken.

Weiterfuehrende Beitraege auf menzel.works

Quellen

KI-Hinweis: Dieser Beitrag wurde mit Unterstuetzung von KI recherchiert, strukturiert und formuliert.

Frage zu diesem Inhalt?
Kurz schreiben.
Kontakt