Foundry Hosted Agents Are the Production Runtime Microsoft Agents Needed

The past few months have made one thing obvious: agentic AI is leaving the demo stage. Agents are writing code, filing pull requests, triaging tickets, and running overnight reports. The question is no longer whether an agent can do the work. It is whether you can let it do the work in production without creating a new category of operational risk.

Microsoft Foundry has been building the answer piece by piece. At Build 2026 the pieces came together into a coherent path from prototype to production. The public preview refresh of hosted agents in Foundry Agent Service is the runtime at the center of that path. It is a managed environment designed specifically for agents that execute code, hold state, touch enterprise data, and need to be governed like any other production service.

Here is what hosted agents actually do, how they connect to the broader Foundry and Microsoft 365 ecosystem, and a practical way to start exploring them this week.

Why Agents Need a Different Kind of Runtime

Traditional application hosting assumes a shared process serving many users. A web API or containerized service keeps one runtime warm and routes requests to it. That is a good model for stateless requests, but it is a poor model for agents.

A useful agent session writes files, executes code, remembers context, and may hold credentials or sensitive customer data. When Customer A and Customer B share the same container, their working directories, their tool outputs, and their secrets can leak across each other. Even when nothing goes wrong, the operational work required to keep that separation safe — per-tenant isolation, state persistence, identity, scaling, and observability — is substantial.

Foundry hosted agents change the default. Every session gets its own hypervisor-isolated sandbox with a persistent filesystem. Not process isolation. Not a code-only sandbox. A dedicated VM-grade sandbox that resumes with its files and state intact after scale-to-zero events. Cold starts are predictable, idle compute costs drop to zero, and the platform provisions a dedicated Microsoft Entra agent identity for each agent so it can authenticate to downstream services without embedding secrets in the image.

The comparison with traditional compute is the clearest summary. Shared containers bundle sessions together, require external storage for state, share service accounts, and leave observability as an exercise for the developer. Hosted agents separate sessions automatically, persist filesystem state, assign per-agent identities, and emit built-in OpenTelemetry traces across agent, session, and fleet levels.

What You Actually Get

The Foundry hosted agents announcement lists seven capabilities that together make the runtime credible for production:

• Predictable cold starts so agents spin up in a custom environment quickly enough for interactive use.
• Scale to zero so you are not paying for idle agents.
• Resume with filesystem intact so files, disk state, and session identity survive after the agent suspends.
• Per-session isolation so every end-user or task runs in its own VM-isolated sandbox, namespace-able through isolation keys.
• Bring-your-own VNet support so outbound traffic can stay on your own network.
• Production-ready endpoints with built-in versioning and weighted rollouts across versions.
• Multiple protocols out of the box, including OpenResponses, Invocations, and automatic mapping to the Activity Protocol for Teams and Microsoft 365.

These are not marginal improvements. They are the table stakes that turn a promising agent prototype into something a platform team is willing to run.

It Is Not Just Compute — It Is the Full Platform

Hosted agents are one layer of a larger Foundry stack that now covers most of the agent lifecycle. That stack makes more sense when you look at it as a whole rather than as isolated feature announcements.

Microsoft Agent Framework v1.0 provides the open-source SDK and runtime for building agents in Python or .NET, with multi-model support, MCP and A2A protocol support, workflows, and middleware hooks for approvals and observability. It is the local development experience.

Foundry Toolkit for Visual Studio Code, now generally available, extends that into the IDE: create agents from templates, test and debug with traces, connect to toolboxes, and deploy directly to hosted agents.

Toolbox in Foundry, in public preview, is a unified way to configure and manage tools. Build a toolbox once, then point any MCP client at a single endpoint. Auth handling, OAuth identity passthrough, and observability for every tool call are handled by the platform.

Memory in Foundry Agent Service, also in public preview, gives agents managed long-term memory across sessions without provisioning external databases. It now integrates natively with Microsoft Agent Framework and LangGraph.

Foundry IQ provides an SLA-backed knowledge plane for grounding agents in enterprise data, unifying Work IQ, Fabric IQ, Azure SQL, file search, and MCP sources behind a single retrieval endpoint.

Observability in the Foundry Control Plane reaches general availability on core capabilities, including OpenTelemetry-based tracing, built-in evaluators for coherence and safety, continuous production monitoring through Azure Monitor, and the AI Red Teaming Agent for adversarial testing.

Putting these together means you can build an agent locally in VS Code, connect it to governed tools and enterprise knowledge, deploy it to a sandboxed hosted runtime, and observe and evaluate it in production without stitching together a separate infrastructure stack.

From Local Code to Hosted Agent

The deployment path is intentionally short. The Azure Developer CLI, azd, can take a Microsoft Agent Framework project from local code to a hosted agent with a small number of commands. The preview supports direct code deployment as well as container deployment, so teams that do not want to manage Docker images can upload source and let the platform build and run it.

A typical azd ai agent init command specifies the source directory, agent name, deployment mode, runtime, entry point, and dependency resolution strategy. azd deploy then packages or builds the image, uploads it, polls until the agent is active, and exposes a stable endpoint. Reusing an agent name creates a new version, which enables canary or rollback workflows through weighted traffic splits.

For .NET developers using Microsoft Agent Framework, the hosting adapter is a few lines of code. A ResponsesHostServer or MapFoundryResponses call exposes the agent through the Responses protocol. The same agent code runs locally and in the cloud, which reduces the distance between development and production.

Governance and Distribution

Production agents do not exist in a vacuum. They need identity, access controls, and a way to reach users.

Every hosted agent receives its own Entra Agent ID. For interactive scenarios that start from Teams or Microsoft 365, Toolbox supports OAuth On-Behalf-Of flows to propagate user context. For autonomous or background workloads, agents authenticate with their own managed identity. In either case, secrets do not need to live in the container image.

Once deployed, agents can be published directly to Teams and Microsoft 365 Copilot from the Foundry portal. Shared scope makes the agent available to individual users under "Your agents" in the Agent Store. Organization scope submits the agent for admin review, after which it appears under "Built by your org" for the whole tenant. Identity, permissions, and policy flow through automatically.

For IT and security teams, every Foundry agent is visible in Microsoft Agent 365, a unified control plane for observing, securing, and governing agents across the organization. It extends the same Microsoft security posture — Entra, Defender, Purview — to agents as first-class assets.

Where to Start This Week

If you want to move from reading to doing, here is a low-risk path:

1. Install Foundry Toolkit for VS Code and create an agent from one of the Microsoft Agent Framework templates. Run it locally first.
2. Add one managed tool through Toolbox, such as file search or web search, and verify the call shows up in traces.
3. Deploy to hosted agents with azd deploy, starting with a read-only or low-permission agent so you can observe behavior before granting broader access.
4. Turn on memory for a test agent and compare task success across repeated sessions.
5. Publish a low-risk agent to Teams under shared scope, validate permissions with a small group, then consider organization-wide distribution.

The key is to start with a narrow, safe task and expand scope as the agent proves itself. Hosted agents give you the isolation and governance to make that expansion responsible.

Why This Matters for the Microsoft Ecosystem

Microsoft's bet is that the future of software is not writing more code by hand; it is defining intent, providing guardrails, and verifying outcomes. That future only works if agents can be deployed with the same rigor as the rest of the production stack.

Foundry hosted agents are the missing runtime layer. They combine the agent-optimized compute, identity, memory, tools, observability, and distribution channels that enterprise agents need, all within the Microsoft ecosystem developers already use. For teams that have been waiting for agentic coding and operations to stop being a party trick, this is the infrastructure that makes the transition credible.

Start small, set your guardrails, and let the runtime prove it can carry the load.