- Long-running agents fail in production not because of model choice, but because typical request/response infrastructure kills processes that wait for hours or days.
- Agents don’t behave like web requests: they pause for tool calls, human approvals, and delayed webhooks while needing to preserve state across those gaps.
- Teams often patch around this with queues, state stores, cron wake-ups, retries, and checkpointing, effectively building a brittle distributed system themselves.
- Microsoft Foundry’s durable runtime suspends and resumes agents automatically, carrying state with them and handling routing, checkpointing, and scaling at the platform layer.
- A practical durable runtime also needs persistent per-session storage, an auditable machine identity, and end-to-end tracing to govern and debug multi-day runs.
Microsoft moved Foundry hosted agents to general availability on July 11, and the headline feature is not a model. It is a durable runtime that keeps an agent alive across hours, days, or weeks of waiting.
The reason your long-running agents keep dying is that you deployed them on infrastructure built for request-and-response, where anything that waits gets killed.
Before you argue about which model to use, decide where the agent lives while it waits for a six-hour API call or a human to click approve.
Agents are not web requests
For two years the conversation about agents has been about the model. Which one reasons better, which one calls tools cleaner, which one costs less per million tokens. Meanwhile the thing that actually stopped teams from putting autonomous agents into production was rarely the model. It was the plumbing underneath.
Think about the shape of a web request. It comes in, does its work in a few hundred milliseconds, and returns. The whole stack most of us deploy on, serverless functions, containers behind a load balancer, request timeouts, is tuned for exactly that shape. It assumes the work is short and the process is disposable.
An agent breaks every one of those assumptions. It calls a tool and waits. It hands off to a human and waits longer. It kicks off a batch job in some other system and waits for a webhook that might come back in six hours. During all that waiting it is holding state: what it has done, what it learned, what it still needs to do. Put that on a serverless function with a fifteen-minute ceiling and the process gets reaped long before the work is finished.
So teams built scaffolding. A state store here, a queue there, a cron job to wake things back up, some retry logic, a homemade checkpoint format so a crashed run could resume. It works, sort of, until it does not, and then you are debugging your own distributed system instead of the agent.
What a durable runtime actually does
The Foundry GA is Microsoft's answer to that scaffolding, and it is worth understanding the shape of the answer regardless of whether you ever touch Azure.
The core idea is a durable execution layer. Microsoft's example is an agent that calls an external API which takes six hours to respond. Instead of holding a process open and paying for idle compute, the runtime suspends the agent and resumes it when the response arrives, with no code from you to manage the pause. The state travels with the agent. Message routing, checkpointing, and scaling based on how much work is queued are handled by the platform rather than by glue you wrote at 2am.
Each session runs in its own isolated sandbox with a dedicated file system that persists, its own machine identity provisioned automatically, and tracing built in. That combination matters more than it sounds. A long-running agent needs a place to keep files between steps, an identity so you can see and govern what it accessed, and traces so you can reconstruct what it did across a run that spanned three days.
Microsoft's showcase is a procurement agent that ran for three days, moving between email, an ERP system, and a human approval loop. Take the vendor framing with the usual pinch of salt, but the example names the real problem. A three-day agent is not one long computation. It is a process that mostly sits idle, waking up when something it was waiting for finally happens. That is a fundamentally different thing to host than a chatbot that answers in two seconds.
The service is framework and model agnostic. It runs orchestrators built with LangChain, CrewAI, or plain Python, against models from OpenAI, Mistral, Meta, and others. You deploy source directly, Python 3.13 or 3.14 and .NET 10, without building a container, or bring your own image if you prefer. A basic Linux agent with a single NVIDIA T4 runs around 75 cents an hour. Microsoft attaches a 99.9 percent uptime commitment and routes every prompt and response through content-safety checks before and after your code sees them.
This is a category now, not a feature
The specific news is Microsoft, but the pattern is bigger than one vendor. AWS has been building the same layer under Bedrock. Startups are selling durable agent execution as their whole product. The managed agent runtime is becoming its own tier of infrastructure, sitting between the model API and your application, the way managed databases and managed queues became their own tiers before it.
That is the real signal in this release. When a category graduates from "write it yourself" to "buy it with an SLA," it means enough people hit the same wall that a market formed around the wall. The wall here is durability. Everyone who tried to run an agent longer than a single request eventually discovered that keeping the process alive and stateful was the hard engineering, not the prompting.
What to check before you pick one
Whether you adopt Foundry, a competitor, or decide to keep running your own, the useful thing this release gives you is a checklist for what a serious agent runtime has to answer.
Where does state live when the agent is idle, and who pays for that idle time. If the answer is a process held open, your bill scales with waiting, not with work.
What happens when the host crashes mid-run. A real durable runtime resumes from the last checkpoint. Homemade scaffolding usually starts over, or worse, resumes into a corrupt state.
What identity does the agent carry, and can you audit what it touched three days later. An autonomous process that acts on email and an ERP for three days is exactly the thing your security team will ask about, and "it ran under the app's service account" is not an answer they will like.
How do you observe a run that spans days. If your tracing assumes a request that starts and ends in one span, you cannot debug an agent that lives across dozens of suspensions.
None of these are model questions. You can have the best model on the market and still have an agent that dies every time it waits, because the model was never the part that had to stay alive. The quiet lesson of this launch is that the interesting frontier moved down the stack, from the thing that decides what to do to the thing that keeps the decider running long enough to finish.
Pick your model second. Decide where the agent lives first.
If you’re trying to ship agents that span hours or days, evaluate your hosting first: can it suspend work, persist state and files, and resume on events without you writing a pile of glue code? Treat “where the agent lives while it waits” as a first-class architecture decision alongside model selection, and look for runtimes that provide isolation, identity, and tracing so you can govern access and debug multi-step runs. Even if you don’t use Azure, use Foundry’s approach as a checklist for what your platform must handle before you attempt multi-day workflows in production.