What building AI agents on Microsoft’s platform actually looks like in 2026 — and what I wish more teams understood before they pick a framework.
Take an agent written in LangGraph, package it as a container image, deploy it to Microsoft Foundry’s hosted agent runtime. It gets its own Microsoft Entra identity the moment it spins up. It scales itself to zero the second traffic stops. It emits OpenTelemetry traces without anyone writing a line of instrumentation code. None of that came from the framework. It came from the platform underneath it.
That’s the shift I think most teams building on Azure in 2026 haven’t fully clocked yet: Microsoft’s agent offering isn’t a product anymore — a single SDK, a single prescribed way of writing agents. It’s a platform you build on. The frameworks running on top of it are interchangeable. The value Microsoft is actually selling lives in the plumbing underneath: the runtime, the identity layer, the tool governance, the observability that turns a weekend prototype into something an enterprise can actually run and defend.
Where the code actually runs
Foundry gives you three ways to run an agent, and I’d stop anyone from treating them as a ladder where one option is “more advanced” than the others. They’re a spectrum of how much you hand over — nothing more.
Prompt agents are mostly configuration with very little code. You define them in the Foundry portal, or with SDKs and REST calls, and Foundry runs them for you. There’s less application code to maintain, no compute to provision, and no infrastructure to patch.I’d reach for this more than most teams expect — a surprising amount of what people build agents for is fully expressible as instructions, tools and a model.
Hosted agents are your code, packaged as a container image — or a zip that Foundry turns into one for you — running on a managed runtime. Each session gets its own hypervisor-isolated sandbox with a persistent filesystem, scale-to-zero autoscaling, an auto-provisioned Entra identity, and OpenTelemetry tracing out of the box. This is where I tell teams to put custom logic, long-running workflows, anything with real multi-agent orchestration.
Direct API use means you skip Foundry’s agent constructs entirely. Keep your existing application, call Foundry’s Responses API straight from your own process — it’s OpenAI-SDK-compatible and hands you Foundry’s models and platform tools (file search, code interpreter, memory, web search, MCP servers, SharePoint and Fabric integrations) without ever creating an agent resource.
Workflows can chain specialized agents step by step, stream updates as work progresses, and make complex automation more reliable by separating responsibilities, tools, and instructions for each stage.
None of these four is the “right” default. Prompt agents for config-only bots, hosted agents for anything with real application logic, workflows for improving clarity, reuse and scalability, direct API use for teams who already have an agent stack and just want Microsoft’s models and tools sitting behind it.
What we’re actually free to build it with
Here’s the part that still surprises people who last touched Azure AI tooling a year or two ago: hosted agents aren’t locked into a Microsoft-authored SDK. The runtime happily hosts Microsoft’s own Agent Framework — the unified SDK that absorbed Semantic Kernel and AutoGen when both went into maintenance mode in October 2025, and hit 1.0 general availability in April 2026 — but it hosts LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK and the GitHub Copilot SDK on exactly the same footing. Ship a container image, or ship a zip and let Foundry build the image for you, and the runtime genuinely does not care which framework wrote your agent logic.
So here’s the line I’d want every architecture discussion to end on: choosing Azure no longer means choosing a Microsoft framework. Pick the framework because it’s the right tool for the job — the abstraction model, the community, what your team already knows — and treat the hosting decision as a completely separate call.
How agents get their tools and data
Quickly, three things worth knowing.
Foundry comes with built-in tools you don’t have to host yourself: a code interpreter for sandboxed Python, file search over your documents via vector retrieval or web search with inline citations.
For anything outside that catalogue, there’s Model Context Protocol (MCP) support — connect external and custom tools through a standard interface instead of hand-wiring an integration for every agent that needs it.
The bit I find more interesting than either of those is Toolboxes, currently in public preview: a single managed endpoint for tools, skills, MCP clients and enterprise data integrations. Register a tool once, and every agent in the project can discover it at runtime instead of someone copy-pasting the same integration into agent after agent. Skills work the same way — versioned in a project-scoped catalogue, discoverable as MCP resources by anything that needs them.
The thing worth saying out loud: tool governance has moved out of the individual agent and into a shared layer. Once you’re running more than a handful of agents, that decision matters more than which framework wrote the reasoning loop — by a wide margin.
Identity and governance — the part I actually get excited about
This is, genuinely, the strongest part of what Microsoft has built here.
Every hosted agent gets its own Microsoft Entra Agent ID automatically, the moment it’s deployed — a real, auditable identity with its own access policies, its own lifecycle, its own audit trail. Not a shared service account that every agent in the org quietly inherits.
Why I care about this: it means you can answer “which agent did this, on whose behalf, under what policy” from a log, after the fact — instead of reverse-engineering intent out of application code at 11pm because a client is asking hard questions. That question, more or less in its entirety, is what an agent security review is.
Cost and data residency — the unglamorous part nobody skips a step on
Two things I’d tell anyone budgeting a project or working under EU rules, plainly.
Your bill comes from several independent meters, not one line item. Foundry Agent Service itself doesn’t add a charge, but you pay separately for model tokens, for tool invocations (Bing grounding, Azure AI Search, Fabric and SharePoint connections, other action tools), for hosted-agent compute (billed per vCPU-hour and per GiB-hour, with real scale-to-zero when idle), and — if you’re using the managed memory service — a separate per-event, per-stored-memory and per-retrieval charge. Add governance licensing on top and the invoice reads more like a utility bill than a single SKU. Plan for that up front so nobody’s surprised in month three.
Region, storage setup and deployment type decide where your agent’s data actually lives — and you decide that at setup, not later. Foundry Agent Service endpoints are regional: data sits in the same region as the endpoint you provisioned. Pick a Data Zone deployment (US, EU or APAC) and processing stays inside that zone; pick Standard or Regional and it stays inside the specific region you chose. For EU teams, the EU Data Zone currently covers France, Germany, Italy, the Netherlands, Norway, Poland, Spain, Sweden and Switzerland. Get this wrong at provisioning and you’re not tweaking a setting — you’re standing up a new deployment.
What I’d stay cautious about
A handful of honest caveats, because I don’t think this piece is worth writing if it reads like a sales sheet.
A lot of what’s above is still moving fast. Hosted agents themselves only reached general availability around mid-2026 after months in preview, and Toolboxes, Skills and agent-to-agent (A2A) communication are still preview features as I’m writing this. Preview features change under you, sometimes in breaking ways — don’t anchor a production architecture on one without a fallback.
Tool availability isn’t uniform across regions. Browser automation, computer use, and some model deployments vary by region and by model — a design that works cleanly in one Azure region can need real rework in another.
The governance layer is a genuinely separate, per-seat licence sitting outside Foundry Agent Service’s own billing. Budget for it as its own line item, not something bundled in by default.
And framework freedom at the runtime, real as it is, isn’t the same as full platform portability. The gravity of this platform sits in its tools, identity and observability layers, not the framework code. An agent built for Foundry’s hosted runtime picks up dependencies — on Entra Agent ID, on the Toolbox pattern, on Foundry’s tracing — that don’t move cleanly to another cloud, even though the framework code technically would.
Where I land on all this
Here’s the pattern, once you strip away the product names. Agents became something you could actually engineer — version, secure, meter, operate — the moment they had three things: a versioned artifact you could deploy and roll back, an identity you could audit, and a cost meter you could point at a specific workload. Microsoft made those three things the default for anything running on this platform, and deliberately left the fourth question — which framework you write your agent logic in — wide open.
That’s a genuinely different bet than the “buy our SDK” era of AI tooling we all just lived through. And it’s exactly why I keep steering framework debates back to the plumbing question first. Pick your framework because you like it. Just don’t let that be the decision that actually determines whether the thing you build is operable a year from now.
This article reflects Microsoft’s Foundry Agent Service platform as documented in July 2026. Microsoft’s agent tooling is evolving quickly; teams should verify current feature status, regional availability and pricing against Microsoft’s official documentation before making architecture decisions.
