Copilot Studio vs Microsoft Foundry: Which One, and Who Pays for What

Build in Copilot Studio when the agent is a feature of Microsoft 365: it lives in Teams, Copilot Chat, or SharePoint, it answers from your tenant's content, the people using it are employees, and a maker or analyst will own it. That is the case where a Microsoft 365 Copilot license already covers most of the runtime and the governance surfaces are the Power Platform ones you already run.

Build in Foundry when the agent is software you are shipping: your own code or framework, a model you choose and version, retrieval over data that has to stay in your own Azure resources, a customer-facing or API surface, or an orchestration loop you need to control. That is the case where you pay for ingredients by the token and the session, and you get the control that comes with that bill.

When it needs both, and it increasingly does, build the model, knowledge, and reasoning in Foundry and put Copilot Studio or the Foundry publishing path in front of it as the door into Microsoft 365. Microsoft's own adoption guidance endorses exactly that combination.

If you only remember one test: if the agent would be a line item on a Microsoft 365 renewal, it belongs in Copilot Studio; if it would be a line item on an Azure bill with a developer's name next to it, it belongs in Foundry. The mistake to avoid is picking by whichever team has capacity this quarter and discovering the billing model in month three.

The names first. Azure AI Studio became Azure AI Foundry in November 2024 and Microsoft Foundry in November 2025. The old model of a hub plus a separate Azure OpenAI resource plus separate AI Services is replaced by a single Foundry resource with child projects, and hub-based projects now live in a portal Microsoft calls Foundry (classic), which is where the new investment is not going. If your team built something in Foundry in early 2025, check which portal it lives in before you plan on it.

Foundry Agent Service went from preview to generally available and now offers three ways to run an agent: prompt agents defined by configuration, hosted agents you ship as containers on any supported framework, and ephemeral agents that live in your application code. Foundry agents can be published directly into Microsoft 365 Copilot and Teams, generally available, with your Microsoft 365 admin approving tenant-wide access. Foundry workflows are moving to code: after December 1, 2026, the visual workflow designer and in-portal workflow runs are no longer supported, though Foundry keeps running YAML workflow definitions deployed as hosted agents. Microsoft recommends the Microsoft Agent Framework for new work, so anything built in the designer has a migration on the calendar.

On the Copilot Studio side, the common currency changed from messages to Copilot Credits on September 1, 2025, with no change to pack quantity or the pay-as-you-go rate. By August 2026 Copilot Studio had split into three harnesses: a Standard harness for rule-based topics and structured workflows, a Copilot Chat harness that extends Microsoft 365 Copilot Chat with your knowledge, and a GitHub Copilot harness for reasoning-heavy, multi-step work that creates and edits Office files, uses skills and memory, and runs each task in a sandbox. The GitHub Copilot harness became generally available on September 2, 2026, and, as the billing section explains, it is billed on a different basis from the other two. Since July 2026 every new Copilot Studio agent gets a Microsoft Entra Agent ID automatically, with no environment-level opt-out.

Across both platforms, Microsoft Agent 365 became generally available on May 1, 2026, licensed per user, as the registry and control plane for agents wherever they were built. Effective July 1, 2026, the agent security capabilities for Copilot Studio and Foundry agents require an Agent 365 license; they are no longer covered by Defender for Cloud Apps or Defender for Cloud. And a Microsoft Agent Pre-Purchase Plan now lets one annual commitment pay down both Copilot Credits and Foundry usage, which tells you how Microsoft expects these two to be bought: together.

Copilot Studio is a software-as-a-service agent builder that sits inside Power Platform. You define knowledge sources, tools (connectors, workflows, MCP servers, other agents), instructions, and channels, and Microsoft runs the orchestration. Governance is the Power Platform kind: environments, data loss prevention policies, the admin center inventory, per-environment credit allocation, and now per-agent spend limits. Microsoft's own architecture guidance describes its cost as ranging "from license to consumption" depending on how much generative work you delegate to the model, which is the most useful single sentence about it.

Microsoft Foundry is a platform-as-a-service. Foundry Models is a catalog of more than ten thousand models from Microsoft, OpenAI, Anthropic, Meta, and others, with deployment types that trade data residency against price. Foundry Agent Service runs the agents. Foundry Tools (formerly Azure AI Services) and Foundry IQ (knowledge, built on Azure AI Search) supply the senses and the memory. A control plane adds tracing, evaluation, and governance. Everything is billed as Azure consumption, and you get the corresponding control: model versions, regions, provisioned capacity, private networking, and your own storage for every thread and file if you want it.

The two are no longer separated by where the agent can appear. A Foundry agent can show up in Teams and Copilot; a Copilot Studio agent can call a Foundry model or a Foundry agent. They are separated by who builds, what you control, and how you pay.

The unit is the Copilot Credit. You buy credits two ways: tenant-wide prepaid packs that replenish each month, or pay-as-you-go through an Azure subscription you link to an environment in the Power Platform admin center. Microsoft's pricing page positions pay-as-you-go as the overflow that avoids interruption when prepaid credits run out, and the alternative is worth knowing: without it, there is a grace band, and enforcement disables custom agents when a tenant reaches 125 percent of its prepaid capacity. Agent workflows are stricter; new workflow runs are blocked once prepaid capacity is exhausted even though the parent agent keeps answering.

For agents on the Standard harness there is a published rate card, and the ratios matter more than the figures. A classic, scripted answer is the base unit. A generative answer costs twice that. An agent action, such as a trigger firing or a tool call, costs five times the base. Grounding an answer in the tenant graph, meaning your Microsoft 365 content, costs ten times the base per grounding call. Workflow actions are metered in blocks of a hundred. Reasoning models add a token-based charge on top of the feature rate, and computer use is charged per step. Rates as published at the time of writing; the current table is in the Sources.

The part that decides most enterprise cases is what the Microsoft 365 Copilot license covers. For a user who holds that license, using Standard-harness or Copilot Chat-harness agents in Microsoft channels (Copilot Chat, Teams, SharePoint) for classic answers, generative answers, and tenant grounding is zero-rated, within fair-use limits. That is why an internal HR or IT agent for a licensed workforce can have close to no marginal runtime cost. The same agent published to a public website, used by contractors without the license, or grounded on behalf of external users is metered per answer. Also outside the license: computer-using agents, workflows that fire on schedules or events rather than on the agent's own call, and any model you bring from Foundry, which is billed separately on Azure.

The GitHub Copilot harness changes the basis entirely. Its agents are billed on consumption, for the model tokens, the tools (including knowledge and MCP servers), and the harness itself, and consumption starts the moment you start building: natural-language authoring, previewing, testing, and generating evaluations all draw credits, where the Standard harness bills only after publish. There is no fixed per-action rate, only ranges by task complexity, and the admin center's coverage table says it plainly: these agents are billed for all usage regardless of the user's license. The controls that come with that are per-environment credit allocation, a switch that stops an environment drawing from the tenant pool, and a per-agent monthly limit with a stop-usage option. Turn them on before the first pilot, not after the first invoice.

One more case that surprises people. Users without the Microsoft 365 Copilot add-on can still use agents in Copilot Chat. Agents that rely on instructions or public web grounding cost nothing extra; agents that reach shared tenant data such as SharePoint or connectors generate usage-based charges, metered in Copilot Credits through Copilot Studio. "We rolled the agent out to everyone" is a billing decision.

There is no charge for the Foundry resource itself, and Microsoft's pricing page states that there is no additional charge for creating or running Foundry-native prompt agents. You pay for what the agent consumes: model tokens through Foundry Models; tool meters for built-in tools such as file search storage per gigabyte per day, code interpreter per session, and web search per thousand transactions; and separate charges or licenses for the connected services, among them Logic Apps connectors, the Fabric data agent, SharePoint grounding, Grounding with Bing, and Foundry IQ through Azure AI Search. Hosted agents add container compute, billed per vCPU-hour and gigabyte-hour of memory during active sessions. If you choose the standard setup so that threads, files, and vector stores live in your own Azure Cosmos DB, Storage, and AI Search resources, those resources bill at their own rates whether or not the agent is busy. Tracing requires an Application Insights resource, so observability lands on the Azure Monitor bill, visible at the subscription rather than on the Foundry resource.

Model billing has more shapes than it did a year ago. Pay-per-token deployments come in Global, Data Zone, and Standard (regional) flavors, which is a data-residency choice with a price attached. Provisioned throughput bills on deployed capacity by the hour whether or not you use it; provisioned deployments cannot be paused, billing stops only when the deployment is deleted, and reservations of one month or one year discount the hourly rate. Batch deployments cut the token price in half in exchange for a twenty-four-hour turnaround. Fine-tuned models are charged three ways, training, an hourly hosting fee that applies even when the model is idle, and inference. Models sold directly by Azure are billed through your subscription and covered by Azure's terms and support; models from partners and the community are Non-Microsoft Products under the Product Terms, with the provider setting the license and price through Azure Marketplace, which is how Anthropic's Claude models are sold in Foundry.

Two governance facts live in the billing. Grounding with Bing is a separate paid resource counted per tool call, and Microsoft states that data sent to it flows outside the Azure compliance and geo boundary and that the Data Protection Addendum does not apply. And SharePoint grounding in Foundry requires a Microsoft 365 Copilot license for the calling user or a metered alternative, so "we'll build it in Azure to avoid the Copilot license" does not survive contact with the SharePoint tool.

For commitment, Foundry has its own provisioned-throughput reservations, and the Microsoft Agent Pre-Purchase Plan pools Foundry and Copilot Studio usage into one annual, non-refundable commitment. Reservations apply first; the pre-purchase plan covers what is left.

Strip the rate cards away and the two platforms bill in different shapes. Copilot Studio's cost is bounded by who uses the agent and where: put a Standard-harness agent in front of licensed employees in Microsoft channels and the marginal cost is close to zero; put it in front of anyone else and it meters per answer. Foundry's cost is bounded by what the agent does per call: tokens in, tokens out, tools invoked, sessions held, and you pay that regardless of who the user is. One is predictable and hard to shape; the other is shapeable and hard to predict.

An HR policy agent for a licensed workforce in Teams is the clean Copilot Studio case. The same agent on the public careers site is a metered agent whichever platform runs it, so the decision moves from "which is cheaper" to "where should this data live and who maintains the code." An agent that reads forty-page contracts with a reasoning model, drafts a summary in Word, and files it is metered either way too: the GitHub Copilot harness charges credits for tokens, tools, and harness, and a Foundry hosted agent charges tokens plus compute. There the decision is who builds it and where it must run, not the meter.

The consequence for planning: any agent that meters needs a usage model before it needs a build. Sessions per day, turns per session, tokens per turn on the model you will actually use, tools per turn. That model is a two-hour exercise and it prevents the month-three conversation.

Seven questions, in order, because the early ones eliminate options and the late ones refine.

1. Who uses it, and do they hold a Microsoft 365 Copilot license? Licensed employees in Microsoft channels are Copilot Studio's strongest case, because the license absorbs the runtime for answers and tenant grounding. External users, unlicensed staff, and machine callers meter on either platform, so the license stops being the deciding factor and the next six questions take over.

2. Where does the agent live? Teams, Copilot Chat, and SharePoint are native to Copilot Studio and reachable from Foundry through publishing. A public website, a mobile app, a customer portal, or an API is Copilot Studio through its other channels, at credit rates, or Foundry, at token rates. If the surface is another system entirely, Foundry's protocol endpoints and hosted agents are the more natural fit.

3. Who builds it, and who maintains it in year two? Copilot Studio is built and maintained by makers with developer help; Foundry prompt agents can be built by either, and hosted agents are code you own, with the runtime, dependencies, and container lifecycle that implies. Microsoft's guidance is blunt that the host decision fixes your cost and latency envelope: a managed harness gives predictable behavior with limited control of the loop; pro-code gives full control and the cost of maintaining it. Choose the platform whose maintenance burden matches the team you will actually have.

4. What must it know, and where must that knowledge stay? Microsoft 365 content is Copilot Studio's home ground, and Foundry can reach it with the right licenses. Data that has to stay in your own storage, vector stores you control, private networking, and retrieval you tune yourself point to Foundry's standard setup with your own resources. Bing grounding takes the query outside the compliance boundary on either platform; decide that consciously.

5. How much reasoning per task, and how variable? Structured Q&A, guided conversations, and repeatable workflows suit the Standard harness and its predictable rate card. Long multi-step tasks with files and judgment suit the GitHub Copilot harness or a Foundry agent, both metered by consumption, so the choice is control rather than cost: Foundry lets you pick and pin the model, cap it with provisioned capacity, and batch what can wait.

6. What must the orchestration loop do that a harness cannot? Custom multi-agent topologies, your own framework, models Microsoft does not offer, evaluation pipelines in your CI/CD, and behaviors a harness will not allow are Foundry. If you cannot name the thing the harness prevents, stay on the harness; you will be maintaining less.

7. What does governance require, and who owns it? Copilot Studio is governed in the Power Platform admin center with environments, DLP, inventory, and credit controls, alongside the rest of your Power Platform estate. Foundry is governed with Azure role-based access, networking, the control plane, and Cost Management. Agent 365 now registers and secures agents from both, per user, and Entra Agent ID gives both kinds an identity. The question is which admin team will own the agent at two in the morning, and whether that team already runs the platform it lands on.

Microsoft has spent 2026 building bridges rather than walls, and the bridges change the answer for a lot of organizations.

Copilot Studio prompts can use models from the Foundry catalog, billed on your Azure subscription rather than in credits, with a caveat worth checking at decision time: as of this writing, the GPT-5 family and later are not supported for bring-your-own-model in prompts. Copilot Studio can also connect to a Foundry agent as a sub-agent, in preview, provided the Foundry agent was created in the new portal and has its Activity protocol endpoint enabled, which today is done through the API rather than the portal. Agents on the GitHub Copilot harness can ground on a Foundry IQ knowledge base, also in preview.

In the other direction, Foundry agents publish into Microsoft 365 Copilot and Teams, generally available. Publishing to yourself needs no approval; publishing to the organization routes to the Microsoft 365 admin center for approval and lists the agent under "Built by your org." Every Foundry agent you publish also appears in the Agent 365 registry.

Microsoft's Cloud Adoption Framework describes the hybrid outright: use Copilot Studio's low-code interface with Foundry's advanced models to handle sophisticated use cases while keeping SaaS security and reliability. Its other advice is just as practical: prototype each candidate for one to two weeks before committing. We would add: run the usage model during the prototype, because that is when the meter tells you the truth.

Signals that a Copilot Studio agent has outgrown the platform: topics and instructions are being contorted to fake a custom orchestration loop; the team needs a specific model version, region, or provisioned capacity; the data owner has asked for threads and files to live in your own storage; the credit bill is climbing with per-call reasoning you cannot shape; or most of the traffic is external and metered anyway, so the license advantage is gone.

Signals that a Foundry agent should have been a Copilot Studio one: a developer is maintaining a Teams question-and-answer bot whose only knowledge is SharePoint; every user holds a Microsoft 365 Copilot license and never leaves Microsoft channels; the backlog is content curation and permissions, not code; the Azure bill has no owner; or the agent was built in the Foundry workflow designer, which loses support on December 1, 2026.

Moving between them is a rebuild of the orchestration layer, not the knowledge. Content, permissions, and the agent's job description carry over; the harness does not.

For organizations that run Microsoft 365 and are building agents for their own people, the default is Copilot Studio: the Copilot Chat harness to extend what licensed users already have, the Standard harness for structured work with a predictable rate card, and the GitHub Copilot harness where a task's reasoning earns a consumption meter. Foundry is the default when the agent is a product, when the model or the data has requirements a harness cannot meet, or when a developer team will own it as software. The hybrid, Foundry underneath and Microsoft 365 in front, is the shape most enterprise agent programs end up in, and there is no reason to pretend otherwise at the start.

Whichever you pick, the order of work is the same one we use on the Grounded Agent Ladder: autonomy should rise only as grounding rises. An agent grounded in six versions of the leave policy will serve six leave policies on either platform, and no billing model fixes that. The permissions and content work comes first; the platform decision comes second; the build comes third.

Microsoft's own documentation for the platform and billing facts above, current as of this post's date. Rate cards, prices, and license terms move; check them at decision time.

1. Copilot Studio billing and licensing: the September 1, 2025 change from messages to Copilot Credits, and what Microsoft 365 Copilot-licensed users get without consuming credits.
2. Standard harness billing rates and management: the current rate card, the exclusions for computer use and bring-your-own models, and the 125 percent enforcement threshold.
3. Harnesses in Copilot Studio: what the Standard, Copilot Chat, and GitHub Copilot harnesses are for.
4. Copilot Credits for GitHub Copilot harness agents: consumption billing for tokens, tools, and the harness, starting at build time.
5. Manage usage for GitHub Copilot harness agents: the license coverage table, environment allocation, and per-agent limits with stop usage.
6. Copilot Studio pricing: prepaid packs, pay-as-you-go, and commit units, with current list prices.
7. Cost considerations for agents in Microsoft 365 Copilot: what users without the add-on license pay when agents reach tenant data.
8. Microsoft Agent Pre-Purchase Plan: the one-year commitment that pays for Copilot Studio and Foundry usage, and its precedence rules.
9. Transition agent security to Microsoft Agent 365: the July 1, 2026 licensing change for Copilot Studio and Foundry agent security.
10. Microsoft Agent 365 overview: general availability on May 1, 2026 and per-user licensing.
11. What is Microsoft Foundry?: the current product scope and the resource model compared with hubs and Foundry (classic).
12. Foundry Agent Service overview: prompt, hosted, and ephemeral agents and the cost model of each.
13. Foundry Agent Service pricing: no platform charge for native agents, tool meters, hosted-agent compute, and the tools with separate charges.
14. Plan and manage costs for Microsoft Foundry: paying for consumed Azure services, fine-tuning hosting, and observability costs.
15. Deployment types for Foundry Models: Global, Data Zone, and regional pay-per-token, provisioned, and batch, with the residency rules.
16. Provisioned throughput billing: billing on deployed capacity, no pausing, and reservation terms.
17. Foundry Models from partners and community: partner models as Non-Microsoft Products priced through Azure Marketplace.
18. Grounding with Bing Search tools: the separate resource, per-call counting, and the compliance-boundary statement.
19. Standard agent setup: the bring-your-own Cosmos DB, Storage, and AI Search design.
20. Publish a Foundry agent to Microsoft 365 Copilot and Teams: the publishing flow and admin approval.
21. Foundry workflows retirement: what stops on December 1, 2026 (the visual designer and in-portal runs), what keeps running (YAML workflows deployed as hosted agents), and the migration paths.
22. Connect a Copilot Studio agent to a Foundry agent: the preview, its portal requirement, and the Activity endpoint prerequisite.
23. Bring your own model for prompts: Foundry models in Copilot Studio prompts, Azure billing, and the unsupported model families.
24. Copilot Studio agent host platforms: Microsoft's own cost and control comparison of Copilot, Copilot Studio, and pro-code hosts.
25. Choose AI agent technology: the Cloud Adoption Framework decision table, the prototype advice, and the hybrid recommendation.