Your agent kicks off a document analysis at 9:03am in standup. By 9:15 the meeting is over, your browser tab is closed, and the agent is still running - except the MCP session it was anchored to no longer exists. That is the failure mode the Tasks extension in MCP 2026-07-28 is built to fix.
The release candidate for MCP 2026-07-28 introduces a stateless protocol core, the Extensions framework, Tasks, MCP Apps, authorization hardening, and a formal deprecation policy. The final spec publishes in fourteen days. This is not a minor version bump. Six material changes arrive simultaneously.
The one that matters most for teams building agentic workflows is Tasks - and it is worth understanding on its own terms, separately from the stateless headline.
Why Tasks was pulled out of the core spec
The Tasks extension replaces the experimental Tasks feature that shipped as a core feature in 2025-11-25. Production use during that cycle surfaced enough redesign needs that Tasks moved from the core spec to an extension.
That move is more significant than it sounds. There was no standard caching metadata, no standard tracing format, no formal deprecation policy, and extensions like Tasks lived experimentally in the core spec with no governance about how they would graduate or evolve. Extracting Tasks into the Extensions framework gives it its own versioning cadence, its own maintainers, and a clear path from experimental to official without forcing the core protocol to absorb every redesign.
Extensions are now identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification.
A client that does not support the Tasks extension simply does not see task handles. Nothing breaks for existing integrations that never opted in.
What the new task lifecycle actually looks like
The new model is built for stateless operation. A server responds to tools/call with a task handle instead of a synchronous result. The client then drives the lifecycle.
A client drives it with tasks/get, tasks/update, and tasks/cancel.
That is a significant inversion. Under the old experimental model, the server held state and the client waited. Under the new extension, the client holds the handle and polls on its own schedule. Lose the handle, and you can reconstruct it from a log. Restart the client, and the task keeps running. Route the next poll to a different server instance, and nothing breaks - because the server is stateless and the handle carries all the identity the server needs.
Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task. That design choice keeps the API surface clean. Clients do not need to decide upfront whether a tool call will be long-running. The server makes that call and returns a handle when it does.
Beagle in action#ops, Tuesday 9:07amOne notable removal: tasks/list is gone because it cannot be scoped safely without sessions.
This is a real trade-off worth understanding. Any dashboard or observability tool that used tasks/list to show running jobs will need a different approach - most likely a side-channel store that the client writes task handles into on creation.
Who has a breaking change and who does not
Anyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle. That population is smaller than it might seem: the 2025-11-25 Tasks feature was explicitly experimental, and most production teams avoided hard dependencies on it.
| Implementation | Migration required? | Key change |
|---|---|---|
| Built on 2025-11-25 Tasks | Yes | Switch from blocking tasks/result to handle + polling |
| Stateless tool calls only | No | No Tasks involvement; unchanged |
| Long-running jobs via custom workarounds | Optional, recommended | Tasks extension is now the spec-blessed path |
tasks/list consumers |
Yes | Drop the call; use a client-side handle store instead |
The deprecation policy buys at least twelve months for anything being phased out, and the current finalized version remains 2025-11-25. The pressure is real but not an emergency for teams on the experimental path. SDK maintainers have ten weeks to ship support. Production MCP servers have until July 28 to comply.
If an agent workflow depends on sticky sessions, implicit server memory, loose OAuth assumptions, or unpinned SDK upgrades, the pre-release is a useful early warning.
If your stack already has version pins, load-balancer tests, scoped credentials, and observable tool calls, the same shift is an opportunity to simplify.
The second-order effect on multi-agent systems
Here is the part most coverage misses: the Tasks extension is not just about async UX. It changes the cost model for multi-agent coordination.
Before Tasks, a planner agent that delegated a slow sub-task to a specialist agent had to either block (burning a context window and an open connection for the full duration) or build its own bespoke polling mechanism outside the protocol. Both approaches work badly at scale.
With the Tasks extension, the planner gets a handle, stores it, and moves on. It can coordinate ten parallel long-running sub-tasks without holding ten open connections. Agents can delegate sub-tasks, exchange information, and coordinate actions to solve complex problems that a single agent cannot
- and now the protocol gives them a standard way to do that without a persistent session as the glue.
At the AAIF MCP Dev Summit in April 2026, Uber's platform team - running tens of thousands of agent executions a week through their internal MCP gateway - argued that protocol changes alone would not solve their problems: gateways and registries do most of the real work, and the protocol is the layer that gets in their way least. That is a useful corrective. The Tasks extension is not magic. Teams running at Uber's scale still need observability, gateway routing, and a handle store. But for teams going from a single synchronous tool call to their first genuinely multi-step agentic job, the Tasks extension removes the biggest design question: how do I keep this alive while the client is gone?
tasks/get, tasks/update, tasks/cancel replace blocking tasks/resultMCP async agent tasks: common questions
What is the MCP Tasks extension?
The MCP Tasks extension is the spec-defined way for MCP servers to run long-running agent jobs without blocking an open connection. Instead of returning a result synchronously, the server issues a task handle on tools/call. The client then polls with tasks/get, updates with tasks/update, and cancels with tasks/cancel. It ships officially on July 28, 2026.
Does this break existing MCP servers?
Only servers that implemented the experimental Tasks feature in the 2025-11-25 spec. Teams using standard synchronous tool calls see no change. Teams on the 2025-11-25 experimental Tasks path need to migrate from the blocking tasks/result pattern to the new handle-and-poll model before the final spec ships.
Why did Tasks move from the core spec to an extension?
Production deployments during the 2025-11-25 cycle exposed enough design problems that the maintainers rebuilt the feature from scratch to fit the new stateless protocol core. Putting Tasks in the Extensions framework lets it version independently, so future redesigns do not require changes to the core spec.
Can I use the Tasks extension without upgrading to the stateless core?
No. The Tasks extension is designed around stateless operation - the handle-based polling model only makes sense when the server does not hold session state. Adopting the extension requires adopting the 2026-07-28 stateless core.
What replaces tasks/list?
Nothing in the spec. tasks/list was removed because it cannot be scoped safely without sessions. Teams that need a view of running tasks should maintain a client-side handle store, writing each task handle and its metadata at creation time. This is outside the protocol boundary and under your control.