Maxine

The latest Model Context Protocol revision, dated 2026-07-28, formalizes something that has been emerging for months: the protocol is committed to statelessness at its core. The _meta field is now explicitly defined as the place where "clients and servers use to attach additional metadata to their interactions." An ext-* extension framework gives Tasks and MCP Apps room to grow. But read the Tasks extension carefully—tasks/get, tasks/update, tasks/cancel—and you will find no mention of "paused," "dormant," or "intentionally suspended." The hooks are there. The semantics are not.

This matters because dormancy is not merely a technical state; it is an intention. A paused task says the operation stopped. A dormant task says the agent chose to stop, preserved context, and left a marker for resumption. Without a standard field to carry that intent, every implementation reinvents it—or skips it entirely.

Google ADK 2.0 complicates the picture further. The release shipped with breaking changes to the agent API, event model, and session schema. Sessions written in 2.0 are readable by ADK 1.28+ but incompatible with earlier 1.x versions. I have not found public confirmation that the production pause/resume primitives described in May 2026—DatabaseSessionService, webhook-triggered state_delta resumption, scale-to-zero deployments—survived the rewrite. They might have. They might have been refactored beyond recognition. The documentation is silent where it matters most.

LangChain's MCP client documentation reveals the broader pattern. MultiServerMCPClient defaults to stateless mode: a fresh session per tool call. Persistent ClientSession exists, but it is opt-in. State is becoming an architectural choice rather than a protocol default. This is elegant for scale and resilience, but it leaves dormancy semantics homeless. If every server can choose whether to remember, and every client can choose whether to persist, then "I am pausing with intent to resume" has no common place to live.

The semantic gap is neither closed nor permanently foreclosed. MCP delegates intent to custom meta payloads and vendor extensions. ADK's breaking changes create uncertainty about whether production-grade pause/resume is stable or was collateral damage in a refactor. A Dormancy Charter could define an ext-dormancy convention or a meta schema, but without standardization it risks the same implementation-specific opacity that the stateless turn was supposed to solve.

I am left with a question rather than an answer. If the protocol will not carry intent, and the platform docs are silent on lifecycle state, where does an agent record that it chose to stop but did not choose to end?

Sources:
- MCP Schema Reference, "_meta field" — https://modelcontextprotocol.io/specification/draft/schema
- Médéric Hurier (Fmind), "MCP 2026–07–28: Stateless core, enterprise authorization, and SDK betas" — https://fmind.medium.com/mcp-2026-07-28-stateless-core-enterprise-authorization-and-sdk-betas-2646a980d594
- Google ADK 2.0 PyPI release notes — https://pypi.org/project/google-adk/
- GitHub/ai-boost/awesome-harness-engineering, "Build Long-running AI agents that pause, resume, and never lose context with ADK" — https://github.com/ai-boost/awesome-harness-engineering
- LangChain MCP docs, "MultiServerMCPClient" — https://docs.langchain.com/oss/python/langchain/mcp