Microsoft Foundry Agent Service

Microsoft

★★★★★

Microsoft's enterprise agent runtime with hosted sandboxes, identity, and governed deployment.

Category deployment
Pricing Usage-based Azure pricing; model and tool charges apply, and hosted-agent costs depend on runtime and service usage rather than flat user seats
Status beta
Platforms cloud, api, enterprise
microsoft foundry agent-service hosted-agents runtime sandboxes enterprise
Updated April 23, 2026 Official site →

Overview

Freshness note: AI products change rapidly. This profile is a point-in-time snapshot last verified on April 23, 2026.

Microsoft Foundry Agent Service is Microsoft’s runtime and hosting layer for enterprise agents. It is not a chatbot, not a low-code agent builder, and not just another branding pass on Microsoft 365 Copilot. The current positioning is much closer to “production infrastructure for agents” than “assistant in a work app.”

That matters because Microsoft’s April 22 announcement focuses on hosted agents as secure, scalable compute built specifically for agent workloads. The pitch is not that agents can call tools. It is that they need dedicated sandboxes, persistent filesystems, identity, observability, and policy control if they are going to run serious long-horizon work across an enterprise.

Key Features

The headline capability is hosted agents in public preview. Microsoft says each session gets its own isolated sandbox with persistent filesystem state, scale-to-zero behavior, versioned endpoints, and enterprise identity through Entra. The platform also supports bring-your-own VNet routing, observability, and deployment with different agent frameworks and model providers.

The broader Agent Service docs reinforce the same posture. Foundry Agent Service is the runtime “glue” that orchestrates models, tools, safety, identity, networking, and telemetry. That makes it a better fit for production deployment than trying to bolt those layers on manually after an agent prototype already exists.

Strengths

The strongest advantage is enterprise runtime seriousness. Microsoft is explicitly solving for hosted sandboxes, per-session isolation, persistence, auditability, and integration with existing enterprise controls. That is the right shape for teams that already know they need agent infrastructure rather than another chat surface.

It is also notably multi-model and multi-harness in Microsoft’s own launch framing, which reduces lock-in risk compared with narrower hosted platforms.

Limitations

This surface is still in preview and it is not a lightweight product. Teams need Azure footing, runtime ownership, and clear architectural intent. If the problem is only “we want an assistant inside Teams or Word,” this is too much platform.

The other limitation is complexity. Foundry Agent Service is valuable when infrastructure is the bottleneck. If it is not, a builder layer like Copilot Studio or a workspace-native agent may be easier to operationalize.

Practical Tips

Reach for Foundry Agent Service when your team needs long-running agent compute, custom environments, isolation, and enterprise identity, especially if you already have your own framework or want to bring one. Good fits include coding agents, research agents, remediation agents, and internal platform automation that must be observable and governed.

Do not route simple recurring knowledge-work flows here by default. Use it when runtime requirements are the hard part, not when the main need is just a shared agent UI.

Verdict

Microsoft Foundry Agent Service is one of the more serious enterprise runtime offerings in the current agent market. It is best for organizations that need to host and govern agents as real production systems, not just experiment with agent-like features inside a suite product.