Andrzej Kaczmarek Infrastructure & Cloud Architect
← All posts
azureaiai-foundryagents

Hosted agents in Foundry Agent Service: bring your own container, let Azure run it

Foundry Agent Service now lets you deploy your own containerized agent code — any framework, any protocol — onto managed, per-session isolated compute. Here is the architecture, the identity model, and the sizing decisions that actually drive your bill.

· 5 min read

Prompt-based agents in Microsoft Foundry cover a lot of ground: instructions, a tool list, a model, done. They fall apart the moment you need something a prompt can’t express — your own LangGraph graph, a Semantic Kernel process, a webhook receiver for Stripe or GitHub, a voice pipeline, or just code you already wrote and don’t want to rewrite as a prompt. Until recently, that meant standing up your own containerization, scaling, identity and observability stack next to Foundry, not inside it.

Hosted agents in Foundry Agent Service close that gap: you package your agent as a container image (or push source code directly for Python/.NET), Microsoft runs it on managed, isolated compute, and you keep the framework and code you already have.

How it works

You push a container image to Azure Container Registry (or, more recently, deploy Python/.NET source directly without building an image yourself). When you deploy a version, Agent Service pulls the image, provisions compute, provisions a dedicated Microsoft Entra ID for the agent, and exposes a dedicated endpoint — no manual managed-identity or routing setup. Your code then calls Foundry models, Toolbox tools, and downstream Azure services using that identity at runtime.

Two identities matter here, and they’re easy to conflate: the agent identity (per-agent, used at runtime for model calls and downstream access) and the project managed identity (project-wide, used by the platform itself for things like pulling from your container registry). If your agent needs to reach a resource outside the defaults — your own Storage account, say — you assign RBAC to the agent’s identity, not the project’s.

The isolation model is per session, not per replica

This is the detail that changes how you think about capacity planning. Hosted agents don’t run as a pool of replicas behind a load balancer — each session gets its own VM-isolated sandbox, provisioned on first use and torn down after 15 minutes of inactivity. State under $HOME and anything uploaded via the /files endpoint persists through that teardown and is restored automatically when the session resumes; a session is only permanently deleted after 30 days of inactivity.

That gives you scale-to-zero with stateful resume for free, but it also means the CPU and memory you configure on an agent version describe one session, not the agent’s aggregate footprint. Billing is based on CPU and memory consumed across every active session — oversize a sandbox and you multiply that cost by however many sessions run concurrently. Sandbox tiers today are 0.5 vCPU/1 GiB, 1 vCPU/2 GiB, and 2 vCPU/4 GiB, and each session’s disk budget tops out around 20 GiB at 1 vCPU or larger (roughly 20% of that is reserved for the system and isn’t yours to use). Right-sizing means running a representative load, checking CPU/memory/duration in the linked Application Insights resource, and adjusting the next version — versions are immutable once created, so there’s no live resizing.

Pick the protocol by caller, not by preference

Hosted agents can expose more than one protocol at once, and the right one depends on who’s calling, not what feels idiomatic:

  • Responses — the default choice for conversational or RAG agents. The platform manages conversation history and streaming lifecycle for you; any OpenAI-compatible SDK works as the client. Background/async execution is a flag (background: true), not custom polling code.
  • Invocations (HTTP) — for callers that dictate their own payload: webhooks from GitHub, Stripe, Jira, or non-conversational jobs like classification and batch processing where the input is structured JSON, not a chat turn.
  • Invocations (WebSocket) — bidirectional streaming for real-time voice agents.
  • Activity — automatic bridging when a Responses-protocol agent is published to Teams or Microsoft 365 channels; no separate integration code.
  • A2A (preview) — agent-to-agent delegation.

If you’re not sure, start with Responses — you can add an Invocations endpoint to the same agent later.

What you give up: Python and C# only

Hosted agents currently support Python and C#, framework-agnostic within that — Microsoft Agent Framework, LangGraph, Semantic Kernel, or plain custom code all work, with samples in the foundry-samples repo. If your agent logic lives in Node or Java today, that’s a rewrite, not a lift-and-shift, and it’s worth confirming before you commit an architecture to this path.

Where this actually pays off

The honest framing: reach for hosted agents when a prompt-based agent genuinely can’t express what you need — custom protocols, your own framework, controlled compute sizing, or state that has to survive across turns in files rather than just conversation history. For a straightforward instructions-plus-tools assistant, a prompt-based agent is still less to operate. Two platform notes worth flagging if you’re network-isolated: Hosted agents support deploying into network-isolated Foundry resources with your own VNet for outbound traffic, but only Foundry projects created after June 25, 2026 get a private (network-secured) container registry — older projects still need the registry reachable over its public endpoint.

A rollout order that holds up

  1. Confirm the fit — if a prompt-based agent with tools already covers the use case, don’t add a container to operate.
  2. Pick the protocol from the caller’s contract, not from what’s easiest to code against internally.
  3. Size the sandbox from a real load test, not a guess, and re-check after every version change since sizing isn’t mutable in place.
  4. Assign RBAC to the agent identity explicitly for anything beyond model calls and session storage — the defaults don’t reach your own Storage or databases.
  5. Watch region and registry constraints early, especially if network isolation or a specific region is a hard requirement.

Hosted agents are the piece that lets “we already built this agent in LangGraph” become “and now it runs on Microsoft’s compute with an Entra identity and OpenTelemetry built in” — without a rewrite. The tradeoff is the same one every managed-compute decision makes: you trade infrastructure work for a billing model you now have to understand before you turn on real traffic.

Sources & further reading: Hosted agents in Foundry Agent Service, What’s new in Hosted Agents (Build 2026), Microsoft Foundry Agent Service overview, Microsoft Agent Framework Harness and Hosted Agents reach GA — InfoQ.