Stateless MCP und stateful Agent-Workflows: Phone-Agent-Architektur für Android
MCP 2026-07-28 macht den Protokollkern zustandslos. Dean erklärt, wo ein Android Phone Agent Task State, Freigaben, Wiederherstellung und Audit trotzdem führen muss.
- MCP 2026-07-28 macht den Protokollkern zustandslos: Anfragen sollen sich selbst beschreiben und ohne verpflichtende Transport-Sitzung an passende Serverinstanzen geroutet werden können.
- Zustandslose MCP-Server schließen stateful Agent-Workflows nicht aus; Task-Zustand, Gerätebild, Freigaben, Authentifizierung, Wiederherstellung und Audit gehören in die Anwendungsebene.
- Für Android Phone Agents muss der Host sechs Zustände sauber führen: Gespräch, Aufgabe, Gerät, Freigabe, Authentifizierung und Nachvollziehbarkeit.
- FoneClaw zeigt nach dem bisher neuesten Produktstand als heutige Android-Basis, warum Task-Kontinuität, Berechtigungswiederherstellung und sichtbare Ergebnisse unabhängig von einem externen Protokolltransport gehalten werden müssen.
Was MCP 2026-07-28 geändert hat
Stateless MCP und stateful Agent-Workflows wirken auf den ersten Blick wie ein Widerspruch. Für Phone Agents ist genau diese Trennung aber der richtige Entwurf. Die finale MCP-Spezifikation vom 28. Juli 2026 führt einen zustandslosen Protokollkern ein. Anfragen sollen sich selbst beschreiben, zu passenden Instanzen geroutet werden können und ohne verpflichtende Transport-Sitzung auskommen. Gleichzeitig bleiben Anwendungen frei, eigenen Zustand sauber und explizit zu führen.
Der Standardwechsel passt zu dem, was wir beim Bauen von FoneClaw täglich sehen: Ein Protokolltransport sollte skalierbar, wiederholbar und gut routbar sein. Eine echte Android-Handyaufgabe braucht trotzdem Erinnerung an Ziel, Gerät, Berechtigung, Freigabe, Ergebnis und Wiederherstellung. Der Transport kann zustandslos werden; der Phone-Agent-Host muss stateful bleiben.
Die Standardsarbeit beschreibt diese Richtung auch in SEP-2575 zu zustandslosem MCP. Dort wird die verpflichtende Initialisierungssitzung für das stateless-first Modell entfernt und per-request Metadaten ersetzen viele stillschweigende Sitzungsannahmen. Die MCP-Veröffentlichung ergänzt außerdem MRTR, Header-Routing, cachebare Listen, Härtungen bei Autorisierung und ein Erweiterungsmodell, zu dem Tasks als formale Erweiterung gehört.
Für FoneClaw ist MCP 2026-07-28 aktuell ein Architekturmaßstab für künftige Connector-Designs. Unsere heutige Android-App nutzt ihre eigene Ausführungsebene; die Lehre ist übertragbar: Der Protokollserver sollte kein verstecktes Gedächtnis für eine Telefonaufgabe sein. Der Agent-Host führt den Task State explizit.
Wie der zustandslose MCP-Anfragezyklus funktioniert
Ein zustandsloser MCP-Server verarbeitet eine Anfrage anhand der Informationen, die diese Anfrage mitbringt oder explizit referenziert. Identität, Fähigkeiten, benötigte Metadaten, angefragte Ressource und optionale Zustandsverweise werden nicht aus einer alten Transport-Sitzung erraten. Das macht Load Balancing, serverlose Deployments, Neustarts und regionale Verteilung einfacher.
In der Praxis kann ein Client Fähigkeiten entdecken, Listen cachen, Header für Routing nutzen und dann eine selbstbeschreibende Anfrage an eine kompatible Instanz schicken. Wenn längerer Zustand nötig ist, gehört er in einen expliziten Verweis. SEP-2567 zu expliziten State Handles beschreibt, wie impliziter Protokoll-Sitzungszustand durch servergeprägte Handles ersetzt werden kann, die spätere Aufrufe mitführen.
Für Phone Agents ist die Übersetzung wichtig: Ein State Handle ist ein Verweis, kein vollständiger Aufgabenvertrag. Ein Handle kann auf eine laufende Serverarbeit, eine Ressource oder einen Zwischenstand zeigen. Die Android-Aufgabe braucht zusätzlich App-Zustand, Gerätekontext, Freigabe, Idempotenz, Ergebnisprüfung und Audit. Diese Zustände gehören beim Agenten und seinem Host zusammen, damit ein Nutzer nach einer Unterbrechung erkennt, was passiert ist.
Ressourcensuche und Vertrauensprüfung bleiben ebenfalls Teil der Architektur. Wenn ein Agent externe Fähigkeiten entdeckt, muss er wissen, welcher Anbieter, welche Berechtigung und welche Version beteiligt sind. Für diese Seite der Agentenwelt vertieft Agentic Resource Discovery: Ressourcensuche, ai-catalog.json und Vertrauen für Phone Agents, wie vertrauenswürdige Entdeckung in der Praxis aussehen kann.
Sechs Zustände, die ein Phone Agent selbst führen muss
Aus FoneClaw-Sicht braucht ein zuverlässiger Android Phone Agent sechs getrennte Zustandsbücher. Sie dürfen zusammenarbeiten, aber sie sollten nicht in einem unsichtbaren Transport-Sessionzustand verschwinden. Genau diese Trennung macht Wiederaufnahme, Freigabe und Fehlerbehebung verständlich.
| Zustand | Was er enthält | Wer ihn führen sollte |
|---|---|---|
| Gesprächszustand | Letzte Nutzerabsicht, Rückfragen, Korrekturen, relevante Formulierungen. | Agent und Modellkontext, mit sparsamer Aufbewahrung. |
| Aufgabenzustand | Ziel, aktueller Schritt, offene Entscheidung, Ergebnis, Abbruch- oder Fortsetzungspunkt. | Phone-Agent-Host, weil er den Ablauf über Oberflächen und Tools hinweg trägt. |
| Gerätezustand | Aktuelle App, sichtbarer Bildschirm, Berechtigungen, Netzwerk, SIM-Auswahl, Einstellungsstatus. | Host liest ihn frisch, weil Android-Zustand schnell veraltet. |
| Freigabezustand | Welche Wirkung der Nutzer für welche Aufgabe bestätigt hat. | Host und Freigabeprotokoll, getrennt von Authentifizierung. |
| Authentifizierungszustand | Identität, Token, Dienstzugriff, Ablaufzeit, Erneuerung. | Auth-Schicht, mit minimalem Zugriff für einzelne Aufgaben. |
| Audit-Zustand | Was angefragt, freigegeben, ausgeführt, geprüft, abgebrochen oder wiederhergestellt wurde. | Agent-Host und Protokollierung, sichtbar für den Nutzer. |
Freigabe und Authentifizierung sind dabei verschiedene Dinge. Ein gültiger Dienstzugang erlaubt dem Agenten, eine Fähigkeit anzufragen. Eine Freigabe bestätigt, dass der Nutzer diese konkrete Wirkung jetzt möchte. Ebenso muss Gerätezustand immer wieder neu gelesen werden: Eine App kann wechseln, ein Dialog kann erscheinen, eine Berechtigung kann entzogen werden, oder der Bildschirm kann durch den Nutzer verändert werden.
FoneClaw führt solche Zustände heute hostseitig für unterstützte Android-Aufgaben. Nach dem bisher neuesten Produktstand stärkt FoneClaw diese Idee durch schwebenden Zugriff, Kontinuität auf demselben Telefon, Berechtigungswiederherstellung und schnelle Aktionen. Die aktuellen Informationen stehen auf der FoneClaw-Downloadseite. Wer Identität, Berechtigungen und Nachvollziehbarkeit tiefer verstehen möchte, findet in Identität von KI-Agenten: Berechtigungen, Genehmigungen und Audit-Trails für Phone Agents die passende Vertiefung.
MCP Tasks, MRTR, Rückfragen und Freigaben
MCP 2026-07-28 bringt mit MRTR und Tasks wichtige Bausteine für längere Interaktionen. MRTR unterstützt Interaktion, wenn ein Server während einer Arbeit zusätzliche Informationen oder Nutzerentscheidungen braucht. Tasks sind eine formale Erweiterung für Arbeit, die über eine einzelne Anfrage hinausgeht. Für Phone Agents ist das nützlich, solange diese Bausteine nicht mit vollständiger Telefonaufgaben-Autorisierung verwechselt werden.
Ein Task Handle kann auf eine laufende Arbeit zeigen: Datei wird vorbereitet, Ressource wird gesucht, Auswertung läuft, Ergebnis wird später abgeholt. Für Android reicht dieses Handle allein nicht aus. Wenn die Aufgabe später eine SMS senden, Nicht-stören ändern, eine Navigation starten oder einen Anruf vorbereiten soll, braucht der Phone-Agent-Host weiterhin eine konkrete Freigabe an der Stelle der Wirkung.
Rückfragen gehören in denselben Ablauf. Wenn ein Server fragt, welcher Kontakt gemeint ist, kann der Agent diese Klärung in den Aufgabenzustand schreiben. Wenn der Nutzer danach eine Freigabe gibt, wird sie mit Ziel, Aktion, Gerät und Zeitpunkt verknüpft. Ablauf, Freigabe und Audit bleiben beim Agenten nachvollziehbar, während MCP die einzelnen Connector-Anfragen transportiert.
So entsteht eine klare Arbeitsteilung: MCP Tasks helfen, länger laufende Connector-Arbeit sichtbar zu referenzieren. Der Phone-Agent Task State hält Nutzerabsicht, Android-Zustand, Freigabe, Wiederherstellung und Ergebnis zusammen. Diese Trennung ist der Kern zuverlässiger stateful AI Agent Architektur.
Ein stateful Android-Workflow über zustandsloses MCP
Nehmen wir eine konkrete Aufgabe: „Bereite eine SMS an Mara vor, dass ich zehn Minuten später komme, und sende sie nach Prüfung.“ In einer Architektur mit zustandslosem MCP würde der FoneClaw-Host zuerst die Absicht aufnehmen, den Kontakt klären und den lokalen Aufgabenstand anlegen. Danach kann er einen Connector über eine selbstbeschreibende Anfrage aufrufen: gewünschte Fähigkeit, Empfängerreferenz, Text, Idempotenzschlüssel und ein expliziter Aufgabenbezug.
Vor jeder externen Wirkung liest der Host den Gerätezustand frisch. Ist die Standard-SMS-App verfügbar? Ist der Empfänger eindeutig? Liegt der vollständige Text vor? Gibt es genau eine stabile Senden-Schaltfläche? Muss eine Dual-SIM-Auswahl sichtbar werden? Diese Prüfung gehört zur Android-Ausführung, nicht zum bloßen MCP-Transport.
Der Nutzer sieht den Entwurf und gibt die konkrete Aktion frei. Die Freigabe wird mit Aufgabe, Empfänger, Text und Zeitpunkt verbunden. Wenn der Connector-Aufruf wiederholt werden muss, schützt ein Idempotenzschlüssel davor, dieselbe Wirkung doppelt auszulösen. Nach der Ausführung prüft der Host das Ergebnis: Entwurf erstellt, Nachricht gesendet, Dialog offen, Berechtigung fehlt oder Nutzerübernahme nötig.
Ein zweites Beispiel ist Nicht-stören. Der Agent plant eine Änderung, liest den aktuellen Zustand, zeigt Dauer und Ausnahmen an, holt Freigabe ein, führt die unterstützte Änderung aus und verifiziert den neuen Zustand. Wenn Android eine Berechtigung verlangt, führt FoneClaw den Nutzer in die Wiederherstellung und hält den Aufgabenstand. Die aktuelle FoneClaw-Erfahrung mit schwebendem Assistenten und bewusstem Bildschirmkontext wird in Schwebender Android KI-Assistent: aktuellen Bildschirm sicher als Kontext nutzen genauer erklärt.
Für Anrufe gilt dieselbe Logik. MCP kann eine Connector-Fähigkeit referenzieren, der Android-Dialer bleibt aber ein eigener Ausführungsbereich. Die call-spezifische Entscheidung zwischen Protokollfähigkeit und nativem Wählfeld behandelt Telefonanrufe mit KI-Agenten: MCP-Calling oder Android-Wählfeld mit FoneClaw.
MCP-Server skalieren, ohne Telefonaufgaben zu verlieren
Zustandslose MCP-Server bringen Infrastrukturvorteile: Instanzen können hinter einem Load Balancer laufen, neu starten, regional skaliert oder serverlos ausgeführt werden. Eine Anfrage trägt die nötigen Metadaten oder expliziten Handles mit. Die MCP Go SDK Version 1.7.0 zeigt als offizielle SDK-Umsetzung Unterstützung für das Protokoll 2026-07-28, per-request Metadaten, Server Discovery und Kompatibilitätspfade für ältere Versionen.
Telefonaufgaben brauchen zusätzlich Wiederholungsregeln. Ein reiner Lesevorgang kann oft erneut ausgeführt werden. Eine externe Wirkung wie SMS senden, Einstellung ändern, Datei löschen oder Anruf starten braucht Deduplizierung, Ergebnisprüfung und klare Einordnung: Wurde die Aktion bereits angewendet? Ist nur die Antwort verloren gegangen? Muss der Nutzer neu freigeben? Welche Folgeaktion ist sicher?
Idempotenz ist deshalb ein Pflichtbaustein. Jeder wirkende Schritt erhält einen stabilen Schlüssel, eine Aufgabenreferenz und ein erwartetes Ergebnis. Korrelation verbindet Logs, UI-Status und Connector-Aufrufe. Audit hält fest, welche Anfrage gestellt, welche Freigabe erteilt, welcher Versuch gestartet und welches Ergebnis beobachtet wurde. So kann der Phone-Agent-Host nach Netzwerkfehler, App-Wechsel oder Serverneustart erklären, wo die Aufgabe steht.
Diese Muster gelten auch für andere Eingangsquellen. Ein Sprachrekorder, der aus einer Notiz eine Handyaktion macht, braucht dieselbe Trennung von Transport, Task State und Android-Wirkung. Für diesen Nachbarfall vertieft KI-Rekorder mit MCP: Von Notizen zu Smartphone-Aktionen, wie aus einem aufgezeichneten Gedanken ein kontrollierter Telefonablauf werden kann.
Sicherheitsgrenzen und Migrationscheckliste
MCP 2026-07-28 bringt neben dem zustandslosen Kern auch Härtungen bei Autorisierung und ein Erweiterungsmodell. Für Phone Agents bleibt die wichtigste Regel: Authentifizierung, Freigabe und Android-Berechtigung sind getrennte Zustände. Ein Token beweist Dienstzugang. Eine Android-Berechtigung erlaubt Zugriff auf einen Gerätebereich. Eine Nutzerfreigabe bestätigt eine konkrete Wirkung. Ein Task Handle referenziert Arbeit. Diese vier Dinge sollten in einer zuverlässigen Architektur nie zu einem einzigen „darf schon“-Signal verschmelzen.
Für Migrationen hilft ein gestufter Plan. Erstens: Protokollversionen aushandeln und ältere Clients über kompatible Pfade bedienen. Zweitens: alle impliziten Sitzungsannahmen finden. Drittens: per-request Metadaten und explizite State Handles einführen. Viertens: Idempotenzschlüssel für wirkende Aktionen verpflichtend machen. Fünftens: Freigaben als eigene Datensätze modellieren. Sechstens: Gerätedaten vor Wirkung frisch lesen. Siebtens: Audit und Nutzerstatus so verbinden, dass Wiederherstellung verständlich bleibt.
Für einen zukünftigen FoneClaw-Connector würden wir genau diese Punkte verlangen: selbstbeschreibende Anfragen, minimale Datenweitergabe, klare Fähigkeitserklärung, idempotente Wirkung, getrennte Authentifizierung und Freigabe, sichtbare Fehler, Abbruch, Ablaufzeit, Wiederherstellung und Ergebnisprüfung. Die heutige FoneClaw-App belegt bereits den Host-Gedanken: Task-Kontinuität, Berechtigungswiederherstellung und geregelte Android-Aktionen gehören in die Telefonerfahrung. Die aktuelle Fähigkeitsübersicht steht auf der FoneClaw-Funktionsseite.
Die kurze Architekturformel lautet: MCP kann zustandslos skalieren; der Phone Agent muss den relevanten Anwendungszustand besitzen. Genau dort entsteht Verlässlichkeit für Android-Workflows: nicht in einer versteckten Transport-Sitzung, sondern in einem expliziten Aufgabenmodell mit Freigabe, Idempotenz, Verifikation, Audit und Wiederherstellung.