Microsoft Foundry Agent Service provides managed runtime for containerized AI agents

Microsoft Foundry Agent Service provides a managed runtime for containerized AI agents on its Azure-based Foundry platform. You package agent code as a container image, push it to Azure Container Registry, and the service handles deployment, compute provisioning, scaling, session persistence, identity, and observability. It addresses the gap between prompt-based agents—defined entirely through the Foundry portal—and running agent workloads yourself across heterogeneous cloud environments.

The framework itself is open-ended. You can bring any agent framework—LangGraph, Semantic Kernel, Microsoft Agent Framework, or custom code—since the protocol libraries are framework-agnostic. Python and C# are supported. At deploy time, Agent Service creates a dedicated Microsoft Entra ID identity per agent and a dedicated endpoint. Two identities are involved: the per-agent identity the container authenticates with at runtime, and a project-wide managed identity used for platform infrastructure operations. For Teams and Microsoft 365 integrations, the agent can act on a user's behalf via on-behalf-of OAuth flows when a token is present, or fall back to its own identity in autonomous scenarios.

Supported protocols include: Responses for OpenAI-compatible clients, Invocations for arbitrary JSON payloads like webhooks, and a WebSocket variant for bidirectional voice streaming. The platform can also bridge Responses to the Activity protocol for Teams delivery, and a preview A2A protocol handles agent-to-agent delegation. An agent can expose multiple protocols at once.

Each session runs in a VM-isolated sandbox with a persistent filesystem: $HOME and files uploaded via the /files endpoint survive idle periods. The idle timeout is 15 minutes, after which compute is deprovisioned but state persists; a resumed session gets fresh compute with state restored. Sessions are deleted permanently after 30 days of inactivity. Scaling is per session, not per replica—there's no replica count or warm pool—and billing is based on CPU and memory consumed across active sessions.

Versions are immutable snapshots of image, resource allocation, environment variables, and protocol configuration. An endpoint routes 100% of traffic to a single version; traffic splitting isn't supported, so updates are all-or-nothing. Environment variables are baked in per version and can't be changed. Sandbox sizes top out at 2 vCPU and 4 GiB, and each session gets up to 20 GiB of disk at 1 vCPU or higher—about 20% reserved for system use, the rest shared among the container image, $HOME, and other writable locations. Right-sizing can be guided by Application Insights data, treating roughly 70% sustained allocation as the threshold for resizing.

Third-party systems are used at your own risk, and users are responsible for responsible AI mitigations, data flowing outside compliance boundaries, and testing their applications. The platform automates infrastructure, not the judgment about what the agents are allowed to do.