MCP Went Stateless. Your AI Agent Still Needs State.

The latest Model Context Protocol specification shifted the MCP protocol toward a stateless core. While this sounds like AI agents should become stateless too, that is not the case. In fact, as AI agents grow longer-running, more autonomous, and capable of executing real actions, application-level state becomes even more crucial.

The key difference is that MCP should not need to remember the connection, while your agent absolutely needs to retain its work. This distinction becomes critical when moving from demos to production environments. The 2026-07-28 MCP specification introduced a stateless protocol core by eliminating the need for persistent sessions between MCP clients and servers.

Requests can carry enough information to be handled independently, allowing them to potentially reach different server instances without requiring the load balancer to maintain routing. While this architectural change is beneficial for scalability, it can create a trap if not properly addressed. Stateless transport does not equate to stateless workflow.

An AI agent is typically a state machine, handling various steps like investigating an order, checking refund policies, calculating refund amounts, seeking human approval, and executing the refund. If an agent's state only exists within the agent instance, it can lead to problems if the process restarts, a deployment occurs, or the request is routed to a different server.

To handle this, the state needs to be persisted. The wrong approach might involve using a simple dictionary to store pending runs, but this fails when the request is routed to a different server instance, causing a KeyError. The better approach is to persist the workflow state, typically in a database or a distributed task queue like Temporal.

This allows any server to reconstruct the current workflow state, ensuring the agent runtime can be replaced without losing progress. Separating agent state into three distinct layers is essential. The first layer is conversation state, which contains information the model needs to understand the interaction, such as user messages, preferences, and retrieved context.

The second layer is workflow state, which represents the application's understanding of the current execution state, including the workflow ID, status, current step, order ID, and refund amount. This state is distinct from the conversation state and should be stored separately in a database or a distributed task queue. The third layer is side-effect state, which tracks what the agent has already done, such as whether an email has been sent, a refund has been created, or a CRM has been updated.

This state is crucial for ensuring idempotency, preventing duplicate actions when retries occur. Implementing idempotency is vital when an agent performs side-effecting actions like making payments, sending emails, creating tickets, or deploying services. By using an idempotency key, the agent can safely retry actions without causing unintended side effects.

For instance, when refunding a customer, an idempotency key ensures that if the refund request is retried due to a network timeout or other issues, the refund is only applied once. Human approval workflows also fall under the category of distributed systems problems. When an agent requires human intervention, it should resume from a durable checkpoint rather than restarting the entire process.

Modern agent frameworks often support a pause/resume model, allowing the agent to continue from where it left off after human approval. This approach changes how we should think about agent execution, treating it more like a distributed system where state is persisted and workflows can be resumed seamlessly. In summary, while the MCP specification's shift toward statelessness is a step in the right direction for scalability, AI agents still require application-level state to function effectively in production environments.

By understanding and properly managing the three layers of agent state—conversation, workflow, and side-effect—developers can build robust, resilient, and reliable AI agents capable of handling complex, real-world tasks.