Microsoft moved Foundry hosted agents to general availability — and if you read only the headline (managed compute for agents), you'll miss the two things that actually matter to a small team. The runtime is the boring part. The interesting part is that it finally decouples the framework you write in from the place it runs, and that every deployed agent gets its own identity.
The decision that just split in two#
Until now, picking an agent stack meant picking two things at once: a harness (how you write the loop — LangGraph, the Claude Agent SDK, the OpenAI Agents SDK, Microsoft's own Agent Framework) and a place to run it. The two were usually welded together, so choosing a runtime quietly chose your framework, or vice versa.
Hosted agents pull them apart. You build with any harness — Agent Framework, LangGraph or LangChain, Semantic Kernel, the Claude Agent SDK, the OpenAI Agents SDK, or plain custom code — and Foundry runs it on a runtime that's wire-compatible with the OpenAI Responses API (Microsoft Learn, InfoQ). Your agent code stays yours; the hosting is a swappable layer beneath it. That's the same "keep it portable" instinct we keep coming back to — see the broader map in Bedrock AgentCore vs Vertex Agent Engine vs Foundry Hosted Agents and the 2026 agent-SDK decision.
The feature to actually adopt: per-agent identity#
Here's the part worth changing your architecture for. Every hosted agent gets its own Microsoft Entra identity (Microsoft Foundry Blog). You assign RBAC roles to the agent, not to the app service it happens to live in, and scope exactly which models, tools, and downstream resources it may reach.
That's real least-privilege. When an agent gets prompt-injected — not if — its blast radius is bounded by its identity's permissions instead of by whatever broad credentials your process was holding. For anyone letting an agent take real actions, this is the single most useful thing in the release, and a reason to adopt hosted agents before you need the autoscaling.
What it costs#
Billing is per active execution: roughly $0.0994 per vCPU-hour of compute and $0.0118 per GiB-hour of memory, charged on the container compute an agent actually consumes (Azure pricing). For spiky, event-driven agents — a webhook fires, the agent wakes, does work, sleeps — that model is efficient: you pay for the seconds you use. For always-on loops, a long-lived container bills continuously, so model your duty cycle before assuming "pay per execution" means cheap. Treat those numbers as a starting point and confirm the current rate before you commit.
Where the lock-in hides#
The portability claim is real but bounded. Your harness is portable — a LangGraph graph runs the same on Foundry as anywhere. But the identity model (Entra), the observability, and the billing are Azure-shaped. Adopting hosted agents pulls that slice of your stack onto Azure even though your agent code stays framework-neutral.
The founder read: if you already live in Entra and Azure, this collapses a pile of deploy-and-permissions glue into a managed primitive — take it, and take the per-agent identity first. If you're on AWS or GCP, the "bring any harness" promise is genuine, but you're adopting an Azure hosting layer to get it; weigh it against the AWS and Google equivalents in the three-way comparison before you move the runtime. Either way, keep the harness portable — that's the part this release finally lets you protect.
