Most agent demos still assume the runtime problem is solved the moment an LLM can call a tool. It is not. Once an agent starts writing files, executing code, holding state across turns, and acting with enterprise credentials, you stop needing a chatbot host and start needing something much closer to a managed application platform, which is the gap Microsoft is trying to close with hosted agents in Foundry Agent Service.
Why Generic Compute Breaks for Agents
Microsoft’s hosted-agents launch post makes the argument directly: containers, web apps, and serverless functions were designed for shared-service patterns, not for agent sessions that write arbitrary files, execute code, and hold sensitive working context on behalf of individual users. If two users land on the same runtime and the agent can manipulate disk state or credentials, isolation is no longer an optimization problem. It becomes a trust problem.
The hosted agents concept page translates that into product behavior: each session runs inside a VM-isolated sandbox with persistent filesystem state in `$HOME` and `/files`, and the platform can deprovision idle compute while restoring that state when the session resumes after inactivity. That design is unusually specific for an agent platform because it treats stateful execution as the default case rather than the edge case.
The Session Model Is the Story
Hosted agents are compelling less because they run containers and more because they expose a session abstraction that maps cleanly to agent workloads. According to the docs, sessions can persist for up to 30 days, idle compute is deprovisioned after 15 minutes, and the platform restores the session’s files and state when work resumes without requiring you to rebuild the agent’s environment by hand.
That lets an agent behave more like a long-running worker than a stateless API endpoint. A coding agent can keep artifacts on disk, a research agent can preserve intermediate files, and a human-in-the-loop workflow can pick up where it left off instead of replaying the whole interaction chain from scratch every time a user returns.
Protocols and Identity Matter More Than Framework Choice
Microsoft is also being more flexible than many managed platforms usually allow. Hosted agents can expose the Responses protocol for OpenAI-compatible conversational flows, the Invocations protocol for arbitrary JSON payloads, plus Activity and A2A support for Microsoft 365 channels and agent-to-agent delegation from the same deployed agent. That means the platform is not forcing every workload into a single chat abstraction.
Identity is handled with the same level of seriousness. Each hosted agent gets its own dedicated Microsoft Entra ID at deploy time, distinct from the project managed identity used for infrastructure operations, and can also participate in on-behalf-of flows when integrated through Microsoft 365 channels for downstream access control. That is the kind of separation enterprises usually have to design for themselves.
The Preview Limits Are Still Real
This is still a preview product, and the limits are not cosmetic. The docs currently cap active concurrent sessions at 50 per subscription per region by default, limit sandbox sizes to between 0.25 vCPU and 2 vCPU, and note that the Azure Container Registry storing your image must remain reachable over a public endpoint because private-network-secured ACR is not yet supported for hosted-agent image pulls.
The launch post adds another useful reality check: hosted agents are most valuable when agents need secure per-session isolation, persistent disk, and scale-to-zero economics, not when a simple prompt agent is already enough for the job. Teams should resist the urge to treat hosted agents as the default deployment target for every Foundry app.
Where Hosted Agents Fit
The Agent Service overview now positions prompt agents, workflow agents, and hosted agents as three distinct choices: prompt agents for rapid prototyping, workflow agents for declarative orchestration, and hosted agents when you need full code-level control over behavior and runtime instead of a configuration-only definition. That is a useful taxonomy because it tells platform teams when they are buying flexibility and when they are just buying complexity.
In practical terms, hosted agents look best suited to coding agents, ops agents, research workflows, and any scenario where filesystem state, custom protocols, or framework-specific orchestration are essential. They are less a replacement for prompt agents than a missing execution tier for serious agent applications.
Conclusion
Hosted agents are one of the more credible signs that Microsoft understands where the agent market is moving. The hard production problems are isolation, identity, state, and lifecycle management, not just prompt engineering.
If the preview matures well, hosted agents could become the part of Foundry that makes custom agent code operationally sane. That would be a much bigger deal than simply giving developers another place to run containers.
Chris Wan
Microsoft Certified Trainer (MCT)
Application Architect, SOS Group Limited
