Microsoft Foundry Agent Service: architecture, components and pricing (the Azure agent platform)

Microsoft Foundry Agent Service: architecture, components and pricing (the Azure agent platform)

If you are mapping the agent-platform choice across clouds, this is the Azure piece. We have the same breakdown for AWS in Amazon Bedrock AgentCore and for Google in What is Vertex AI. Here we focus on Microsoft Foundry Agent Service on its own.

The naming, untangled

More confusion lives in the names than in the technology, so settle it first. As of October 2026:

The one distinction that trips up most teams: Foundry Agent Service is the runtime you deploy to; Microsoft Agent Framework is the SDK you build with. They are not the same product, and you do not have to use them together. MAF is open-source and runs anywhere; Foundry Agent Service happens to host it well. You can also build “Foundry-native” agents without MAF at all. We come back to that split below, because it is also what drives the bill.

For reference, the sources: the Foundry Agent Service product page, the Foundry Agent Service pricing page, and Microsoft’s Agent Framework announcement.

What Foundry Agent Service does

Foundry Agent Service is a modern API, runtime, and developer platform for moving an agent from prototype to production, operated with Foundry’s enterprise security, observability, and governance. It reached general availability in 2026.

There are two ways to run an agent on it, and the difference matters for both architecture and cost:

• Foundry-native agents. You build the agent from prompts and workflows directly in the Foundry SDK or the Foundry portal. Microsoft charges nothing extra for creating or running these - you pay only for what they consume (model tokens and any tools).
• Hosted agents. You bring an agent built with an external open-source framework - Microsoft Agent Framework or LangGraph - and run it on a fully managed Foundry runtime, in a customer-dedicated container with built-in scaling, observability, security, and governance. This is the direct parallel to AgentCore’s “bring your framework, run it on managed isolated infrastructure” model, and it is billed on container compute.

Microsoft describes the hosted path as “deploy with one command to hosted agents, a session-isolated managed runtime with autoscaling and zero idle cost”. That is their claim, and the session-isolation and autoscale-to-zero shape matches what the pricing model implies; treat the “zero idle cost” line as the vendor’s framing, not a figure we have independently load-tested.

Native vs hosted: the choice that drives the bill

Because native and hosted are billed completely differently, the choice between them is the first cost decision, not an implementation detail.

The practical read: if your agent is straightforward, native keeps the platform cost at zero and you only pay for tokens and tools. The moment you need the control of a real framework - multi-agent workflows, human-in-the-loop, your own orchestration - you move to hosted and take on the container compute. That is a genuine architectural fork, and it is worth deciding deliberately rather than by default.

How much does Foundry Agent Service cost - pricing and cost model

Foundry Agent Service is billed by consumption, in the same spirit as AgentCore: no license fee for “the platform”, you pay for the parts you use. The cost has three layers.

The cost layers

1. The orchestration layer is free for native agents. Creating and running Foundry-native agents (prompts and workflows) carries no platform charge. This is a real difference from a runtime where every agent-second is billable.
2. Models are where most of the spend lands. Token consumption is billed through Foundry Models, on a separate pricing page, per the model you pick. As on every agent platform, at real traffic this is usually the largest line.
3. Hosted agents and tools are metered on top. Hosted agents bill container compute per vCPU-hour and GiB-hour. Tools and knowledge are each separate charges.

Per-component rates

Here is the honest part, and it is also the catch. The components and their billing units, per the Foundry Agent Service pricing page (as of October 2026):

How to read the cost shape

Even without the masked figures, the shape is clear and it mirrors the other clouds:

• At low traffic, native agents plus a modest token spend can be genuinely cheap - the free orchestration layer is doing real work here. Hosted agents change that, because container compute runs whenever the agent is up.
• At real traffic, model tokens dominate, exactly as they do on AgentCore and Vertex. The platform layer, native or hosted, is usually a minority of the bill.
• Tools and knowledge are easy to under-budget. File Search vector storage, Code Interpreter sessions, Web Search transactions, and especially the separately-licensed connectors (Fabric, SharePoint, Bing grounding, Foundry IQ) add up and are billed apart from the agent itself.

The FinOps takeaway is the same one we keep arriving at with agents: the per-agent platform cost is rarely the problem. Token spend and fragmented tool/knowledge resources are. That is the same fragmentation mechanism we described in agent sprawl - cost comes from multiplying resources, not from a single service.

How it compares to AgentCore and Vertex

The short version, because it is the obvious next question: all three major clouds now offer the same core pattern - a managed, isolated runtime where you bring your framework and deploy an agent without standing up your own infrastructure. AgentCore (Strands, LangGraph, others), Vertex’s agent platform, and Foundry Agent Service (Microsoft Agent Framework, LangGraph) are converging on that shape.

The differences are in the details that matter for a decision: pricing transparency (AWS publishes rates; Azure gates them behind the calculator), the framework story (each cloud pushes its own first-party SDK while supporting LangGraph), and ecosystem gravity (which cloud your data, identity, and tools already live in). A full three-way comparison is its own piece - and the one most teams actually need before committing. If that is where you are, the AWS and Google breakdowns linked above are the other two legs of it.

Where it fits for a team on Azure

If you are already on Azure, Foundry Agent Service is the path of least resistance for production agents - and the decisions worth getting right early are:

• Native vs hosted vs Agent Framework. This is the fork that sets both your architecture and your cost base. Decide it against the actual workload, not the demo.
• Model-spend sizing. Tokens are the biggest variable. Sizing them against real session volume is the difference between a budget that holds and one that does not.
• Tool and knowledge governance. Connectors, File Search collections, and grounding sources are separately billed and easy to sprawl. Consolidate where you can.

When it is worth bringing in an external partner

• The cost model. Consumption billing across native, hosted, models, and tools - with the per-unit rates behind a sign-in - is hard to estimate without doing the calculator work for your region and volume. It drives the budget.
• The native-vs-hosted-vs-MAF decision. It is an architectural choice with a long maintenance tail, not a one-off deployment.
• Cross-cloud comparison. If you are genuinely choosing between AgentCore, Vertex, and Foundry, the right answer depends on where your data and identity already sit as much as on the platforms themselves.

Summary

Microsoft Foundry Agent Service is Azure’s managed platform for running AI agents in production - the third leg alongside AWS AgentCore and Google’s Vertex agent platform. Three things to remember:

1. Names first. Microsoft Foundry (formerly Azure AI Foundry) is the platform, Foundry Agent Service is the agent runtime, and Microsoft Agent Framework is the open-source SDK (Semantic Kernel + AutoGen converged). The runtime and the SDK are not the same thing.
2. Native vs hosted is the cost fork. Native agents carry no platform charge; hosted agents bill container compute per vCPU-hour and GiB-hour. Model tokens and tools are extra in both cases.
3. Azure hides the numbers. Unlike AWS, the per-unit rates are behind the calculator and a sign-in - so sizing an Azure agent takes more work, and that opacity is itself a point to weigh when comparing clouds.

Frequently asked questions about Foundry Agent Service

Choosing between native and hosted agents on Foundry?

Book a free 30-minute call. We help teams on Azure pick between Foundry-native and hosted agents, size the real model and tool spend, and decide between AgentCore, Vertex, and Foundry when the choice is still open.

Book a call Send a message