Microsoft Foundry or Copilot Studio? Pick the Control Plane Before You Pick the Model

The most expensive Microsoft agent decision happens before model selection. A team chooses an authoring tool, wins approval with a polished demo, then discovers that nobody owns identity, data access, evaluation, deployment or operations after launch. I would settle those five ownership questions before comparing a single model.

Microsoft's current guidance places Foundry in the PaaS camp and Copilot Studio in the SaaS camp, with room for declarative work on both paths.[1] The company now uses Microsoft Foundry for the platform it used to call Azure AI Foundry.[6] Both can run production agents. They serve different operating teams. Teams that choose on demo speed or catalogue size miss that distinction.

Put the five owners in the design document and the on-call roster.

The naming needs one more distinction. Agent 365 has reached general availability as Microsoft's central control plane for agents, while Foundry Control Plane gives administrators fleet views, policy controls and security signals across Foundry resources and connected platforms.[4][19] Administrators can use a shared registry to improve oversight. It cannot turn two runtimes into one portable workload. Your team still inherits the operating work from its authoring choice.

The demo hides the operating model

Microsoft's own Customer Zero guidance frames Copilot Studio as configurable governance, where administrators own the risk, and Foundry as explicit governance, where the organisation owns more architecture and operating risk.[3] That is a better starting point than a feature matrix.

Copilot Studio suits a business product owner working with a Power Platform centre of excellence. Makers shape instructions, topics, knowledge and actions. Administrators set environment boundaries, connector policy, release paths and capacity. Engineering joins for custom connectors, high-risk actions and integration design. Citizen development works inside that contract. Without it, a helpful department agent becomes an unowned production system.

Foundry suits an engineering product team with Azure operations support. Developers can configure a prompt agent without application code, package a hosted agent with their own framework, or call the Responses API from another runtime.[6][7] A prompt agent in the Foundry portal does not create a citizen-development operating model. The team still needs Azure RBAC, network design, source control, release approvals, telemetry ownership and cost controls.

Copilot Studio wins when the workflow belongs in Microsoft 365

For a SharePoint knowledge agent, Copilot Studio can scope knowledge to a site or list and retrieve content on behalf of the signed-in user, so existing SharePoint permissions remain part of the answer path.[12] Power Platform data policies let administrators require authentication, restrict connectors and control publication to Teams, SharePoint, websites and other channels.[11] This gives a Microsoft 365 governance team a short route from policy to enforcement.

Microsoft manages orchestration through knowledge, topics, tools and connectors. Makers can shape the agent without inventing an agent loop. Choose this constraint when the process fits it. If the design needs custom routing logic, specialised protocols or deep application state, connector chains can hide complexity until operations inherits it.

Low code also needs release discipline. Microsoft recommends development, test and production environments, solutions for transport, and pipelines or DevOps integration. Application Insights settings, manual authentication, channel security, deployed channels and sharing need post-deployment attention because they do not all travel with a solution.[17] A maker can author the agent. A platform team still needs to run releases and operations.

Copilot Studio supports repeatable test sets, transcripts, activity maps and automated evaluation runs through APIs or Power Platform connectors.[16] Use those features before launch and after each material change. A pleasant test chat does not establish how the agent behaves under permission variants, tool failures or regression tests.

Foundry earns its overhead when behaviour is an application

Foundry gives engineers more control over models, orchestration and runtime shape. Hosted agents can use Agent Framework, LangGraph or custom code in a container, with a managed endpoint, scaling and a dedicated Entra identity. Prompt agents remove the container workload for cases that need no custom orchestration.[7] Model choice matters here, but the larger prize is control over the code around the model.

That control creates work. Engineers own dependencies, application state, custom protocols, network paths and failure handling. Security teams decide which identity acts on each resource and whether the agent uses delegated user access or its own permissions. Operations staff need traces that connect a user request to model calls, tools and downstream services.

Foundry has built-in and custom evaluators for quality, retrieval, safety and agent behaviour. It supports tracing, production monitoring and evaluation gates in CI/CD through Application Insights and OpenTelemetry integration.[8] These capabilities fit a team that already treats prompts, tools and orchestration as versioned software. A team that buys Foundry without assigning those responsibilities gets a console and an operations gap.

Microsoft 365 data needs the same design care. Foundry IQ can build permission-aware knowledge bases across SharePoint and other sources, pass the caller's Entra identity and support citations. Some Foundry IQ features have reached general availability while others remain in preview, with portal access and API version affecting the release state.[18] Check the exact path you plan to use. A proof of concept with a broad service identity does not prove safe user-level retrieval.

Deployment creates the same trade-off. Foundry can publish agents to Microsoft 365 Copilot and Teams through a bot or proxy layer, while custom applications can use managed endpoints. Copilot Studio has native publishing across Microsoft 365 Copilot, Teams, partner apps, mobile apps and custom websites.[15][7] Pick the channel after deciding who will maintain its authentication and release plumbing.

Hybrid needs an operating boundary

A hybrid works when each platform has one job. Let the Copilot Studio team own the employee conversation, approved Microsoft 365 knowledge and channel delivery. A Foundry-hosted service can handle specialised scoring, custom orchestration or a shared engineering capability behind an approved interface. Foundry IQ can also provide one governed knowledge base to both paths, subject to its release constraints.[18]

Microsoft documents connected Foundry agents for Copilot Studio's GitHub Copilot harness. That path needs the Activity protocol and project access, and its linked agent-creation guidance carries a preview label.[13] Treat feature status as a release gate. A production design can use an API or publishing path with a release state you have verified.

The boundary must name two owners. The Copilot Studio team owns conversation quality, environment policy and channel operations. The Foundry team owns service quality, code, model deployments and Azure telemetry. Both teams need shared identity mapping, an end-to-end trace and one incident route. Without them, users experience one agent while two teams each see half a failure.

Cost follows the team and the runtime

Copilot Studio measures usage in Copilot Credits through prepaid packs, prepurchase plans or pay-as-you-go billing. Capacity can pool across the tenant.[9] One interaction can trigger several meters, and bring-your-own Foundry models add separate charges. Some authenticated Microsoft 365 Copilot usage has inclusion rights with conditions and fair-use limits, so finance needs the exact channel, identity and flow design before forecasting.[10]

Foundry Agent Service charges can include inference, tools and container compute for hosted agents.[7] Search, storage, networking, monitoring and log retention can sit on other Azure meters. Microsoft recommends a representative test workload and reconciliation against resource and meter records before rollout.[14]

Compare cost per accepted business outcome. Include failed runs, evaluation, engineering time, connector maintenance, incident response and audit evidence. A cheap authoring session can produce an expensive operating year.

Three scenarios make the choice clear

HR policy guidance in Teams

Choose Copilot Studio. HR owns the policy content and response standards. The Power Platform team owns environments, data policies, test sets, release approval and credit capacity. SharePoint supplies permission-trimmed knowledge, and Teams supplies the work surface. Engineering should join if the agent starts approving exceptions or writing to case systems, because those actions change the risk boundary.

Claims triage with a custom risk engine

Choose Foundry. The insurer needs proprietary orchestration, several enterprise data sources, model comparison and integration with an existing claims application. Engineers own the agent code and model deployments. Security owns delegated access and service permissions. Operations owns traces, evaluation gates and rollback. Publishing the experience into Teams remains an option, but Teams does not remove the application lifecycle.[15]

Customer service with shared specialist services

Use both. Copilot Studio handles the customer conversation, approved knowledge and handover rules. A Foundry service handles custom document analysis that several applications need. The business team can change knowledge and escalation rules without a code release. Engineers can change the analysis service without teaching every maker about containers. Both teams need shared test cases, identity tests and a joined incident view.

Migration rebuilds operating assumptions

Do not approve either path on a promise of easy migration. Power Platform solutions move Copilot Studio artefacts between environments. They do not transform those artefacts into a hosted Foundry application.[17] A move in the other direction faces the same mismatch between custom runtime code and managed low-code orchestration.

Plan a rebuild of identity, knowledge, tools, evaluation, telemetry, channels and billing. Preserve business requirements and test evidence rather than treating the old configuration as a portable file. Run both versions against the same cases, measure the differences and keep a rollback route until the new owner accepts the service. The migration budget belongs in the initial platform decision.

My bet: shared governance, separate studios

By the end of 2027, Microsoft will make governance feel more consistent across these platforms. Agent 365, Foundry Control Plane, Entra, Purview and Defender already point towards shared inventory, identity, policy, evaluation evidence and cost oversight.[4][19] Central governance will reduce the argument over which admin centre should see an agent.

The authoring experiences will stay distinct. A business maker shaping a managed workflow has a different job from an engineer shipping a container and debugging a tool call. Microsoft gains more by joining the control planes above those jobs than by forcing both groups into one studio.

My recommendation stands: choose the operating team and its control plane first. Pick the model after that team proves it can govern, test, deploy and repair the agent.

Image: Microsoft Foundry and Copilot Studio icons from Microsoft's Azure architecture and Power Platform icon collections. Microsoft permits their use in architecture diagrams, training materials and documentation. The composition adds labels and a neutral background without changing the icons.

Sources: [1] Technology plan for AI agents (Microsoft, 2026); [3] Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry (Microsoft, 2026); [4] Agents hub - Start here for agentic computing at Microsoft (Microsoft, 2026); [6] What is Microsoft Foundry? (Microsoft, 2026); [7] What is Microsoft Foundry Agent Service? (Microsoft, 2026); [8] Observability in generative AI (Microsoft, 2026); [9] Standard harness licensing (Microsoft, 2026); [10] Billing rates and management (Microsoft, 2026); [11] Configure data policies for agents (Microsoft, 2026); [12] Add SharePoint as a knowledge source (Microsoft, 2026); [13] Add a Foundry agent as a connected agent (Microsoft, 2026); [14] Plan and manage costs (Microsoft, 2026); [15] Custom engine agents for Microsoft 365 (Microsoft, 2026); [16] About agent evaluation (Microsoft, 2026); [17] Establish an application lifecycle management strategy (Microsoft, 2026); [18] What is Foundry IQ? (Microsoft, 2026); [19] Microsoft Foundry Control Plane (Microsoft, 2026)

Connect with me on LinkedIn.

A note on the process: I used AI to help with research, drafting and editing. I checked factual claims against Microsoft documentation on 9 November 2026. I did not run tenant-side tests.