TL;DR
Microsoft Foundry Agent Service and Microsoft Agent Framework are complementary, not competing. Agent Framework is the open .NET and Python developer framework for building agents and multi-agent workflows in code — the design and orchestration layer. Foundry Agent Service is the managed runtime and control plane that runs, secures, observes, and publishes those agents inside Microsoft Foundry.
Microsoft Foundry Agent Service and Agent Framework
AI agents are moving past the “chatbot with tools” phase.
The interesting question is no longer only whether a model can call a function, search a document, or generate a response. The harder question is whether an organization can run agents as reliable software systems: with identity, state, observability, governance, deployment, evaluation, and integration into real business workflows.
That is where Microsoft Foundry Agent Service and Microsoft Agent Framework become important.
They are related, but they are not the same thing.
A simple way to think about them is this:
- Microsoft Foundry Agent Service is the managed platform layer for running, scaling, securing, observing, and publishing agents.
- Microsoft Agent Framework is the developer framework for building agents and multi-agent workflows in code, especially when you need more control over orchestration, state, tools, and execution paths.
In other words, Agent Framework helps you design and implement the agent system. Agent Service helps you operate that agent system inside Microsoft Foundry.
That distinction matters because the future of enterprise AI agents will not be won only by better prompts. It will be won by the platforms that make agents deployable, governable, observable, and composable.
The broader picture: Foundry as the AI app and agent factory
Microsoft describes Foundry as a place to build, optimize, and govern AI apps and agents at scale. That framing is useful because it positions Foundry not as a single SDK or model endpoint, but as a production environment for the AI application lifecycle.
A modern AI application usually needs more than a model:
- model selection and deployment
- tool calling
- retrieval over enterprise data
- memory or conversation state
- evaluation
- prompt and agent optimization
- tracing and monitoring
- responsible AI controls
- identity and access control
- integration into channels like Teams, Microsoft 365 Copilot, custom apps, or APIs
Foundry’s role is to bring these pieces into one operating surface and Agent Service and Agent Framework sit inside that broader story.
The point of the diagram is not that every agent needs every box. Most do not.
The point is that production agents eventually touch many of these concerns. If those concerns are not handled by the platform, every team ends up rebuilding them differently.
What is Foundry Agent Service
Foundry Agent Service is Microsoft’s managed service for building and running agents in Foundry. Microsoft’s documentation defines an agent as an AI application that uses a model from the Foundry model catalog to reason about user requests and take autonomous actions. Unlike a simple chatbot, an agent can call tools, access external data, and make decisions across multiple steps.
The important part is the runtime layer around the model.
Agent Service provides a common entry point through the Responses API, a managed Agent Runtime, built-in and custom tools, model access through the Foundry model catalog, observability, identity, security, and publishing options.
Conceptually, this makes Agent Service less like “an SDK for calling a model” and more like a managed environment for agent execution.
The service is responsible for things such as:
- hosting and scaling agents
- managing conversations and responses
- coordinating tool calls
- integrating with Microsoft Entra identity and RBAC
- supporting observability through tracing, metrics, and Application Insights
- enabling content filters and network isolation patterns
- publishing or exposing agents through stable endpoints and channels
That is a different level of abstraction from simply making a request to a chat completion endpoint.
Prompt agents and hosted agents: two paths, different levels of control
One of the most useful distinctions in Foundry Agent Service is between prompt-based agents and hosted agents.
A prompt agent is the simpler path. You define the agent largely through instructions, model selection, and tool configuration. Foundry runs the agent for you. This is a good fit when the agent’s behavior is mostly declarative and you do not want to manage runtime code.
A hosted agent is different. It is your own code, packaged as a container image and deployed to Agent Service. Microsoft’s hosted agents documentation describes them as containerized agentic AI applications that run on Agent Service. They are useful when you want to bring your own framework ( for example, Agent Framework, LangGraph, Semantic Kernel, or custom code ) while still using Foundry as the managed runtime.
This distinction is important. It means Foundry is not forcing a single agent-building style.
You can start simple with prompt agents when the use case is straightforward. But if the agent needs custom orchestration, custom protocols, stateful workloads, special routing, or deeper integration with existing systems, hosted agents give you a path to bring your own application logic.
This is a healthy design because not every problem deserves a custom agent framework. Sometimes a prompt agent with the right tools and data is enough.
But when the process becomes complex, code becomes valuable again.
What is Microsoft Agent Framework
Microsoft Agent Framework is an open, multi-language framework for building production-grade AI agents and multi-agent workflows in .NET and Python.
It is the successor direction that brings together ideas from Semantic Kernel and AutoGen. Microsoft’s documentation describes it as combining AutoGen’s agent abstractions with Semantic Kernel’s enterprise capabilities such as session-based state management, type safety, middleware, telemetry, model support, and graph-based workflows.
That last part is especially important: workflows.
A lot of “agent” demos are open-ended loops: the model decides what to do next, calls tools, observes results, and continues. That can be powerful, but it can also be hard to govern.
Agent Framework makes a useful distinction:
- Use an agent when the task is open-ended, conversational, or requires autonomous tool use and planning.
- Use a workflow when the process has defined steps, explicit routing, human-in-the-loop checkpoints, or multiple agents/functions coordinating in a controlled path.
This is a pragmatic distinction.Not every business process should be given to a fully autonomous agent. Some processes need deterministic steps, approvals, typed inputs and outputs, retry logic, or clear routing between specialized components.
That is where Agent Framework becomes more than an “agent SDK”. It becomes an orchestration layer for AI application design.
Agent Service vs Agent Framework: the clearest mental model
The most common confusion is to compare Agent Service and Agent Framework as if they compete with each other.
They do not.
They live at different layers.
A practical way to separate them:
Agent Framework answers:
- How should the agent reason, route, and coordinate work?
- Do I need one agent or multiple agents?
- Do I need a graph-based workflow instead of open-ended autonomy?
- How do I manage sessions, middleware, tools, memory, and human-in-the-loop flow in code?
- How do I keep my application portable across model providers and hosting choices?
Agent Service answers:
- Where does the agent run?
- How is it exposed through endpoints or channels?
- How does it authenticate?
- How are conversations, responses, tools, and lifecycle managed?
- How do we trace, monitor, evaluate, secure, and publish it?
- How does it fit into Foundry, Azure, Microsoft 365, and enterprise governance?
If Agent Framework is the design and orchestration layer, Agent Service is the managed runtime and control plane.
You can use Agent Service without writing complex Agent Framework code. You can also use Agent Framework locally or with different services. But the combination becomes powerful when you want custom agent logic deployed into an enterprise-grade managed environment.
Why this matters for enterprise AI
The biggest gap between agent demos and production agents is not intelligence. It is operations. A demo can be impressive with a model, a prompt, and a few tools.
A production agent needs answers to boring but critical questions:
- Who is the agent acting as?
- What data can it access?
- Which tools can it call?
- Can it act on behalf of a user?
- Can it run autonomously without a user token?
- Where is conversation state stored?
- What happens when it fails halfway through a workflow?
- Can we replay or inspect its decisions?
- How do we evaluate whether it is improving or regressing?
- How do we publish it safely into business channels?
This is why Agent Service’s identity model is important.
Hosted agents, for example, get a dedicated Microsoft Entra ID agent identity. In user-invoked scenarios, the platform can support OAuth On-Behalf-Of flows when a user token is present. In autonomous or background scenarios, the agent can authenticate using its own identity, typically through managed identity patterns.
This maps much better to enterprise reality than treating agents as anonymous API calls. In real organizations, agents need to be auditable actors.
Tools, data, and MCP: agents need capabilities, not just prompts
An agent without tools is mostly a conversational model with instructions.
Foundry Agent Service exposes built-in tools such as file search, code interpreter, memory, web search, MCP servers, and custom functions. The Responses API acts as a common access point for models and platform tools.
This matters because the agent stack is becoming more modular.
A useful agent may need to:
- search internal documentation
- query structured data
- call a line-of-business API
- execute code in a controlled environment
- access files
- invoke MCP servers
- remember relevant state across turns
- hand off to another process or agent
Agent Framework also supports tools and MCP integration at the application layer. This gives developers flexibility: some tools may be platform-managed, some may be framework-level integrations, and some may be custom services behind enterprise APIs.
The architectural question becomes: Which capabilities should live in Foundry as managed tools, and which should live in my application or workflow code?
There is no universal answer. For common capabilities like file search, code execution, memory, and standardized tool protocols, platform-managed tools can reduce operational burden. For domain-specific business logic, custom APIs or framework-level functions often make more sense.
How this connects with the rest of Foundry
The Agent Service and Agent Framework story becomes more interesting when you place it next to the rest of the Foundry toolkit.
A production agent lifecycle might look like this:
This loop is more important than any individual feature.
Agents should not be treated as “ship once and hope” systems. They need an iteration loop:
- Build the agent.
- Connect it to data and tools.
- Run it in a managed environment.
- Trace what happened.
- Evaluate quality and safety.
- Improve prompts, tools, workflow design, or model choice.
- Redeploy and monitor again.
That is the broader Foundry value proposition: not just agent creation, but an agent lifecycle. For enterprise teams, this lifecycle is where many AI projects either mature or fail.
Microsoft Foundry Agent Service versus Agent Framework: comparison table
| Dimension | Foundry Agent Service | Agent Framework |
|---|---|---|
| Layer | Managed runtime & control plane | Developer orchestration & design layer |
| Primary job | Run, scale, secure, observe, and publish agents | Build agents & multi-agent workflows in code |
| Question it answers | Where does the agent run and how is it governed? | How should the agent reason, route, and coordinate? |
| Form factor | A managed service inside Microsoft Foundry | An open framework for .NET and Python |
| Control level | Prompt agents (declarative) or hosted agents (your container) | Full code control: sessions, middleware, tools, graph workflows |
| Identity & security | Entra agent identity, OBO, managed identity, RBAC | Application-level logic; relies on the host for runtime security |
| Best when | You need an enterprise runtime, endpoints, channels & observability | You need custom orchestration, portability, or complex routing |
| Used together | Hosts your framework code as a governed runtime | Supplies the agent logic deployed into Agent Service |
A practical decision guide
If we were advising a team, we would not start by asking, “Should we use Agent Framework or Agent Service?”
We would start with the shape of the task.
If the task is mostly conversational, has a limited set of tools, and does not require custom runtime behavior, start with a prompt agent in Foundry Agent Service. It keeps the surface area smaller and lets the team focus on instructions, model choice, data, and evaluation.
If the task has explicit business steps, approvals, branching, human-in-the-loop checkpoints, or multiple specialized components, use Agent Framework workflows. Then deploy through Agent Service if you want the managed Foundry runtime and enterprise integration.
If the task needs your own code, custom protocols, long-running work, special state handling, or framework portability, use a hosted agent. Agent Framework can be the orchestration layer, while Agent Service provides the runtime envelope.
If the task is just a deterministic API operation, do not force an agent into it. Write the function. Then let the agent or workflow call that function only when reasoning or natural language interaction adds value.
That last point is underrated. Good agent architecture is not about making everything autonomous. It is about deciding where autonomy helps, and where deterministic software should remain deterministic.
The strategic takeaway
Microsoft’s agent stack is moving toward a layered model:
- Foundry as the AI app and agent factory.
- Agent Service as the managed runtime and control plane.
- Agent Framework as the developer orchestration layer.
- Models, tools, data, memory, MCP, identity, evaluation, and observability as supporting capabilities around the agent.
This is the right direction because enterprise agents are not just prompts. They are systems.
The real value will come from how these layers work together:
- Agent Framework gives developers structure when agent behavior becomes complex.
- Agent Service gives organizations a managed place to run and govern those agents.
- Foundry connects the surrounding lifecycle: models, tools, data, evaluation, optimization, monitoring, and publishing.
For us, the most important shift is this:
We are moving from building agents as isolated experiments to operating agents as managed, observable, governed AI applications.That is where Microsoft Foundry becomes interesting. Not because it magically removes all complexity, but because it acknowledges the complexity that production agents actually have. And in enterprise AI, acknowledging the boring complexity is usually the first step toward building something real.
Sources and further reading
- Microsoft Learn — What is Microsoft Foundry Agent Service
- Microsoft Azure — Foundry Agent Service product page
- Microsoft Learn — Microsoft Agent Framework overview
- Microsoft Learn — Microsoft Agent Framework agent types
- Microsoft Learn — Hosted agents in Foundry Agent Service
- Microsoft Learn — Build with agents, conversations, and responses in Foundry Agent Service
- GitHub — microsoft/agent-framework README
FAQ
They operate at different layers and are complementary, not competing. Agent Framework is the developer framework for building agents and multi-agent workflows in code. Foundry Agent Service is the managed platform that runs, secures, observes, and publishes those agents inside Microsoft Foundry.
It is Microsoft's managed service for building and running agents in Foundry. It supplies a common entry point through the Responses API, a managed Agent Runtime, built-in and custom tools, model access via the Foundry model catalog, plus observability, identity, security, and publishing.
It is an open, multi-language framework for building production-grade AI agents and multi-agent workflows in .NET and Python. It brings together AutoGen's agent abstractions and Semantic Kernel's enterprise capabilities, including session state, type safety, middleware, telemetry, and graph-based workflows.
No. The common confusion is to compare them as rivals, but they live at different layers. Agent Framework is the design and orchestration layer; Agent Service is the managed runtime and control plane. They are strongest when combined.
A prompt agent is declarative — you define it through instructions, model selection, and tools, and Foundry runs it for you. A hosted agent is your own code packaged as a container image and deployed to Agent Service, so you can bring your own framework while using Foundry as the managed runtime.
Use an agent when the task is open-ended, conversational, or needs autonomous tool use and planning. Use a workflow when the process has defined steps, explicit routing, human-in-the-loop checkpoints, or multiple agents and functions coordinating on a controlled path.
Yes, and that is where they are most powerful. Agent Framework can be the orchestration layer for custom agent logic, while Agent Service provides the enterprise-grade managed runtime, identity, observability, and publishing envelope.
Hosted agents get a dedicated Microsoft Entra ID agent identity. In user-invoked scenarios, the platform can support OAuth On-Behalf-Of when a user token is present; in autonomous or background scenarios, the agent authenticates with its own identity, typically through managed identity patterns — so agents behave as auditable actors.
Foundry Agent Service exposes built-in tools such as file search, code interpreter, memory, web search, MCP servers, and custom functions, all reachable through the Responses API. Agent Framework also supports tools and MCP integration at the application layer.
Start from the shape of the task. Mostly conversational with a few tools → a prompt agent. Explicit steps, approvals, or branching → Agent Framework workflows deployed via Agent Service. Custom code, protocols, or portability → a hosted agent. A purely deterministic operation → just write the function and let an agent call it only when reasoning adds value.
