Microsoft Copilot Studio is the Microsoft 365 workshop for building, publishing and governing AI agents connected to your organization’s data, without building an engine. Microsoft Foundry, formerly Azure AI Foundry, is the Azure platform for building custom engine agents, with model selection, customized indexing and explicit orchestration.
The verdict fits in three sentences. Copilot Studio when the need lives inside Microsoft 365 and the value comes from your data and your processes. Microsoft Foundry when the scenario goes beyond the workshop: a specific engine, model or orchestration. In many projects the two coexist, Copilot Studio as the front end in Microsoft Teams and Foundry behind it.
This article compares both platforms across ten criteria, settles three common scenarios and describes the mixed architecture we meet most often in large organizations. If the notion of an agent is still unclear in your organization, start with our definition of what an AI agent is. The choice is made use case by use case, not once and for all.
Microsoft Copilot Studio: the agent workshop built into Microsoft 365
Copilot Studio is a graphical workshop. You describe an agent through its topics, actions and instructions, you point it at its knowledge sources, and the platform handles understanding the request, searching the sources and phrasing the answer. That is the principle of the declarative agent: no engine to write, no orchestration chain to code, no index to maintain. A business profile or a Power Platform maker, supported by a Microsoft 365 architect, produces a first usable agent. For the definition of the object itself, see what is a Copilot agent.
Agents live where your people already work. Publishing targets Microsoft Teams, Microsoft 365 Copilot Chat, a web channel or a SharePoint site. That proximity weighs heavily on real usage: the agent sits one click from the current conversation, not behind another address to remember.
On the data side, the agent connects to SharePoint and website knowledge sources, to Dataverse tables, and to the Power Platform connectors that open access to Dynamics 365 and line-of-business applications. Microsoft Graph supplies the user context. The decisive point for an IT department: queries run with the user’s identity, so SharePoint permissions apply natively, with nothing to rebuild.
- Building: topics, actions, instructions and knowledge sources, in a graphical interface.
- Publishing: Microsoft Teams, Microsoft 365 Copilot Chat, web channel, SharePoint site.
- Data: SharePoint, Dataverse, Power Platform connectors, Dynamics 365, Microsoft Graph.
- Consumption: agent usage is billed in Copilot Studio credits, pay as you go or in capacity packs; what a Microsoft 365 Copilot license covers depends on the publishing channel, so check it against your Microsoft agreement and on the Microsoft Copilot Studio pricing page.
- Governance: Copilot Studio agents are provisioned in a Power Platform environment, which relies on Dataverse, and are managed from the admin center, with an agent inventory.
Microsoft Foundry, formerly Azure AI Foundry: the platform for custom agents
Microsoft Foundry, formerly Azure AI Foundry, is the Azure environment where a technical team designs an agent end to end. Nothing is declarative here: you choose the model, you write the orchestration, you decide how documents are chunked, indexed and returned. This is the platform for custom engine agents, and the Microsoft Foundry documentation describes its full scope.
The first contribution is the model catalog: you compare OpenAI, Mistral and open models on your own test sets, and you switch between them use case by use case rather than for the whole organization. The second is control over the document engine: chunking, metadata enrichment, indexing in Azure AI Search, guardrails and systematic evaluation of answers.
The tooling follows the same code-first logic: the Agent SDK and Semantic Kernel, Microsoft’s open source orchestration library, the MCP protocol to expose tools to an agent, and the Microsoft Foundry agent service to host execution. The economics change nature too: you pay Azure consumption, tokens, indexing, compute and storage, inside your own subscriptions and regions.
- Model catalog: comparison and switching model by model, depending on the use case.
- Document engine: chunking, enrichment and indexing under your control, Azure AI Search.
- Orchestration: Agent SDK, Semantic Kernel, MCP, the Microsoft Foundry agent service.
- Execution: your Azure subscriptions, your regions, your network and your keys.
- Cost: Azure consumption, tokens, indexing, compute, storage.
The trade-off deserves to be stated plainly. Everything that is native in Copilot Studio becomes design work in Foundry: propagating the user’s identity, honoring SharePoint permissions, publishing into Microsoft Teams and governing the agents functionally. This is not a weakness of the platform, it is the price of control.
Copilot Studio vs Microsoft Foundry: the 10-criteria comparison
The table below lists the ten criteria that decide the call in our scoping workshops. Read it criterion by criterion, with no winning column.
On mobile, swipe the table to the left to see the Microsoft Foundry column.
| Criterion | Microsoft Copilot Studio | Microsoft Foundry |
|---|---|---|
| 1. Build model | Graphical workshop, topics, actions and instructions, declarative agents, publishing in a few clicks | Engine development, code and SDK, orchestration written and versioned |
| 2. Skills required | Business team or Power Platform maker, supported by an M365 architect | .NET or Python developers, an AI architect, continuous deployment practices |
| 3. Available models | Built-in Microsoft models, few settings | Azure model catalog, including Mistral via Azure AI Foundry, and Claude via the Anthropic API, comparable use case by use case |
| 4. Data connection and RAG | SharePoint and website knowledge sources, Dataverse, Power Platform connectors, Microsoft Graph | Customized indexing, Azure AI Search, document chunking and enrichment controlled end to end |
| 5. Permissions and identity | Queries run with the user's identity, SharePoint permissions honored natively, Microsoft Purview labels | To be designed: Microsoft Entra ID identity propagation and index filtering by entitlement, owned by the project |
| 6. Hosting and data residency | Power Platform environment in your Microsoft 365 tenant, region chosen at creation | Your Azure subscriptions, your regions, network and keys under your control |
| 7. Cost model | Copilot Studio credits, pay as you go or capacity packs, on top of Microsoft 365 licenses | Azure consumption: tokens, indexing, compute, storage |
| 8. Governance and monitoring | Power Platform admin center, data policies, agent inventory, cross-platform management with Agent 365 | Your Azure tooling for technical monitoring, functional agent governance still to be built |
| 9. Time to the first agent in production | 6 to 12 weeks, 2 to 4 for scoping then 4 to 8 for the build | Depends on scope, to be assessed |
| 10. When to choose it | The need lives inside Microsoft 365 and the value comes from your data and your processes | The need goes beyond the workshop: a specific engine, model or orchestration |
Neither platform is better than the other. They answer two different questions: where the agent lives, and who writes its engine. On criterion 6, the compliance framework is handled the same way in both cases and documented with you, hosting in Europe and Switzerland, ISO/IEC 27001:2022 certification: see security and compliance for your agents.
The short version, with AI Desk Pro as a third option, is on our Copilot Studio and Microsoft Foundry partner page.
Unsure about one specific use case? We settle it in a single scoping session.
Three scenarios and the platform we recommend
An HR or IT question and answer agent on SharePoint
Employees keep asking the same questions about leave, benefits, resetting an access or the software catalog. The answers already exist, scattered across SharePoint documents nobody opens.
Our recommendation: Copilot Studio. The source of truth is already in SharePoint, permissions apply with the user’s identity, and publishing into Microsoft Teams is immediate. Nothing to build on the engine side, so nothing to maintain. This type of HR agent, like the one deployed at France Televisions, reaches 95% adoption and has saved 7 months of HR work.
If you have no internal team to maintain the agent and the need is standard IT or HR support, a ready-to-deploy product such as AI Desk Pro answers the same need without a development project.
Watch out for: the freshness of the sources. An agent plugged into a SharePoint library that is never cleaned up returns outdated answers with the same confidence as accurate ones.
A sales agent connected to Dynamics 365 and Dataverse
Sales teams spend their days between the CRM and Microsoft Teams. They want to prepare a meeting, retrieve an account history and draft a proposal without switching tools.
Our recommendation: Copilot Studio, with a Foundry engine only if you need control over the model or over proprietary scoring logic. Connectors to Dynamics 365 and Dataverse are native, actions write back into the CRM, and the agent is published where the sales force works. At GroupeActive, drafting a sales proposal went from a full day to two hours, a 75% saving in drafting time, as described in the customer story published by Microsoft.
Watch out for: credit consumption once the agent is used daily by the whole sales force. The cost model has to be verified before the general rollout, not after.
A multi-step engine with document processing and several models
You need to extract data from contracts or case files, classify it, chain several processing steps and compare how several models behave before settling on one.
Our recommendation: Microsoft Foundry. Document extraction and classification, chained steps, comparative model evaluation and control over the index go beyond what a declarative workshop can do. You need to write the orchestration, not configure it.
Watch out for: Microsoft Entra ID entitlement propagation and monitoring, which are not provided by default and must enter the project scope from the scoping phase.
When to combine both: Copilot Studio in front, Microsoft Foundry behind
This is the most frequent pattern among the large organizations we support. The user talks to a Copilot Studio agent published in Microsoft Teams or in Microsoft 365 Copilot Chat. That agent calls a Microsoft Foundry engine through a custom connector or an MCP server exposing the engine. The experience, the identity and the permissions stay on the Microsoft 365 side; the complexity, the models and the orchestration stay on the Azure side.
This split has three practical consequences. Multi-agent orchestration is written once, with the Agent SDK and Semantic Kernel, then reused behind several front ends. Each agent receives an identity in Microsoft Entra ID: you grant it rights, trace its actions and revoke it like a service account. Microsoft Purview labels keep applying to the content it handles. Finally, managing agents across platforms, inventory, owners, access and costs, is handled with Agent 365.
There is no extra platform to buy: everything stays inside the Microsoft estate your teams already administer. Scoping this kind of architecture falls within the Microsoft Copilot Frontier Program, which can fund up to 50 days of service.
Five mistakes we see in agent projects
- Choosing the platform before writing the use case and identifying the source of truth. Consequence: the architecture is locked before the business question is asked, and gets paid for in rework.
- Going to Foundry for a question and answer need on SharePoint. Consequence: the team rebuilds by hand the permissions and identity propagation that Copilot Studio provides natively.
- Staying on Copilot Studio for heavy multi-step document processing. Consequence: response times and credit consumption drift, noticed in production rather than during scoping.
- Forgetting the running cost. Consequence: nobody monitors answer quality, sources age and no owner is identified.
- Letting every team publish agents with no inventory and no naming rule. Consequence: ownerless agents inside the tenant, which the IT department discovers during an audit.
These trade-offs belong in a scoping phase. That is the purpose of our Copilot Factory offering: use cases, platform, governance and skills transfer.
Frequently asked questions about Copilot Studio and Microsoft Foundry
No, Copilot Studio is subscribed to independently of Microsoft 365 Copilot. Agent usage is billed in Copilot Studio credits, pay as you go or in capacity packs. What a Microsoft 365 Copilot license covers depends on the publishing channel, so check it against your Microsoft agreement. Witivio settles that trade-off with your IT department before the build.
Yes, but not in the same way. A Foundry agent is exposed through an API and sits behind a front end: a Copilot Studio agent published in Teams, or a dedicated Teams application. This is the pattern Witivio puts in place most often, the experience and the permissions on the Microsoft 365 side, the engine on the Azure side.
The two models cannot be compared line by line. Copilot Studio bills credits per interaction, on top of your Microsoft 365 licenses. Foundry bills Azure consumption: tokens, indexing, compute, storage. At moderate usage and for a standard use case, Copilot Studio is generally cheaper; at high volume or with heavy processing, the trade-off is made use case by use case. Witivio prices both during scoping.
Model choice is not what Copilot Studio is for, since it relies on the built-in Microsoft models. To choose between models you have to go through Microsoft Foundry: Mistral via Azure AI Foundry, Claude via the Anthropic API, with your explicit consent. Witivio takes that route when the use case justifies real control over the model.
A Copilot Studio agent is provisioned in a Power Platform environment, which relies on Dataverse. Your teams do not need to be Power Platform developers to use it, but your IT department has to decide on environments, data policies and publishing rights. Witivio sets that framework during scoping, before the first agent.
Agent 365 replaces neither Copilot Studio nor Microsoft Foundry: it is the management layer for agents, whichever platform produced them. Inventory, owners, access, costs and compliance. That is what prevents ownerless agents from spreading inside the tenant. Witivio puts that framework in place with Agent 365.