Microsoft Foundry vs Copilot Studio: Where to Build Your Company's AI Agents

Build in Copilot Studio when the agent serves your own staff inside Microsoft 365 and its job is to answer questions or run workflows over data your connectors already reach. Build in Microsoft Foundry when the agent is part of a product, serves customers or other systems, or needs custom code, model choice and Azure-level network and security controls. Many organizations will use both, with Copilot Studio as the front door in Teams and Microsoft 365 Copilot and Foundry handling the complex work behind it.

The choice is less about features than about operating model. These are separate products, not one inside the other. Copilot Studio is a SaaS tool in the Power Platform family, governed from the Power Platform admin center and paid for in Copilot Credits. Foundry is an Azure platform service, governed like any other Azure workload and billed on Azure consumption. Pick the platform whose operating model matches who will own the agent in two years.

How they compare

Microsoft’s own Cloud Adoption Framework technology plan for AI agents positions the two clearly. Copilot Studio is the software-as-a-service option for low-code agents built quickly by business teams. Foundry is the platform-as-a-service option for pro-code agents with deep integration, custom logic and your own choice of models.

That distinction matters more than any feature list, because it decides who carries the operational burden. A Copilot Studio agent lives in a Power Platform environment. Microsoft runs the runtime, and your makers own the logic. A Foundry agent lives in an Azure subscription. Your engineering team owns the code, the deployment pipeline, the networking and the monitoring, the same way they own any other Azure application.

Dimension	Copilot Studio	Microsoft Foundry
Primary users	Employees in Teams, Microsoft 365 Copilot and internal sites	Customers, partners, applications and back-end processes, as well as employees
Data and connectors	Power Platform connectors, SharePoint and Microsoft 365 knowledge, Dataverse	Azure data services, Azure AI Search, custom APIs, OpenAPI and MCP tools
Extensibility	Topics, agent flows, connectors, custom prompts, connected agents	Full code with SDKs and frameworks, model choice from the Foundry catalog, multi-agent orchestration
Governance	Power Platform admin center: environments, data policies for connectors, Microsoft 365 admin controls for publishing	Azure: RBAC, Azure Policy, private networking, Azure Monitor, Cost Management
Cost model	Copilot Credits via prepaid capacity packs or pay-as-you-go against an Azure subscription	Azure consumption: model tokens, tools and retrieval, hosting, logging
Who builds it	Makers and Power Platform teams with IT oversight	Software engineers and AI engineers with a CI/CD pipeline

Choose Copilot Studio when

Every user is an employee with a Microsoft 365 identity and the agent should appear where they already work. Copilot Studio is the shorter path here. Publishing to Teams and Microsoft 365 Copilot is built in, and users authenticate with the identity they already have.

The data is already reachable through a connector. Copilot Studio shines over SharePoint, Dataverse, ServiceNow, Salesforce and the rest of the Power Platform catalog, with agent flows handling the workflow around the conversation.

Your IT team already governs Power Platform. Copilot Studio agents are governed through Power Platform environments and data policies, which many IT teams already use for Power Apps and Power Automate. The skills and controls are in place before the first agent ships.

You want to test demand before investing. A department prototype in Copilot Studio is the fastest route to real user feedback at the lowest build cost.

Choose Microsoft Foundry when

The users are customers, partners or other software. Copilot Studio can publish to a website, but when the agent is a product feature with its own user interface, service levels and release cycle, you want it built and versioned like the rest of your application.

The agent needs to reach data inside a private Azure network, call internal APIs, or use a model your team has evaluated for the task. In our assessment work, the most common reason a Copilot Studio prototype moves to Foundry is a data source that sits behind a private endpoint with no connector path.

You have engineers to own it. Foundry offers portal-based prompt agents for simple cases, but production Foundry agents are typically built, tested and deployed by engineers through a pipeline. They fall under Azure landing zone controls: role assignments, policy, network isolation and logging.

Foundry is also younger in its current form than many procurement documents suggest. We covered the naming history and the SDK changes in From Azure AI Studio to Microsoft Foundry. The next-generation Foundry Agent Service reached general availability in March 2026 with private networking and production SDKs, which made it a realistic production choice for regulated clients.

Using both together

The two platforms are designed to connect. As of June 2026, Copilot Studio can connect to a Microsoft Foundry agent as a connected agent, currently in preview. The maker adds an agent, chooses Microsoft Foundry as the external agent type, supplies the Foundry project endpoint and the agent ID, and writes a description that tells the Copilot Studio orchestrator when to hand work to the Foundry agent.

The pattern this enables is practical. Employees talk to one agent in Teams or Microsoft 365 Copilot, built and maintained by a low-code team. When a request needs heavier processing, such as analysis over data in Azure or a multi-step task your engineers have built and tested, Copilot Studio delegates to the Foundry agent and returns the result. Copilot Studio can also use models deployed in Foundry for its own prompts and generative answers, billed separately from Copilot Credits.

Two cautions apply. First, the connection is a preview feature, and Microsoft states that preview features aren’t meant for production use. Plan pilots on it, not critical workloads. Second, Microsoft places responsibility for the connected agent on you, including data flows between agents, permissions and approvals, and observability. Design the identity and data boundary between the two agents before you connect them, not after.

Which platform for which use case

Use case	Recommended platform	Why
HR or policy questions for staff in Teams, grounded in SharePoint	Copilot Studio	Employee users, Microsoft 365 data, low-code maintenance by the HR or IT team
IT helpdesk agent that creates and updates tickets	Copilot Studio	Existing connectors for common service desk tools, agent flows for the workflow
Customer-facing assistant inside your web or mobile app	Foundry	Product feature with your own UI, release pipeline and monitoring
Document processing with no chat interface, such as invoice or claims intake	Foundry	Runs as a back-end process, needs code, evaluation and scale controls
Agent that queries data behind private endpoints in Azure	Foundry	Private networking and Azure RBAC on the data path
Staff-facing agent that needs a complex reasoning back end	Both	Copilot Studio front end in Teams, connected to a Foundry agent
Department prototype to test demand before investing	Copilot Studio	Fastest route to real user feedback with the lowest build cost

What drives the cost of each

Neither platform is cheaper on list price. The answer depends on usage pattern, because the two bills scale on different things.

Copilot Studio usage is metered in Copilot Credits. How many credits an interaction consumes depends on the agent design, including generative answers, tool calls and flows, as set out in Microsoft’s Copilot Studio billing rates. Licensed Microsoft 365 Copilot users can use many agent scenarios without extra charges, so for staff-facing agents used by people who already hold those licences, Copilot Studio is often the lower incremental cost.

Foundry costs follow Azure consumption: tokens per model and deployment type, retrieval and tool usage, and supporting services such as logging. Microsoft’s Foundry cost guidance notes that Azure OpenAI has no hard spending cap, so budgets and alerts in Cost Management are your guardrail. Our cost breakdown for a Microsoft 365 Copilot rollout covers the licence side of that equation.

Our recommendation

Standardize on a decision process, not a single platform. Most organizations end up with low-code agents for internal productivity and pro-code agents for products and back-end automation. For each use case we confirm who the users are, where the data lives and whether a connector reaches it, which admin team will own the agent, and what the cost driver will be at expected volume. Most use cases resolve on the first two questions. The rest go to a time-boxed prototype of one to two weeks on each platform, as the Cloud Adoption Framework recommends, and a documented decision, so teams stop building in the wrong tool.

Weight the ownership question heavily. Neither governance model is stronger in the abstract. The risk is choosing a platform your security team does not already know how to govern, and the failure modes we described in When AI Agents Go Rogue appear on both platforms when ownership is unclear.

If your teams are already building agents in both tools without a shared process, our Microsoft Foundry consulting team designs and builds pro-code agents on Azure, and our AI consulting practice in Vancouver helps leadership decide which use cases belong where. Book a consultation and we will map your agent use cases to the right platform.