Stateless MCP, Stateful Phone Agents: Android Workflow Architecture Playbook
Dean and the FoneClaw product team explain MCP 2026-07-28 stateless transport, explicit state handles, Tasks, MRTR, approvals, and the stateful Android phone-agent layer reliable workflows still need.
- MCP 2026-07-28 makes the protocol core stateless: requests are self-describing, can route to compatible server instances, and use extensions for richer behaviors.
- Stateless MCP still supports stateful agent workflows when task, approval, auth, device, audit, and recovery state live in the application layer instead of hidden transport sessions.
- MCP Tasks, MRTR, elicitation, and explicit state handles help long-running workflows while keeping authorization, approval, and phone state as separate responsibilities.
- Reliable Android phone-agent workflows need idempotency, device-state rechecks, visible approval, result verification, correlation records, and recovery after failure.
What MCP 2026-07-28 Changed
The July 28, 2026 Model Context Protocol release matters because it separates transport simplicity from application responsibility. The MCP 2026-07-28 specification overview introduces a stateless protocol core. Requests are self-describing, compatible server instances can handle them without relying on a mandatory long-lived protocol session, and richer behavior moves into explicit mechanisms such as metadata, discovery, MRTR, header routing, cacheable lists, authorization hardening, and an extensions framework.
The standards work behind that release makes the design intention clearer. SEP-2575: Make MCP Stateless removes the mandatory initialization handshake for the stateless-first model and replaces session-negotiated assumptions with per-request metadata. The important design lesson for phone agents is straightforward: the connector protocol can scale as stateless transport while the phone-agent application remains deeply stateful.
We care about this at FoneClaw because phone workflows are full of state. A user may start a task from the floating assistant, attach current-screen context, approve a message, recover a missing permission, or stop an action before completion. The connector request can be self-contained, but the host has to remember the user's task, approval, device state, and result. Agentic Resource Discovery: ai-catalog.json, Tool Trust, and Phone Agent Authorization explains the adjacent trust problem: discovery and authorization need explicit records rather than implicit assumptions.
How the Stateless MCP Request Lifecycle Works
A stateless MCP request lifecycle starts with enough information in each request for a compatible server instance to understand what is being asked. Metadata tells the server about capabilities, identity context, version expectations, or routing needs. Discovery can be requested or cached. Header routing can help infrastructure send the request to the right class of service. Cacheable lists reduce repeated negotiation when tools, prompts, or resources are stable enough to reuse.
The server no longer needs to depend on a hidden transport session to remember earlier setup. That makes round-robin deployment, serverless execution, restarts, scaling, and failover easier. Another compatible instance can receive the next self-contained request. This is the infrastructure win: MCP can behave more like normal web transport while preserving a clear protocol shape for agent systems.
Stateful applications still need explicit state references. SEP-2567: Sessionless MCP via Explicit State Handles describes how implicit protocol session state can be replaced by server-minted handles threaded through later calls. A handle can identify a long-running task, cursor, partial operation, or other server-side state reference.
That handle is a reference, not the whole workflow. A phone agent still needs its own task ledger, approval record, auth state, device-state reading, retry policy, and audit trail. Every feature also does not become a single request. Long-running work can use explicit handles, Tasks, polling, cancellation, or follow-up calls while the protocol core stays stateless.
Six Kinds of State a Phone Agent Must Own
When we build phone-agent workflows at FoneClaw, we separate state into ledgers. This keeps stateless MCP stateful agent workflows understandable. The protocol request can be stateless, but the Android host has to own the user-facing state that makes the phone task reliable.
| State ledger | Owner | Why it matters for phone workflows |
|---|---|---|
| Conversation state | Agent host and model context | Tracks the user's request, clarifications, preferences, and current intent. |
| Task state | Phone-agent host | Tracks whether work is planned, running, waiting, blocked, approved, stopped, verified, or recovered. |
| Device state | Android host, re-read at execution time | Tracks the current app, screen, permission, default handler, setting state, and visible controls. |
| Approval state | Phone-agent host | Records what the user approved, for which task, target, payload, and consequence. |
| Auth state | Identity and connector layer | Controls which service, account, or tool may be called. Approval and authentication stay separate. |
| Audit and recovery state | Phone-agent host | Records request IDs, idempotency keys, observed results, failures, retries, user stops, and repair steps. |
Device state deserves special attention. A phone can change between planning and execution. The user may switch apps, the screen may refresh, a permission may be revoked, or a Send button may move. A reliable phone agent re-reads device state before external effects. For a deeper governance model, AI Agent Identity, Permissions, and Audit Trails for Phone Tool Governance explains how identity, permission, and audit records fit together.
MCP Tasks, MRTR, Elicitation, and Approvals
MCP 2026-07-28 also matters because it gives long-running agent work a cleaner shape. The release includes MRTR and an extensions framework, and Tasks is a formal extension. In plain language, this lets systems handle work that spans more than one immediate request-response turn while preserving a stateless protocol core.
MRTR gives model-driven systems a way to interact across tool/resource flows instead of squeezing everything into one call. Elicitation gives the application a route to ask the user for missing information. Tasks can represent long-running work through task handles, status checks, cancellation, and completion patterns. Those mechanisms fit phone workflows well because Android tasks often pause for user input, permission recovery, or a visible approval.
The important split is approval versus authorization. A task handle can identify work, and an auth token can permit a service call. User approval records the human decision for a specific action. For example, a connector may be authenticated to a messaging service, while the user still reviews the recipient and body before sending. A task handle carries continuity; it does not become permission to perform every later effect.
That distinction is exactly how we think about phone agent task state. Sensitive actions need the target, consequence, and approval attached to the task. Cancellation and expiry should be part of the record too: if the user stops the task, if the handle expires, or if the device state becomes stale, the workflow should return to a visible recovery path.
A Stateful Android Workflow Over Stateless MCP
Consider a visible SMS workflow as an architecture example. The user says, "Text Morgan that I will arrive at 4:30." The phone-agent host captures intent, checks contacts, verifies the default messaging path, and prepares a task record. If a stateless MCP connector is involved for some service capability, the host sends a self-describing request with metadata, a correlation ID, an idempotency key, and only the state references needed for that call.
The request may land on any compatible stateless MCP server instance. The server handles its part and returns a structured response or task handle. The phone-agent host then rechecks Android device state before action: current app, permission, visible recipient, full message body, and stable Send control. The user's approval is recorded against the task, recipient, body, and consequence.
Execution happens through the Android side, not through transport magic. FoneClaw today is useful as a host-state analogy: the current FoneClaw release information describes floating-assistant task continuity, permission recovery, and quick actions. Current governed Android workflows include visible messaging, Do Not Disturb, dialer preparation, navigation handoff, and selected settings actions. The user-facing product capabilities are summarized on FoneClaw Features. This article uses that behavior to show host-side state ownership; it does not assert current MCP 2026-07-28 or MCP Tasks support in FoneClaw.
If execution fails, the idempotency key prevents careless duplication, the correlation ID links the retry to the same task, and verification decides the next step. A stale screen may require reattachment. A missing permission may trigger recovery. An ambiguous Send control may keep the draft visible for manual completion. For current-screen continuity in the Android host, Android Floating AI Assistant: Use Current-Screen Context Safely explains how user-triggered context can support phone tasks. For call-specific protocol decisions, AI Agent Phone Calls: MCP Calling Services vs Android Dialer Control keeps that deeper topic separate.
Scale MCP Servers Without Losing Phone-Task Reliability
Stateless MCP servers make infrastructure more flexible. A platform can load-balance requests, restart instances, scale serverless workers, cache discovery responses, and route by headers or capabilities. The MCP Go SDK v1.7.0 release is one official SDK example for protocol 2026-07-28, with per-request metadata, server discovery, and compatibility paths for legacy protocol versions.
Reliability for phone tasks requires more than routing. External effects need deduplication and verification. A retry after a network timeout may be harmless for a read operation and risky for a send, delete, purchase, or settings change. The agent host should classify retries by effect: read-only, idempotent write, approval-required effect, or manual-recovery step. Each class needs its own policy.
Idempotency is the bridge between scalable servers and real-world phone actions. The host should attach an idempotency key to any operation that could repeat. It should store a correlation ID for logs and audit. It should verify the observed result after execution instead of trusting a transport response alone. When an operation has side effects, compensation or user-visible recovery may be needed.
This is the same lesson we apply to recorder-to-action workflows. AI Recorder MCP: How Meeting Notes Become Confirmed Phone Actions shows why notes, suggested actions, approvals, and phone execution need separate records even when an upstream connector can produce useful structured output.
Security Boundaries and a Migration Checklist
The 2026-07-28 MCP release includes authorization hardening, and phone-agent builders should treat that as the starting point rather than the whole security model. Authentication proves which client, user, or service may call something. Approval records the human decision for a specific task. Permission describes what Android or the service allows. Audit records what happened. These states support each other, but each has its own job.
Backward compatibility needs planning. Some clients and servers will use earlier lifecycle assumptions. The Go SDK release notes preserve compatibility paths for legacy protocol versions, which is the right migration signal: negotiate capability, test both lifecycles, and avoid assuming every connector has upgraded. A stateless-first connector should still report version, supported extensions, discovery behavior, and state-handle semantics clearly.
Our migration checklist for a phone-agent team is direct:
- Move hidden protocol-session assumptions into explicit metadata, handles, or application state.
- Keep conversation, task, device, approval, auth, and audit ledgers separate.
- Attach idempotency keys and correlation IDs to operations with external effects.
- Re-read device state before sending, changing settings, dialing, navigating, or deleting.
- Record approvals by task, target, payload, and consequence.
- Classify retries by side effect and route risky retries to user-visible recovery.
- Support legacy protocol negotiation during migration.
- Test cancellation, expiry, denial, timeout, and stale-device-state paths.
For a FoneClaw connector design, we would require explicit capability discovery, scoped authorization, task-bound approval, Android permission awareness, idempotent request handling, result verification, and clear recovery. Stateless transport is a strong foundation when the application layer owns the state that users actually depend on.