# Stateless, Yet Durable: MCP Tasks v2

## Executive summary

The session details MCP Tasks v2, an architectural evolution designed to enable durable, long-running workflows while maintaining a fundamentally stateless protocol design. Using Purchase Order processing as a concrete example, the talk contrasts the complexity and scalability issues of V1 (which relied on stateful server tracking and polling) with the simplified V2 approach. The key shift involves moving client responsibility for task ID persistence to durable storage and introducing a future notification mechanism to replace inefficient constant polling.

## Key takeaways

- MCP Tasks v2 Simplification: V2 eliminated the complex `task list` functionality (due to scalability concerns) and significantly changed how elicitation flows, simplifying the client-server protocol into basic polling and an explicit `update` API.
- Durability vs. Statelessness: While the MCP protocol is stateless, the tasks themselves are designed as durable state machines (e.g., invoice processing), requiring robust mechanisms to track their lifecycle states (Working, Input Required, Terminal).
- Scaling Beyond Polling: For massive scale (millions of tasks), constant polling is inefficient. The future direction involves implementing a notifications mechanism within the MCP Tasks protocol to allow idle tasks to consume zero resources until an event occurs.

## Technical details

- MCP Protocol Evolution: V2 eliminated `task list` and changed `task result`, simplifying the client-server communication for long-running processes. The server is no longer responsible for holding all in-flight tasks; clients must persist task IDs to durable storage.
- Workflow Implementation: The speaker demonstrated using Temporal (an open-source distributed system platform) to implement both the client and server sides of a Purchase Order processor, showcasing how state transitions (e.g., from 'Working' to 'Input Required') are managed via polling and task updates.
- Task Lifecycle States: A task progresses through defined states: Working (in process), Input Required (waiting for external input/approval), or Terminal (Completed, Failed, Canceled). The protocol must manage these transitions reliably.

## Practical implications

- Build engineers designing complex workflows should prioritize protocols that decouple state management from the core communication layer to ensure scalability.
- When building long-running agentic processes, anticipate the need for a notification/event-driven model rather than relying on continuous polling to manage resources efficiently.
- The architecture requires both server-side durability (e.g., using Temporal) and client-side persistence of task handles to prevent 'orphan tasks.'

## Topics

Distributed Systems, Workflow Orchestration, Stateless Architecture, Agentic AI, Protocol Design, Temporal Computing, Agentic AI Foundation (AAIF), Temporal Open Source Project

Source: https://www.youtube.com/watch?v=dGU0ibFPo9M