'MCP Tasks (async): Why Aren''t Any Agents Supporting Them? - Cornelia Davis, Temporal'

MCP tasks enable long-running asynchronous tool invocations with durability guarantees, but their complexity - particularly around state management and protoco...

By Sean Weldon

MCP Tasks and the Challenge of Asynchronous Agent Orchestration: An Analysis of Protocol Evolution from V1 to V2

Abstract

The Model Context Protocol (MCP) Tasks specification enables asynchronous, long-running tool invocations with durability guarantees, yet has experienced minimal client-side adoption since its November release despite addressing critical architectural requirements for production agent deployments. This analysis examines the technical barriers preventing widespread implementation, focusing on state management complexity and protocol handling challenges inherent in the V1 specification. Through detailed examination of enterprise purchase order workflows requiring human-in-the-loop approvals and multi-step ERP integrations, this synthesis demonstrates how V1's stateful protocol design - particularly session-based task/result endpoints and unfiltered task/list operations - creates scalability limitations and implementation burdens. The July V2 specification addresses these challenges through fundamental architectural shifts toward stateless protocols and signal-based communication patterns, though substantial client-side implementation complexity remains. These findings have significant implications for agent framework developers navigating the trade-offs between durability guarantees and implementation accessibility.

1. Introduction

Modern AI agent architectures increasingly require integration with enterprise systems through workflows that extend beyond simple request-response patterns. The Model Context Protocol (MCP) Tasks specification addresses this need by enabling asynchronous tool invocations that persist across infrastructure failures, network disruptions, and human interaction delays. Released in November as an experimental feature, MCP Tasks has experienced limited client-side adoption despite solving fundamental architectural problems for production agent deployments.

The central challenge lies in reconciling the durability guarantees necessary for enterprise workflows with the complexity burden imposed on client implementations. Traditional MCP tools operate synchronously through tools/call endpoints, returning immediate responses suitable for stateless operations. However, workflows involving human approvals, multi-system orchestration, and extended processing times require fundamentally different architectural patterns that maintain task state across temporal and infrastructure boundaries.

This analysis examines the technical evolution of MCP Tasks from V1 to V2 specifications, focusing on protocol semantics, state management challenges, and scalability considerations. The synthesis establishes requirements for long-running task infrastructure through enterprise use cases and evaluates how architectural decisions impact client-side implementation feasibility. The core thesis posits that while V2's transition to stateless protocols represents a significant improvement over V1's session-based design, the inherent complexity of durable task management continues to present substantial barriers to widespread adoption.

2. Background and Related Work

2.1 MCP Protocol Foundation and Synchronous Limitations

The Model Context Protocol provides a standardized interface for AI agents to interact with external tools and data sources. Traditional MCP tools follow synchronous request-response semantics through the tools/call endpoint, suitable for operations with immediate results. This pattern proves fundamentally insufficient for workflows requiring persistence across temporal boundaries and infrastructure failures, particularly in enterprise contexts where processes may span hours or days and involve multiple external dependencies.

2.2 Task Lifecycle and Workflow Orchestration Patterns

MCP Tasks introduces a formal state machine governing task progression: working → input_required → working → terminal states (complete, cancel, or fail). This lifecycle model maps domain-specific state machines to protocol-level states, enabling standardized handling of complex workflows while preserving domain semantics. The specification draws conceptual parallels to workflow orchestration systems, particularly signal-based communication patterns for injecting data into long-running processes - a pattern exemplified by systems like Temporal that enable external events to modify workflow state without maintaining continuous connections.

3. Core Analysis

3.1 Enterprise Requirements and Durability Challenges

The necessity for asynchronous task handling emerges clearly from enterprise workflow analysis. Consider a purchase order processing scenario: upon goods receipt, the system must execute parallel back-office updates while simultaneously processing invoices. The invoice processing workflow itself comprises multiple sequential steps: ERP validation, human approval requests, ERP reconciliation, and payment execution. Each step introduces potential delays - human approvals may require hours or days, while ERP systems may experience temporary unavailability.

The specification mandates that tasks cannot disappear once launched. Tasks must survive client disconnection, server crashes, network failures, and extended human delays. This durability requirement necessitates infrastructure capable of persisting and recovering task state across all failure modes. As the analysis notes, "once you've launched a task it has to be durable...the task needs to survive that and you need to be able to interact with that task when the infrastructure comes back." This represents a fundamental shift from stateless tool invocations to stateful, persistent orchestration.

3.2 V1 Protocol Architecture and Scalability Limitations

The V1 specification defines five core endpoints: tools/call (request-response), task/get, task/cancel, task/list, and task/result. Two architectural decisions in V1 create significant implementation challenges. First, the task/list endpoint operates as a stateful, unfiltered query mechanism. In scenarios with numerous concurrent tasks, clients must query potentially millions of tasks to locate specific instances - an approach that scales poorly in distributed systems.

Second, and more critically, the task/result endpoint employs a long-running connection to tunnel input_required states back to clients. When a task reaches the input_required state, the server maintains an open connection to communicate this requirement. This session-based protocol introduces substantial complexity: clients must manage connection lifecycles, implement reconnection logic, and synchronize state across connection failures. Furthermore, the reference implementation enforces FIFO processing of input_required states on the client side, preventing concurrent handling of multiple tasks awaiting input.

The stateful nature of these endpoints violates fundamental distributed systems principles. As emphasized in the analysis, "stateful protocols are the absolute worst thing in large-scale distributed systems," creating bottlenecks and complicating horizontal scaling.

3.3 V2 Architectural Improvements and Protocol Simplification

The July V2 specification addresses these limitations through fundamental architectural revisions. The protocol transitions to a stateless design, representing what the analysis characterizes as a "major improvement for distributed systems scalability." Tasks become an extension within a structured MCP core, enabling modular protocol evolution rather than monolithic specification updates.

V2 eliminates the task/list endpoint entirely, removing the scalability bottleneck of unfiltered queries. More significantly, input_required handling shifts from the session-based task/result connection to a client-side update endpoint following signal-based patterns. Instead of maintaining long-running connections to tunnel state changes, servers push updates to client-provided endpoints, decoupling task state progression from connection lifecycle management.

The task/result endpoint simplifies considerably by removing session-based protocol complexity. While task lifecycle management remains unchanged - still mapping domain state machines to protocol states - the mechanism for communicating state transitions fundamentally shifts from connection-based to message-based patterns.

3.4 Persistent Client-Side Implementation Requirements

Despite V2's improvements, substantial client-side complexity remains. Clients must implement local persistence for task identifiers, as the specification provides no mechanism for task recovery without prior knowledge of task IDs. As the analysis emphasizes, "if you don't persist task IDs, there is no way to get it back." This requirement should arguably be mandated explicitly in the specification rather than left as an implicit implementation detail.

Clients must also handle multiple concurrent tasks rather than relying on FIFO processing constraints. The protocol handler must manage state synchronization, particularly for the signal-based input_required pattern where servers push updates asynchronously. While V2 significantly reduces complexity compared to V1's session management requirements, implementing robust task tracking still demands substantial engineering effort.

4. Technical Insights

4.1 Implementation Patterns and Framework Support

The Fast MCP framework provides server-side support for task implementation, demonstrating practical patterns for task lifecycle management. Server implementations must persist task state, handle state transitions according to the lifecycle state machine, and manage the update endpoint protocol for client communication. The invoice processing workflow exemplifies this pattern: validate ERP → request approval → reconcile ERP → await human approval → execute payment, with retry logic at each step.

Client-side implementation requires a task tracker component, conceptually implemented as a workflow with elicitation handling for server-to-client communication. This tracker must maintain mappings between task IDs and domain contexts, persist this state across process restarts, and handle asynchronous updates from multiple concurrent tasks.

4.2 Scaling Considerations and Future Directions

Current polling-based approaches face inherent scaling limitations. A scenario with millions of clients each managing numerous tasks creates unsustainable query loads. The MCP specification includes a notifications protocol designed to enable server-push models instead of client-pull patterns, addressing this scalability concern. However, this protocol requires additional implementation complexity on both client and server sides.

Planned implementations in the Fast MCP framework aim to simplify client-side task support, with the stated goal of making "task implementation as accessible as current MCP server development." This suggests recognition that current complexity levels present adoption barriers requiring framework-level abstraction.

4.3 Trade-offs and Limitations

The V2 specification's stateless design improves scalability but shifts complexity to client implementations. Clients now bear responsibility for endpoint provisioning, state persistence, and concurrent task management - responsibilities that V1's session-based approach partially centralized on servers. This trade-off favors distributed systems scalability at the cost of increased client implementation burden.

The experimental status of the specification, while encouraging cautious adoption, also reflects genuine architectural challenges. The evolution from V1 to V2 demonstrates that the protocol design space involves non-trivial trade-offs between implementation complexity, scalability, and durability guarantees.

5. Discussion

The limited adoption of MCP Tasks despite its experimental status reflects a fundamental tension between architectural necessity and implementation accessibility. Enterprise workflows demonstrably require asynchronous, durable task handling - the purchase order use case illustrates requirements that simple request-response patterns cannot satisfy. However, the complexity of implementing these guarantees, even with V2's improvements, creates barriers for client framework developers.

The transition from stateful to stateless protocols in V2 represents sound distributed systems engineering. Session-based protocols create coupling between connection lifecycle and application state, complicating failure recovery and horizontal scaling. V2's signal-based pattern aligns with established workflow orchestration practices, enabling independent scaling of task execution and client communication.

Nevertheless, significant implementation challenges remain unresolved. The requirement for client-side task ID persistence, while architecturally necessary, should be explicitly mandated and potentially standardized through reference implementations. The absence of such guidance increases the likelihood of fragmented, incompatible client implementations. Furthermore, the notifications protocol intended to address polling scalability adds another layer of complexity that clients must implement for production deployments.

Future work should focus on framework-level abstractions that encapsulate task management complexity. The Fast MCP initiative represents one approach, but broader ecosystem support will be necessary for widespread adoption. Additionally, the specification would benefit from explicit guidance on client-side persistence requirements and reference architectures for common deployment patterns.

6. Conclusion

This analysis demonstrates that MCP Tasks addresses genuine architectural requirements for production agent deployments, particularly in enterprise contexts requiring human-in-the-loop workflows and multi-system orchestration. The V2 specification's transition to stateless protocols and signal-based communication represents significant improvement over V1's session-based design, addressing fundamental scalability limitations inherent in stateful distributed protocols.

However, the persistent complexity of client-side implementation - including task ID persistence, concurrent task management, and protocol handler development - continues to present substantial adoption barriers. The experimental status of the specification reflects both architectural evolution and genuine technical challenges in balancing durability guarantees with implementation accessibility.

Practical takeaways for framework developers include the necessity of client-side state persistence infrastructure, the value of signal-based patterns over session-based protocols for long-running operations, and the importance of framework-level abstractions to reduce implementation burden. As the ecosystem matures and frameworks like Fast MCP provide higher-level abstractions, adoption barriers should diminish, enabling broader deployment of asynchronous agent workflows in production environments.

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub