Copilot Studio or Microsoft Foundry? Pick the host, not the tool.

What's the difference between Copilot Studio and Microsoft Foundry?

Copilot Studio is a low-code environment for departmental agents, governed through the Power Platform admin center. Microsoft Foundry is a pro-code Azure platform that gives you the whole orchestration loop and more than 10,000 models. Copilot Studio gets you to production faster; Foundry gives you control you will eventually need if the agent is doing real work.

Most comparisons stop there, and that is where they go wrong. The more useful question is not which tool you author in. It is which host the agent runs on, because the host decides the orchestration, the model access, and the operating cost. Microsoft says this plainly: keep the host decision separate from the authoring method (Choice of agent host).

The same authoring canvas can target different hosts and produce different quality and cost. So pick the host first.

Wait, is it Azure AI Foundry or Microsoft Foundry?

Microsoft Foundry. It is the current name for what was Azure AI Foundry, and before that Azure AI Studio.

This trips up more conversations than it should, because most articles written in the last two years still say Azure AI Foundry. Microsoft documents the change directly in What is Microsoft Foundry, along with several renames that travel with it:

• Azure AI Studio / Azure AI Foundry is now Microsoft Foundry.
• Azure AI Services is now Foundry Tools.
• The Assistants API (Agents v0.5 and v1) is now the Responses API (Agents v2), with terminology moving from Threads, Messages, Runs and Assistants to Conversations, Items, Responses and Agent Versions.
• The RBAC roles were renamed to Foundry User, Foundry Owner, Foundry Account Owner and Foundry Project Manager. Role IDs and permissions did not change.
• The old hub-plus-Azure-OpenAI-plus-AI-Services resource model collapsed into a single Foundry resource with projects.

One date worth putting in your calendar: agents built on the classic experience are deprecated and scheduled for retirement on 31 March 2027. If you have something in production on the classic Agents API, the migration is real work and the clock is running.

The three-way decision table

This is the framework we walk clients through. Read it top to bottom and the answer is usually obvious by the fourth row.

Scroll the table sideways to see all three columns.

Owner, host, governance, model access and cost model are Microsoft's, from the agent host guidance and the Microsoft 365 Copilot and Copilot Studio comparison. Build effort, complexity ceiling and maintenance effort are ArchitectNow's own guidance from delivered engagements, not Microsoft figures. Treat them as planning ranges.

When is Copilot Studio the right call?

When a department needs an agent doing real multi-step work, and the people who understand the process are closer to the problem than your engineers are.

• Customer support agents that open tickets and escalate to a human.
• IT help desk triage that routes requests to the right team.
• Sales assistants that pull CRM data, take notes, or start an approval.

It also wins on governance for this tier of work. Environment-level DLP, connector control, role-based access, and publishing approval all run through the Power Platform admin center, which means the agent inherits a control plane your admins already operate. That is worth more than it sounds. The failure mode with agent sprawl is not a bad agent, it is forty agents nobody can inventory.

When is Microsoft Foundry the right call?

When you need the orchestration loop itself: how many model turns happen, which model handles which step, what gets cached, and what the trace looks like afterwards.

In practice that means one of four things. The agent reaches data that does not live in Microsoft 365. Multiple specialist agents need a supervisor coordinating them. You need model choice, including non-Microsoft models. Or the thing is customer-facing and the quality bar means you have to be able to evaluate and tune it properly.

The cost of that control is maintenance. Foundry is an engineering asset with an engineering lifecycle: source control, CI/CD, evaluation sets, real observability. Teams that pick it for the ceiling and staff it like a low-code project are the ones who end up unhappy, and it is worth being blunt about that before the decision rather than after.

What about Microsoft 365 Copilot agents?

The option most comparisons skip, and often the correct answer.

Declarative agents built in Microsoft 365 Copilot answer questions from content you already have, respect the permissions already in place, and take under a day. A project FAQ agent over SharePoint, an onboarding agent over an internal knowledge base, a product documentation assistant. No code, no new governance surface, no new bill.

A meaningful share of the agent ideas that arrive framed as a Foundry project are actually this. Test the cheap host first. If it cannot do the job you will find out in a day, and that day is the cheapest requirements-gathering you will ever run.

How do the cost models actually differ?

Licenses and tokens are the visible difference. The orchestrator is the one that decides your bill.

Microsoft's own framing is that two agents can return identical answers and differ by an order of magnitude in cost, because cost follows how the agent runs rather than what it returns. Four levers drive it: tokens consumed per interaction, how many model turns the orchestrator takes, which model handles each step, and how much of the work is deterministic enough to move out of the model entirely.

That is why the host choice is a cost decision, not just a capability one. Microsoft 365 Copilot gives you a managed orchestrator and a predictable bill with little control. Copilot Studio moves along that line as you delegate more to generative orchestration. Foundry hands you every lever, including the ones that let you spend a great deal of money quickly.

Standing context is the one that surprises people. Every instruction, knowledge snippet and tool definition loaded on a turn is billed on that turn, whether or not it was relevant. An agent with a generous system prompt and twelve tools attached pays for all of it on every single interaction.

Can you use more than one?

Most organizations past their first few agents end up on all three, and that is the healthy outcome rather than a failure of standardization.

The pattern that holds up: Microsoft 365 Copilot for knowledge and Q&A over content people already have access to. Copilot Studio for departmental process agents with real workflow. Foundry for the small number that need deep control, custom models, or supervisor and task agent orchestration across enterprise systems.

What does need standardizing is the layer underneath: identity through Microsoft Entra ID, data governance through Microsoft Purview, an inventory of what exists, and one place to see what agents are doing. Picking a single build platform is not a governance strategy. Knowing what is running is.