Hosted Agents Look Like Microsoft’s Best Attempt Yet at Enterprise-Grade Agent Runtime
Most cloud infrastructure still assumes software behaves like a polite web app. A request comes in, some stateless code runs, maybe a database gets touched, and a response goes back out. AI agents are not polite web apps. They keep context, write files, execute code, call tools, accumulate state over time, and increasingly act on behalf of real users inside real systems. That mismatch is why so much “enterprise agent infrastructure” still feels like ordinary cloud hosting with a fresh coat of model paint.
Microsoft’s new hosted agents announcement is interesting because it starts from that mismatch instead of pretending containers and serverless primitives are already good enough. Hosted agents in Foundry Agent Service, now in public preview, promise per-session VM-isolated sandboxes, persistent filesystem state, integrated identity, scale-to-zero economics, stable endpoints with versioning and weighted rollouts, and support for multiple protocols and frameworks. In plain English, Microsoft is trying to turn the runtime itself into a product category for agents.
That matters more than another model announcement because runtime assumptions are where enterprise AI systems often fall apart. Once an agent can touch a filesystem, hold secrets, write artifacts, and chain tool invocations across a session, sharing infrastructure across users starts to look less like efficiency and more like liability. Microsoft says each session gets its own dedicated sandbox rather than sharing a container with other sessions. If that claim holds up under production conditions, it is a real upgrade in the safety model.
Shared containers were never a comfortable fit for agents
The company’s blog is effectively an indictment of traditional cloud primitives for this workload. Containers, web apps, and functions were designed around multi-tenant request handling, not long-running autonomous software with local state. When Customer A and Customer B hit the same instance and the agent is writing files, invoking code, or caching context, isolation stops being an implementation detail. It becomes the product.
Microsoft’s headline claim is per-session hypervisor-style isolation with a persistent filesystem. That means the platform is not just giving developers a code-execution sandbox for one turn. It is offering an environment that can hibernate and resume with disk state intact. The companion developer-journey post adds two specific numbers that make the pitch more concrete: pricing during preview starts at $0.0994 per vCPU-hour and $0.0118 per GiB-hour, and the service is supposed to start sessions in under 100 milliseconds while charging only for active execution.
Those details matter because they expose the economic thesis behind the product. Microsoft is trying to remove the ugly tradeoff between keeping agent environments warm all the time and suffering painful cold starts every time a user comes back. If the runtime can suspend between turns and resume without losing working state, developers get something that looks more like persistent compute without paying full-time idle tax. For agent workloads, that is a much more sensible optimization target than shaving milliseconds off yet another stateless API path.
The platform play is bigger than hosting
On its own, isolated compute is useful but incomplete. Microsoft knows that, which is why the hosted-agents story is tied tightly to the rest of Foundry: Toolbox for shared tool access, memory for cross-session recall, observability through OpenTelemetry-style tracing, Entra-based identity, DLP and guardrails, VNet support, and distribution into Teams and Microsoft 365. The bet is not just “run your agent here.” It is “run your agent here, connect it to enterprise identity and data, and publish it into the places your users already work.”
That is a stronger platform argument than the industry’s usual agent-hosting pitch. A lot of vendors still talk as if deployment is the main challenge. For enterprises, deployment is merely the first hard part. The real questions arrive immediately after: how is outbound network access controlled, what identity is used for downstream actions, how are tool calls audited, how do we version releases safely, how do we see what the agent actually did, and how do we keep one customer’s session state away from another’s? Microsoft is at least aiming at the right checklist.
The framework posture is also notably pragmatic. Microsoft explicitly names LangGraph, Microsoft Agent Framework, Claude Agent SDK, OpenAI Agents SDK, and GitHub Copilot SDK as acceptable harnesses. That is a good sign. Enterprises do not want to be told they must rewrite their orchestration layer every time a cloud vendor upgrades its agent story. By keeping the runtime relatively open, Microsoft is positioning Foundry as a place to host and govern agents rather than an all-or-nothing ideology.
What engineers should test before they believe the marketing
The launch is promising, but preview infrastructure should be treated like preview infrastructure. “Under 100ms” startup sounds great. So do filesystem-preserving resume and scale-to-zero. The question is what happens when the pleasant demo meets real traffic, messy tools, and compliance requirements. Practitioners should test at least five things immediately.
First, isolation boundaries. If each session really gets a dedicated sandbox, how are artifacts cleaned up, how long does state persist, and what exactly prevents cross-session leakage in edge cases? Second, durability. If the filesystem survives scale-down events, what are the guarantees around long idle periods, failed resumes, and region-level incidents? Third, network control. BYO VNet support is a serious enterprise requirement, but teams need to validate outbound restrictions and service-to-service patterns in their own environment. Fourth, auditability. Identity and on-behalf-of claims sound good on paper; the important part is whether every consequential action remains attributable after tool chains get complicated. Fifth, cost shape. Charging only for active execution is attractive, but teams need to understand what “active” means in a long-running agent with bursts of waiting, retries, and tool latency.
There is also a subtle risk Microsoft will need to manage carefully: when a platform makes agent execution easier, teams tend to over-trust autonomy faster than their controls mature. Better runtime isolation does not magically make bad tool permissions safe. Persistent state does not make memory quality correct. Fast startup does not make governance optional. The runtime can make production possible. It cannot make sloppy agent design responsible.
Still, this is one of Microsoft’s best Azure AI infrastructure stories in months because it is aimed at a real pain point. Enterprises do not just need smarter models. They need a sane place to run agent-shaped software without rebuilding the isolation, persistence, identity, and observability stack themselves. If hosted agents deliver even most of what the preview promises, Foundry becomes a more credible default for teams that want agents in production but do not want to become a bespoke agent-platform company in the process.
The sharp takeaway is this: Microsoft is no longer just trying to sell agent features. It is trying to sell new runtime assumptions for agent systems. That is the right fight. Models will keep changing. The teams that win will be the ones that make the operational layer boring enough for security, platform, and application teams to all say yes.
Sources: Microsoft Foundry Blog, Microsoft Learn, Microsoft Foundry Blog