Foundry Hosted vs In-Process vs Copilot Studio Agents (2026 Decision)

A team lead asks the question in a planning meeting and the room splits three ways: do we build this agent in Copilot Studio, write the orchestration ourselves and host it, or hand our container to Foundry and let it run our code? All three are official Microsoft build paths in 2026, all three end up in the same tenant-wide agent inventory, and the wrong pick costs you a rebuild once the project outgrows it.

The answer is not “the most powerful one.” It is the one whose service model matches who is building the agent, who owns the runtime, and how much pro-code control over orchestration and protocols you actually need. This article is the decision framework for that choice, grounded in Microsoft Learn and current as of mid-2026.

Two of these three paths are public preview, so this is a guide to architectural fit and direction, not a production-reliability scorecard.

The three paths in one paragraph each

Microsoft’s own Cloud Adoption Framework frames the build options as three service tiers, which is the cleanest mental model to start from. The CAF positions them as Copilot Studio (SaaS, no/low-code), Microsoft Foundry (PaaS, pro-code or low-code), and GPUs and Containers (IaaS, code-first frameworks for maximum flexibility). The first two are managed by Microsoft. The third is where the self-hosted SDK path lives when you own the compute end to end.

Copilot Studio is a graphical, low-code tool for building agents and agent flows, part of the Power Platform set. Microsoft describes it as a fully managed SaaS platform where makers focus on agent experiences without worrying about infrastructure, hosting, or governance. It connects to data via prebuilt or custom connectors, can run standalone, and can extend Microsoft 365 Copilot with enterprise data.

Foundry Hosted agents are the middle path. Foundry Agent Service is a managed platform for building, deploying, and scaling agents, and it offers two agent types: Prompt agents (fully managed, no code or compute to maintain) and Hosted agents (your own containerized code, run by Foundry with a managed endpoint, scaling, identity, and observability). Hosted agents are the option that interests pro-dev teams who want to keep their orchestration code but not run the servers.

The Microsoft 365 Agents SDK is the self-hosted, pro-code path. It lets developers build custom engine agents using the AI stack of their choice and deploy them to Microsoft 365 Copilot. It is model- and orchestrator-agnostic and can surface agents across Microsoft 365 Copilot, Teams, third-party platforms, custom applications, and websites. The trade is that you host the orchestration process yourself.

A note before the comparison, because the brief flagged it as an open question: Foundry also offers Prompt agents, the fully-managed no-code-runtime option inside the same Agent Service. This article treats the three build paths the title names. Prompt agents are a separate managed option within Foundry Agent Service, and if you do not need custom code at all, they sit alongside Copilot Studio as a low-effort choice rather than competing with the Hosted path.

What “in-process” actually means here

“In-process” is the part of this comparison that trips people up, so it is worth pinning down. In-process here means the Microsoft 365 Agents SDK self-hosted path. It refers to running the agent’s orchestration inside a process you own and host, rather than handing a container to Foundry or building declaratively in Copilot Studio. Two pieces matter.

The first is the host. With the Microsoft 365 Agents SDK, your Program.cs manages hosting (for example an ASP.NET host in C#), registers storage (the samples use Memory Storage, switchable to Blob or Cosmos DB for production), and routes the api/messages endpoint. You provision and pay for that compute, typically on Azure, separately from the agent itself.

The second is the orchestrator that runs inside that host. Both Semantic Kernel and the Microsoft Agent Framework can be the orchestrator inside an Agents SDK agent. Semantic Kernel implements orchestration patterns directly in the SDK (Concurrent, Sequential, Handoff, Group Chat, Magentic) and ships an in-process runtime via the Microsoft.SemanticKernel.Agents.Runtime.InProcess package. That literal “InProcess” runtime is where the term comes from.

The useful detail for planning: the Microsoft Agent Framework is the direct successor to Semantic Kernel and AutoGen, built by the same teams. It combines AutoGen’s agent abstractions with Semantic Kernel’s enterprise features and adds graph-based workflows for explicit multi-agent orchestration, in C# and Python public preview. The same Agent Framework code can run inside your own process today and be packaged as a Foundry Hosted agent later. The hosting integration lets you take any Agent or workflow and expose it through the Foundry Responses or Invocations protocol, deploying it as a containerized Hosted agent; for C# you install the Microsoft.Agents.AI.Foundry.Hosting and Azure.AI.Projects NuGet packages.

That last point reframes the whole decision. In-process self-hosted and Foundry Hosted are not opposite ends of a religious war. They can be the same orchestration code with a different runtime owner. That makes “start in-process, graduate to Hosted” a real migration path rather than a rewrite, and it lowers the stakes of getting the first call slightly wrong.

How Foundry Hosted agents actually run

If you have not deployed one, the Hosted agent runtime model is worth understanding because it drives several decisions below. Foundry Hosted agents are containerized agentic applications: you package your agent as a container image, push it to Azure Container Registry, and at deploy time Agent Service pulls the image, provisions compute, assigns a dedicated Microsoft Entra ID agent identity, and exposes a dedicated endpoint. The platform handles scaling, session state persistence, observability, and lifecycle management.

The runtime is per-session and sandboxed. Hosted agents run in per-session VM-isolated sandboxes with a persistent filesystem ($HOME and /files), which enables scale-to-zero with stateful resume. The design intent is short-lived idle sessions that suspend cheaply, with a hard session lifetime ceiling.

Hosted runtime specs at a glance (preview defaults, re-verify before sizing). From the Hosted agents concepts doc:

• Sandbox sizes: 0.5 vCPU / 1 GiB, 1 vCPU / 2 GiB, or 2 vCPU / 4 GiB
• Session idle timeout: 15 minutes
• Session lifetime: permanently deleted after 30 days of inactivity
• Concurrency: default 50 maximum active concurrent sessions per subscription per region (adjustable via Microsoft Support)

Bring-your-own framework is the headline. Hosted agents let you bring your own code in any framework - Microsoft Agent Framework, LangGraph, Semantic Kernel, OpenAI Agents SDK, Anthropic Agent SDK, GitHub Copilot SDK, or custom code (the last three via the Invocations protocol bridge). Language support is Python and C#, and the protocol libraries are framework-agnostic. If your team has standardized on LangGraph, you do not have to abandon it to get a managed Microsoft runtime.

Tools are opt-in, not automatic. Hosted agents reach Foundry-managed tools (Code Interpreter, Web Search, Azure AI Search, OpenAPI, custom MCP connections, A2A) through a Toolbox MCP endpoint provisioned in the project. The agent code connects to this endpoint using standard MCP client libraries, and the platform does not inject tools automatically. That is a deliberate design choice: you wire the tools you want rather than inheriting a fixed set, which is closer to how a code-first developer expects to work.

A few constraints to put in the architecture doc. Hosted agents are in public preview, billed on consumption of CPU and memory during active sessions plus per-call inference and tool usage. They support deployment within network-isolated Foundry resources and can use a customer-provided Azure Virtual Network for outbound traffic, but the Azure Container Registry holding the image must currently remain reachable over its public endpoint. If a fully air-gapped registry is a hard requirement today, that is a gap to confirm against current docs before committing.

The side-by-side comparison

This is the load-bearing table. Read it by dimension, not by column. The cross-links referenced in these rows live in the body and Read Next sections, not in the cells.

A few cells deserve the prose that does not fit in a table cell.

On governance, all three paths converge in one place. Foundry, Copilot Studio, and other Microsoft agents surface in a single tenant-wide inventory: administrators view and govern them under Microsoft Entra admin center, Entra ID, Agent ID, All agent identities, where they can apply Conditional Access, Identity Protection, network access controls, and lifecycle governance. All three land in one shared Entra identity inventory you can see in one place, even though each platform keeps its own governance control plane. Shared visibility is not a unified control plane.

On channels, the practical difference is reach versus native simplicity. In Microsoft’s custom-engine-agent comparison, the Agents SDK reaches Microsoft 365 Copilot, Teams, partner apps, mobile apps, and custom websites, while Foundry reaches Microsoft 365 Copilot and Teams natively, with other channels requiring custom integration. Copilot Studio agents can run across websites, mobile apps, Facebook, Microsoft Teams, or any channel supported by the Azure Bot Service, and can be published to Microsoft 365 Copilot. If your distribution requirement is “everywhere our customers are,” the SDK and Copilot Studio reach further than Foundry’s native channels.

How do you choose between Foundry Hosted, in-process, and Copilot Studio?

Run four gates in order and take the first hard answer: Gate 1 is who builds it (no coder means Copilot Studio), Gate 2 is who owns the compute (must own it means self-hosted SDK), Gate 3 is your code on managed infra (yes means Foundry Hosted), and Gate 4 resolves channels and protocols. Skip the feature checklist on the first pass.

Gate 1 - Who is building this, and do they write code? If the builder is a business maker or analyst with no developers attached, the answer is Copilot Studio. It is explicitly for makers building departmental, organizational, or external-customer agents with multi-step workflows, approvals, branching, autonomous capabilities, and Azure AI integration, all without code. If you do not have pro-dev capacity and the use case fits connectors and flows, stop here. You do not need Foundry or the SDK.

Gate 2 - Must you own the compute? If a hard requirement (a data-residency mandate, an existing hosting estate, a need to run inside a network boundary that Foundry’s container registry constraint cannot meet) forces you to own the runtime, the Microsoft 365 Agents SDK self-hosted path is the answer. You bring your own orchestrator, host it yourself, and accept that you are responsible for compliance, security, and responsible AI of the hosted runtime. This is the most control and the most operational burden.

Gate 3 - Do you want your own code but not your own servers? If you have orchestration logic to write but no appetite to run the infrastructure, Foundry Hosted agents are the fit. You containerize the code, push to ACR, and Foundry handles scaling, identity, observability, and lifecycle. This is the path for a team that has outgrown Copilot Studio’s fixed orchestrator but does not want to operate a 24/7 host.

Gate 4 - What is your channel and protocol requirement? If you need to reach the most surfaces (partner apps, mobile, arbitrary websites, the widest reach of the three) the Agents SDK reaches furthest. If you need custom protocols (webhooks, voice, AG-UI), background or async behavior, or agent-to-agent delegation, Foundry Hosted or self-hosted SDK beat Copilot Studio, which is strongest at connector-driven, conversational, in-Microsoft-365 scenarios. If your target is Microsoft 365 Copilot and Teams specifically, all three reach there, so this gate does not decide it; fall back to Gates 1 through 3.

For an enterprise platform plan, two trade-offs sit underneath these gates. The first is effort versus control: lowest effort and least pro-code control with Copilot Studio, managed code on Microsoft-run infrastructure with Foundry Hosted, and highest control with full ownership of compute on the self-hosted SDK. The second is maturity. Copilot Studio is GA. Foundry Hosted agents are public preview, and the Microsoft Agent Framework is public preview. For a workload you are putting into production this quarter, weigh “GA today” against “the right long-term runtime that is still in preview” honestly, and design the migration path either way.

Identity and governance: where the paths quietly differ

Identity is the dimension most teams underweight and then regret. All three paths get an Entra agent identity, but how much you control it differs.

Copilot Studio takes the automatic route with no override. Agents created in Copilot Studio can be configured to automatically receive a Microsoft Entra agent identity, an Entra service principal with an “Agent” subtype, when enabled at the Power Platform environment level. The constraint to note: Copilot Studio requires automatic management and does not allow bringing your own Agent ID or app registration. If your security model depends on pre-provisioning specific app registrations, that is a real limitation.

Foundry Hosted agents also automate identity but expose more of it to your code. Every Hosted agent gets its own dedicated Microsoft Entra agent identity and dedicated endpoint, both created automatically at deploy time. When integrated via Microsoft 365 channels it can use OAuth 2.0 On-Behalf-Of for user-invoked scenarios or its own agent identity for autonomous or background scenarios. Foundry agent identities support both attended (OBO, delegated) and unattended (client-credentials, application-only) authentication, with an automatic multi-step OAuth token exchange between Agent Service, Entra ID, and the downstream resource. The tools that currently support agent-identity authentication are MCP and Agent-to-Agent. That attended/unattended split is the architecturally important part: it is what lets one Hosted agent act as a user in a chat and as itself in a background job.

On the governance surface, the platforms diverge by design. Copilot Studio agents are governed through the Power Platform admin center with environment-level data loss prevention, role-based access, auditing, connector governance, ALM across dev/test/prod, and compliance via Microsoft Purview; publishing to an organization’s app catalog requires admin approval. Foundry’s enterprise capabilities, by contrast, include dedicated Entra agent identity, private networking, Azure RBAC, content safety guardrails that mitigate prompt injection including cross-prompt injection (XPIA), end-to-end tracing with Application Insights, and publishing to Microsoft 365 Copilot, Teams, and the Entra Agent Registry. Same destination inventory, different control planes.

One more useful convergence point: Copilot Studio custom engine agents integrate automatically with Agent 365 - an Agent ID is created automatically, the agent appears in the agent registry automatically, agents are pre-approved via Power Platform admin policies, and telemetry flows to the Agent 365 observability backend automatically. If you want the lowest-friction path to a governed, registered, observable agent, the low-code option does that wiring for you. The pro-code paths give you more control and ask you to wire more yourself.

Extensibility: tools and MCP across the three

Tooling is where the platforms feel most different day to day.

Copilot Studio extends agents through Power Platform connectors (hundreds of prebuilt plus custom/REST connectors), agent flows, and Model Context Protocol servers. Each connected MCP server appears as a tool offering its MCP tools and resources. Two details matter for governance: using MCP requires turning on generative orchestration, and MCP connectivity rides on Power Platform connectors, so the same DLP data policies that regulate connectors also regulate MCP access. That is a feature, not a bug, for a regulated org: your existing connector governance automatically covers your agent’s MCP tools.

Foundry Hosted agents take the opposite stance: nothing is automatic, everything is explicit. Tools come through the Toolbox MCP endpoint and you consume them with standard MCP client libraries. That is more setup and more control. It also means your tool layer is portable, since it speaks plain MCP rather than a platform-specific connector model.

The Agents SDK leaves tools entirely to you. You bring your own, and the Teams SDK v2 adds A2A and MCP while the Agent Framework adds graph-based multi-agent workflows. If your agent’s value is a bespoke set of internal tools that no connector covers, the SDK and Foundry Hosted both let you build them; Copilot Studio asks you to wrap them as connectors first.

This maps onto a pattern worth internalizing if you are building agents that should survive a vendor rotation: keeping tools and orchestration portable is exactly the discipline behind LLM-agnostic agent design, and the MCP-everywhere direction across all three platforms makes that easier than it was a year ago.

Where it breaks: caveats and the honest limits

Strong opinions, with the practitioner caveats attached.

Preview is preview. Foundry Hosted agents are public preview and the Microsoft Agent Framework is public preview. Limits and behaviors change. The runtime numbers in the specs list above (concurrency, idle timeout, session lifetime) are preview defaults as of mid-2026; re-check them before you size capacity, and assume the public-endpoint requirement on Azure Container Registry could shift. Just as important, no independent operational reliability signal yet exists for Hosted agents in production, so in my read you should weight this path as architectural direction, not proven reliability. Do not write a production runbook against preview numbers without a “verify current docs” line in it.

The “graduate later” path is real but not free. Yes, the same Agent Framework code can run in-process and later be repackaged as a Foundry Hosted container. That lowers the cost of starting in-process. It does not make the move a no-op: you still take on container packaging, ACR, the Toolbox MCP wiring for tools, and a different identity and networking model. Plan it as a migration with a test pass, not a checkbox.

Copilot Studio’s ceiling is real. It is the fastest path and the right one for a large class of agents. But it is weaker at deep pro-code control over API calls, orchestration, and response formatting, its pro-dev tooling (source control, CI/CD, native Git) is less integrated than the project-based Agents Toolkit, and it supports Adaptive Cards schema 1.6 and earlier. The actual “outgrows Copilot Studio” failure mode, in my experience, is not a missing feature but orchestration reliability: as the instructions and the tool catalog grow, the managed orchestrator’s behavior gets harder to keep predictable, and that ceiling shows up well before you hit any documented limit. If you can see the agent needing custom orchestration or bespoke response shaping within a year, starting low-code can become a rebuild. That is the most common expensive mistake in this decision.

Foundry’s networking has a sharp edge today. Hosted agents support BYO VNet for outbound traffic, but the container registry must currently remain reachable over its public endpoint. For a strict zero-public-endpoint mandate, that is a blocker until it changes. Confirm against current docs rather than assuming it has been lifted.

Maturity claims need dates. As of mid-2026, Copilot Studio is GA and the other two paths have preview components. Microsoft’s pace here is fast, so treat the GA/preview status as a snapshot, not a permanent fact, and re-verify before a go/no-go.

Pricing is not in scope here. Foundry Hosted agents bill on container compute during active sessions plus inference and tool usage, but the exact rates live on the Foundry pricing page rather than in the Learn docs cited here, and they were not retrieved for this article. Do not build a cost model from the qualitative description above; pull current pricing before you commit budget.

What you can reason about without rates is the shape of each cost. Copilot Studio bills on capacity or per-message, so cost tracks usage volume. Foundry Hosted is consumption on the active session and is cheap when idle because it scales to zero. The self-hosted SDK path is fixed 24/7 compute that you pay for whether the agent is busy or not, which is the operational weight behind the Gate 3 line about a team that “does not want to operate a 24/7 host.” This is the author’s framing, not a quoted price; confirm the actual numbers on the current pricing pages.

Which agent build path should you pick?

The decision is less about which platform is most capable and more about matching the service model to your team and your constraints. A maker team with a connector-shaped problem should not be writing containers. A pro-dev team with bespoke orchestration and a hard residency mandate should not be boxed into a fixed low-code orchestrator. And a team that wants its own code without running servers now has a genuine middle path that did not exist cleanly a year ago.

Run the four gates, document the answer as an architecture decision record, and note the migration path you are keeping open, because the same Agent Framework code spanning in-process and Foundry Hosted means you can defer the highest-stakes part of this call without locking yourself in. The platforms all feed one Entra agent inventory, so whichever you pick, the governance team can see it. Pick for who builds it and who runs it, not for the longest feature list.

Read Next

• Azure AI Foundry vs Azure OpenAI: The 2026 Decision - the platform-level choice that sits underneath the agent runtime decision
• Six Rules for LLM-Agnostic AI Agents on Microsoft Foundry - keeping orchestration and tools portable across all three build paths
• The Microsoft Agentic Patterns Playbook, Decoded - the orchestration patterns these runtimes execute
• Risk-Tiered Agent Governance, Annotated - how to govern the agents once they land in the shared Entra inventory
• AgentOps on Foundry: A CI/CD Reference Architecture - the deploy and observability layer for Hosted agents specifically
• AI Governance Framework for Microsoft Enterprises - the operational governance that wraps all three runtimes

If you are mapping the Foundry Hosted vs in-process vs Copilot Studio decision for an enterprise agent platform and want a second-opinion review of your gate answers before you commit, reach out.