On raw Anthropic/OpenAI APIs you assemble the agent stack yourself. Here's exactly what Foundry hands you pre-built — and the surprise: it runs your SDK code too.
← Back to the decision map (axis overview)
In the orientation map, this axis was summarised as one trade: control vs. time-to-production. That's true, but it hides the most important fact — so let's correct it before anything else.
It's tempting to picture "Foundry agents" as Microsoft's competitor to the OpenAI Agents SDK and the Anthropic (Claude) Agent SDK — a third framework you'd have to learn and get locked into. That's wrong. Foundry Agent Service is a managed runtime that explicitly hosts agents written with Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK, or your own code.1
So the question isn't "their framework or mine." It's "how much of the surrounding plumbing do I want to operate myself?" — and Foundry lets you pick a point on that spectrum without rewriting your agent logic.
When you build an agent on the raw Anthropic messages or OpenAI responses API, the model call is the easy 10%. These are the layers you end up owning — each is a real component to build, secure, scale, and keep alive:
Anthropic and OpenAI do hand you some of this — both ship agent SDKs, built-in tools (web search, file search, code/computer use), handoffs, guardrails, and tracing.4 But the hosting, enterprise identity, governance, evaluation pipeline, and multi-provider portability are still yours to assemble. That gap is precisely what Foundry sells.
Foundry exposes three levels of "how much do I hand over," and you can move up the spectrum later without rewriting your agent.1
Defined by config alone — instructions + model + tools, authored in the portal or via SDK/REST. Foundry runs it.
Your code (OpenAI/Anthropic SDK, LangGraph…), packaged as a container or zip. Foundry runs it with a managed endpoint, autoscale, per-agent Entra identity.
Keep your agent running wherever it is; just call Foundry's Responses API for models + platform tools.
The Responses API is Foundry's single entry point for all agent types — it's the successor to OpenAI's Assistants API (being sunset in 2026) and unifies chat + tools.1,4 Mentally: it's where Foundry put the orchestration primitives, the way Anthropic's Messages API + Agent SDK is where Anthropic put theirs. The win is that one endpoint fronts every model in the catalog — "swap models without changing your agent code."1
Whichever level you pick, these come pre-built. Map each back to a layer in the DIY stack above:
A fair worry for a buy decision: "does committing to Foundry's agent layer lock me in?" Two things cut against it. MCP (tools) and A2A (agent-to-agent) are open, model-agnostic standards Foundry speaks natively1 — and Toolbox exposes your curated tools through a single MCP-compatible endpoint that any runtime can consume.1 Combined with "bring your own SDK," your agent logic and tool definitions stay portable. What's Foundry-specific is the managed hosting + governance, not your code. (The genuinely sticky, Foundry-exclusive tools are the Microsoft-data ones: SharePoint, Work IQ, Fabric IQ.1)
| Layer | Roll your own DIY | Foundry Agent Service managed |
|---|---|---|
| Agent framework | Your choice (you host it) | Same choices — but Foundry can host them for you |
| Orchestration | You write the loop / use an SDK | Prompt agents need none; hosted agents reuse your SDK |
| RAG / grounding | Build the whole pipeline | Foundry IQ — managed, cited, hybrid search |
| Memory | Your own store + extraction | Built-in memory tool / APIs (preview) |
| Tools | Host each + run MCP servers | Built-in catalog + managed MCP connections |
| Evals & tracing | Build harness + instrument | Built-in evals, optimizer, end-to-end tracing |
| Identity & safety | Your auth + content filtering | Per-agent Entra identity, RBAC, XPIA guardrails |
| Hosting / scale | Your containers + infra | Managed endpoint, autoscale, versioning, publishing |
| Multi-model | Integrate each provider | One Responses endpoint over the whole catalog |
| Best when… | Max control, niche orchestration, no Azure footprint, avoid platform fees | Want speed + enterprise governance, already on Azure, multi-model, don't want to operate infra |
Judgement, not code. Instant feedback on each.
1. Your team already has a working agent built on the Anthropic Agent SDK and likes it. A stakeholder says "but if we go Foundry we'll have to rebuild it on Microsoft's framework." The accurate response is:
2. An org wants Foundry's managed RAG so answers come back grounded with citations, without building a vector pipeline. Which component does that — and via what mechanism?
3. A CTO worries adopting Foundry's agent layer means total lock-in. What's the strongest counter — and the honest caveat?
You've now mapped model access (0001) and build tooling & agents (this one). The two axes left to deep-dive are enterprise & compliance (the residency/identity/data-flow teeth) and the commercial model (PTU vs per-token economics with real break-even math). Say which, or throw me a scenario from your own decision and I'll pressure-test it.