Most software requests have the decency to finish. An agent may call three tools, wait for a person, lose a connection, sleep overnight and wake up to discover that the world moved on without it. The industry keeps describing these as long-running tasks, which is accurate in the same way that describing a toddler as a short adult is accurate. Duration changes the engineering problem.
The first surprise is that keeping an agent alive is not the same as keeping its work alive. Alibaba Cloud’s sandbox talk starts with the cost and security problem of leaving execution environments running while agents do nothing. Hibernation helps, but only if the system can restore the right state, survive a failed wake-up and resume quickly enough that the user does not assume the agent has joined a monastery.
The MCP Tasks extension exposes the protocol version of the same issue. Async tool calls sound simple until a client has thousands of background tasks completing on their own schedules and asking for human attention at unpredictable moments. Cornelia Davis argues that the new MCP design puts a real durability requirement on the client as well as the server. The client is no longer merely displaying a tool result. It is operating a small distributed system.
Failures make the distinction unavoidable. Temporal’s chaos-engineered demo breaks agents, MCP servers, APIs and storage while durable execution resumes from the last completed work instead of replaying every tool call and spending the tokens again. PayPal’s experience building agentu arrives at similar patterns from the harness side: keep large tool catalogs from consuming the context window, isolate state between sessions and make recovery part of the workflow rather than an exception added later.
Once agents cross clouds, the old distributed-systems vocabulary returns in force. Equinix focuses on idempotency, compensating transactions, cold starts and partial failure. A browser agent needs the same discipline. If it has filled most of a form when the page changes, starting over may submit something twice; guessing where to resume may skip a required step. Durable work needs checkpoints tied to confirmed outcomes, not a transcript and optimism.
An agent that runs for hours is not one large model call. It is a stateful process moving through systems that fail independently. The model may decide what to try next. The runtime must remember what already happened and prevent “try again” from becoming “do it twice.”
Continue the conversation at AGNTCon + MCPCon North America
- The Sleeper Awakes: Hibernation and Wake-Up Strategies for Agent Sandboxes with Zhang Zhen, Alibaba Cloud
- Why the Heck Aren’t Any Agents Supporting MCP Tasks? with Cornelia Davis, Temporal
- Chaos Engineered: How to Build Invincible Agents and MCP Systems with W. Ian Douglas and Melissa Herrera, Temporal
- Between Intent and Execution with Hemanth HM, PayPal
- Agentic Workflows Are Distributed Systems with Praneeth Kamalaksha Patil, Equinix
- 5 Ways to Build a Durable Browser Agent with Andrew Baker, Temporal
AGNTCon + MCPCon North America takes place Oct. 22–23 in San Jose. Register and use OUTREACH25 to save 25%.
Share
Author

Alex Salkever
View All PostsAlex Salkever is the Editor-in-Chief of the AAIF and the Linux Foundation. He has been working in open source storytelling for over a decade and formerly served as a CMO and VP at a number of technology companies. He started his career in journalism, ultimately working as the technology editor for Bloomberg BusinessWeek. He leads efforts to build the AAIF media engine to drive awareness and education.



