MCP Tasks Explained: The Async Gap Agents Can't

The pitch for AI agents is clean: you give them work, they do it. The reality is messier. Networks drop. Servers restart. Humans wander off on vacation. A protocol that assumes every tool call resolves in a single round trip is a protocol that fails the moment the work gets interesting.

That gap — between the request-response world MCP was built for and the long-running, human-involving, crash-surviving work agents actually need to do — is exactly what Cornelia Davis laid out in a recent talk at the AI Engineer conference. Davis is a distributed systems veteran at Temporal who literally wrote the book on cloud native patterns, and she came with a live demo, a lot of opinions, and a question that doubles as an indictment of the current state of agent tooling: why aren't any agents supporting MCP tasks?

Her first answer is the charitable one: "Well, cuz they're smart." The MCP tasks specification that shipped in November was marked experimental, and as Davis walks through the spec's architecture, the wisdom of that caution becomes obvious.

The problem is durability, and durability is hard

A task, in MCP terms, is what you get when a tool call can't resolve immediately. Instead of a response, you get a handle — an identifier you can use to check status, receive updates, and signal input back into the running process. Simple enough in the abstract.

The moment you ask that system to survive real infrastructure conditions, the complexity compounds. "The longer something runs, the more likely there's going to be some kind of infrastructure blip," Davis explains. Clients disconnect. Servers crash. The human whose approval you're waiting on takes a two-week holiday. The spec is unambiguous that a launched task must be durable — it has to survive all of this and remain interactable when things come back online. That requirement sounds reasonable until you try to build it.

Davis demonstrated the concept with an invoice processing flow: a purchase order triggers parallel back-office work alongside an MCP tool that validates against an ERP, waits for human approval, reconciles again, and ultimately pays the invoice. The tool is inherently multi-step and multi-day. It's exactly the kind of work that breaks if you try to hold a connection open for its entire duration.

The dashboard she showed cycling through states — submitted, working, input required — is the user-facing expression of a task lifecycle that the spec carefully defines. Tasks move through working to input-required and back, eventually landing at completed, canceled, or failed. Getting those transitions right on both server and client, across disconnections, is the work.

What was wrong with V1

The November specification, which Davis calls tasks V1, made two design choices that created problems at scale.

The first was task/list — an endpoint that let a reconnecting client ask the server what tasks it had. Conceptually sensible. Practically a disaster. "What happens if you've got a whole slew of agents out there and you've got a million tasks at the back end?" Davis asks. "Spoiler alert, there is no filter on that endpoint." A recovering client would need to page through the entire task list to find the one it cared about. This is the kind of design decision that's fine in a demo and catastrophic in production.

The second problem was task/result, which handled the input-required state by holding open a long-running connection and having the server elicit a response from the client through it. Davis describes the implementation as "really quite ugly" — and she would know, because she built one. When she shows the client-side protocol handler her team implemented, it's a tangle of connection management, reconnection logic, and state recovery. "Back to the question of why the heck aren't there any clients that are supporting this protocol? Yeah. That's why. Super involved."

What's notable here is that Davis isn't criticizing the spec for lacking ambition — she's pointing out that V1 tried to solve the hardest parts of the problem using mechanisms that create new hard problems. A stateful server-side task list is a scaling liability. A server-that-elicits-from-client through a persistent connection is an inversion of the natural request direction that makes reconnection logic genuinely painful.

V2 and the governance story behind it

In May, Angie Jones — whose blog post Davis credits as the signal that substantial changes were coming — announced that the protocol was going stateless. For anyone who's spent time in distributed systems, that's significant. Stateful protocols don't compose well, don't scale horizontally, and make every failure scenario harder. Going stateless is the right call.

V2 makes two structural changes that matter. First, the stateless core: task/list disappears entirely, replaced by a client-side obligation to persist task IDs. The spec currently uses "should" rather than "must" for this persistence requirement, which Davis finds puzzling — "if you don't persist task IDs, there is no way to get it back" — but the direction is clear. If you don't save the ID, the task is effectively gone.

Second, the input-required mechanism gets inverted. Instead of the server holding a connection open to elicit client responses, the client now sends an update to the server when human input is available. Davis maps this directly to how Temporal handles it: "That's effectively what this is. It's a way of signaling into this long-running task." The lifecycle states stay the same — that design was sound — but the wire protocol for moving between them becomes dramatically cleaner.

V2 also restructures MCP itself. Tasks have become an extension rather than a core feature, part of a broader move to give MCP a stateless core with optional capabilities layered on top. Whether that modularity will make adoption easier or just make the surface area harder to reason about is a real question. Extensions are only as useful as the ecosystem that implements them.

What still doesn't scale

Davis is candid about the limits of what V2 actually solves. The task/list problem is gone, but it's replaced by a polling problem that looks manageable until it isn't. If a million agents each have a running task, you now have a million clients each periodically polling their individual task for status updates. "That does not scale," she says flatly.

The spec includes a notifications protocol that's supposed to address this — a single endpoint where clients can ask whether anything has changed, then fetch only the relevant task — but Davis describes it as still in-progress and showing promise rather than ready. The gap between a cleaner protocol and a protocol that actually works at production scale isn't closed yet.

This is worth sitting with. The agent ecosystem is being built under the assumption that MCP provides a durable foundation for long-running tool invocation. That assumption is currently only partially true. V1's durability story had structural problems. V2 fixes the worst of them but introduces a scaling challenge that needs the notifications layer to fully resolve. The notifications layer isn't done.

None of this is a reason not to build. Davis's own implementation — a task tracker workflow running on Temporal, handling multiple concurrent purchase orders, surviving server restarts — demonstrates that the pieces work. But it also demonstrates that today, making them work requires building the client infrastructure yourself, because nobody has packaged it yet. Davis says her near-term goal is to get this implemented in FastMCP so developers can use the same framework they're already using for their MCP servers.

The clearest framing she offers cuts across both the technical and the temporal: "Just because you can open a long-lived stateful connection does not mean you should." That's the lesson of V1 applied, and it's the design principle V2 is trying to encode. Whether it lands cleanly enough that the agent ecosystem finally shows up to implement it — that's the open question July's V2 release will start to answer.

Dev Kapoor covers open source software and developer communities for Buzzrag.