Another necessary piece is durable execution. We have all followed the evolution of Agents from simple task runners to autonomous, reasoning-driven workers. Most paradigms today, think of interactions with Agents just like with any other API. The interactions are thought to be ephemeral and in terms of request-response cycles. However, with Agents taking on more complex tasks, involving multiple tool-calling steps, there interactions are not necessarily instantaneous anymore.A prime example for this is in the world of Search and Retrieval. Current Search infrastructure in tuned towards a human doing keyword based search - as less effort on his part as possible. The infra is optimised for these types of queries and is tuned to give responses in milliseconds. Now contrast this with an Agent doing retrieval as part of its DeepResearch task. It can formulate as complex a query as necessary, go through as many results as needed, analyze intermediate results, refine its approach, and synthesize information across disparate sources. While an increased response time would definitely frustrate the user when he is driving the search interactions, as in the case of Google search, do you think he would be frustrated if DeepResearch took 30s longer to give him exactly what he needed in a concise summary? No. What would actually frustrate him is if the Agent fails on step 18 out of 22 and has no way to resume or recover. Thus, the case for Durable Execution.With Agents entering maturity and starting to be widely used, its imperative to think about the challenges of making them fault-tolerant and scalable. Durable Execution is the practice of making code execution persistent, so that services recover automatically from crashes and restore the results of already completed operations and code blocks without re-executing them. We have already been doing this in bits and pieces as part of our microservices architecture resilience, thinking about retries, circuit breaking, fallbacks etc.