DEV Community: Holger Imbery

Copilot Managed Runtime: The Runtime Becomes the Governance Boundary

Holger Imbery — Sat, 24 Oct 2026 00:00:00 +0000

Microsoft now runs the code that Copilot, Copilot Studio, and third-party AI tools produce, inside your Microsoft 365 tenant. I think that is the right answer to a problem we can no longer solve at the build side. But a runtime is only as good as the policies behind it, and this one sits on top of the Power Platform estate you already have, with its environments, DLP, and routing rules. This article explains what was announced, where I would place it, and what I would set up in the next 90 days.

Introduction: the tracker that 200 people now depend on

Every enterprise I work with has a version of this story. Someone in operations gets tired of a shared Excel file. They build a small tracker in an afternoon. It works. They share the link in a Teams channel. Three weeks later, 200 colleagues depend on it, it talks to a SharePoint list and a line-of-business system, and nobody in IT knows it exists. The owner is going on parental leave next month.

Five years ago that tracker was a canvas app, and the Power Platform CoE had at least a fighting chance to find it. Today the same person can describe the tracker in a chat and get working code back. Soon an agent may build it unasked.

That is the context for Microsoft Copilot Managed Runtime. My thesis is simple. Copilot Managed Runtime shifts enterprise governance from the tools people build with to the place their code runs. That is the right move, because we can no longer control who builds apps with AI. But the runtime is only as good as the policies behind it, and it arrives on top of an existing Power Platform estate. Architects should treat it as a landing zone to design deliberately, before the first AI-built app goes viral.

What Microsoft announced, and what it did not

On 25 September 2026, Microsoft put Copilot Managed Runtime into public preview. The Copilot blog announcement describes it as a platform “to run code within the Microsoft 365 tenant boundary that’s governed by IT.” According to the same post, it already powers the apps built in Copilot Cowork, Copilot Code, and Copilot Studio. Microsoft is also opening it to third-party tools and professional developers. Lovable is the named third-party example.

For developers, the way in is an SDK (@microsoft/managed-apps) and a CLI (@microsoft/managed-apps-cli) invoked as ms. The SDK overview on Microsoft Learn lists the documented capabilities:

Microsoft Entra authentication and authorization out of the box
More than 1,500 connectors, callable from JavaScript and TypeScript
A native Git inner loop, with either a platform-managed repository or your own GitHub repository (owned by an organization on GitHub Enterprise Cloud)
Adherence to sharing limits, Conditional Access, Advanced Connector Policies, and Data Loss Prevention
A GitHub Copilot plugin for coding agents
A central inventory in the Microsoft 365 admin center ( Apps > All apps ), with usage analytics and health metrics with alerting

Users open their apps at managedapps.cloud.microsoft. The overview page now lists four build paths: Cowork, Copilot Studio, Copilot Code, and the SDK with its CLI. All four produce an app that inherits the tenant’s default governance policy: approved connectors, sharing rules, and content security policy.

One detail was easy to miss at launch and matters a lot: there is a Power Platform environment behind every app. According to the admin FAQ, apps are created in personal developer environments, and environment routing creates those environments for makers. They are always managed environments. Each one sits in an environment group, and that group carries the connector, sharing, and content security rules. Most of the governance discussion below comes back to this.

Licensing. Users need either a Power Apps Premium license or Copilot Credits to run an app. The licensing FAQ is now clear on how credits are counted. The runtime measures usage in API calls. Launching an app, reading or writing data through a connector, and publishing an app each count as an API call, and each call costs 0.1 credits. Specialized services such as Work IQ APIs are charged separately at their own rates. The October 2026 Copilot Credits Guide lists pay-as-you-go credits at $0.01 each (USD list price), so one launch costs a tenth of a cent. Users without enough credits first get a warning. During preview they are then blocked after 20 app operations or five minutes of use, whichever comes first.

Power Apps Premium is not quite “free” either. Premium users don’t consume credits when they run apps, but their API calls count toward the daily Power Platform request limits of their license, and usage above those limits is billed in credits. The Power Apps use rights that come with Microsoft 365 or Dynamics 365 licenses do not cover these apps at all.

Building and running are billed separately. Building in Cowork is charged through the maker’s Cowork spending policy in the Microsoft 365 admin center. Building in Copilot Studio is charged through Copilot Studio billing per environment in the Power Platform admin center, and billing starts during creation, not at publication. Running an app is billed per user and managed in the Microsoft 365 admin center. So the cost of one app can show up in two admin centers.

Availability. All eligible commercial tenants get the runtime automatically, and no admin action is needed. But each creation path has its own default. According to the admin overview, Copilot Studio app creation is on by default, CLI app creation is off by default and has to be enabled per environment or environment group, and Cowork app building depends on the tenant being onboarded to the Frontier program.

Repositories. The repository type is chosen when an app is created and cannot be changed later. If you bring your own repository, it must be owned by an organization on GitHub Enterprise Cloud, on github.com or a ghe.com data residency host. Personal accounts, GitHub Enterprise Server, and other providers such as Azure DevOps are not supported. Repository visibility is not set in the runtime. You manage it with GitHub Enterprise Cloud repository policies.

On the same day, Microsoft launched the new Copilot with Home, Code, and Autopilot. It split pricing into a user subscription for everyday AI and usage-based billing for Cowork, Code, Autopilot, and frontier models. Microsoft said cost management in Agent 365 would expand to cover Code and Copilot Managed Runtime, with Copilot Studio agents planned for October. A week earlier, on 17 September, the Power Platform September update made the model app-builder skill and the canvas authoring agent plugin (with MCP support) generally available.

Everything above about the runtime is preview. Microsoft Learn marks it as prerelease documentation subject to change, and the Copilot Credits Guide lists it as a paid public preview, so usage is billed even though the product is not generally available. The Cowork build path also requires the Frontier program. Do not bet production workloads on today’s details.

When I started this article, two of my biggest questions were the credit cost of a launch and how existing Power Platform DLP applies. Microsoft has since documented both. What it still has not documented is an export path to another platform, what happens to an app when its owner leaves, and which events reach Microsoft Purview. I come back to those below.

Why it matters: governing the runtime instead of the builder

For about a decade, citizen-development governance has worked on the build side. We controlled who got a maker license, which environments existed, which connectors a maker could combine, and which templates people started from. That model assumed building was the hard part, done in a small number of tools we owned.

That assumption is gone. A business user can now produce an app in Cowork, in Copilot Studio, in Lovable, or with a coding agent in Visual Studio Code. You cannot put a gate in front of every one of those tools. Trying to do so creates the shadow IT you wanted to prevent.

The runtime is the one place all of those paths converge. Identity, connectors, sharing, and inventory are enforced there, regardless of who wrote the code. Microsoft frames it as “central governance should not require centralized creation.” I agree with that sentence. It is overdue.

I’d push back on the next step in Microsoft’s argument, though. The blog says enterprise readiness “becomes the default path.” A default is not readiness. A default policy decides which connectors an app may call. It does not decide who supports the app at 8 a.m. on a Monday, whether the data model will survive a second department, or what happens when the owner leaves. The runtime removes the platform work. It does not remove the operating model work, and that is the part most customers underinvest in.

What gets better: one inventory across build tools, Entra sign-in everywhere, real Git history instead of opaque app packages, and a policy layer that applies to code you did not write. What gets harder: a new kind of app now lives in your Power Platform environment groups but is governed from the Microsoft 365 admin center, with its own licensing logic. Two admin centers share one set of rules. That overlap is the architect’s problem, not Microsoft’s.

Architecture implications: where an app should live

The first question in every workshop will be: should this app run in Copilot Managed Runtime, in Power Apps, or in Azure? There are clear criteria.

Criterion	Managed Runtime	Power Apps	Azure
Audience size	Team to department	Department to enterprise	Enterprise or external
Data sources	Connectors, Graph, SharePoint	Dataverse plus connectors	Anything, you build it
Dataverse	Through the Dataverse connector	Native	Via API
Licensing you own	Premium or credits	Premium already paid	Azure consumption
ALM maturity	Git, own repos on GitHub Enterprise Cloud only	Solutions, pipelines	Full DevOps
Expected lifetime	Weeks to months	Years	Years
Pro-dev ownership	Optional	Optional	Required

I read the table like this. Managed Runtime is the right default for small, AI-built, connector-backed tools with a limited audience and an uncertain future. Power Apps stays the home for apps that need a real Dataverse data model, security roles, business process flows, and the solution-based ALM that many enterprises have spent years building. Azure remains the answer when you need custom infrastructure, external users, or an engineering team that owns the service end to end.

Connectors. The 1,500+ connectors are the headline, but the defaults are much tighter. The default governance settings allow 18 Microsoft first-party connectors that authenticate only through Entra ID, plus 12 Microsoft MCP servers. Third-party, custom, and preview connectors are excluded. Even on allowed connectors, actions that open the door wide, such as “Send an HTTP request”, Office Scripts, or freeform DAX queries in Power BI, are blocked by default. That is a sensible starting point. The risk now sits in two places: when you widen the list, and in tenants that already have environment groups and data policies (more on that below). If you switch the connector policy to full control, Microsoft stops adding new connectors automatically, and the list is yours to maintain from then on.

Git and versioning. The Git inner loop is a real improvement over what most citizen-built apps ever had. Builds and deploys come from real commits, and bring-your-own GitHub means branch policies and pull-request reviews still apply. But the repository choice is permanent per app, your own repositories must sit in a GitHub Enterprise Cloud organization, and Azure DevOps is not supported. Decide the repository pattern before people start creating apps, not after. There is also a setting that allows developers to deploy artifacts built outside Microsoft’s build system. It is off by default. Keep it off unless you have a build pipeline you trust, because the supply-chain checks then become your job.

When an app outgrows the runtime. This is the question I would ask Microsoft first. The blog describes a developer pulling code down and continuing to build without standing up a separate runtime. That covers growth in code. It does not cover growth in audience, data volume, or criticality. I have seen too many “temporary” tools become business-critical to accept “we’ll move it later” as a plan. Because the code is a TypeScript or JavaScript single-page app in Git, moving to Azure is at least technically plausible. Moving to Power Apps is not documented. A Power Apps code app looks like the closest target, but until Microsoft describes a path, I would plan for a rebuild. Treat that as a design input, not a surprise.

Power Platform is also moving toward code. Microsoft Learn already has guidance on converting a vibe app to a Power Apps code app, and the model app-builder skill now builds Dataverse artifacts from natural language. The overlap between the two platforms will grow before it shrinks.

Governance implications: the default policy is the real control

Because the runtime is on automatically, and Copilot Studio app creation is on by default, the default governance policy is not a setting you will get to eventually. It is the control that already applies to every app built today. The defaults live in a default environment group, which you find in the Microsoft 365 admin center under Apps > Settings > Environment groups. It has four rules: routing, connectors and MCP servers, sharing, and content security policy. Review them this week.

Some routing decisions cannot be undone. The service initializes Copilot Managed Runtime governance when the first app is created, or earlier when an administrator opens the app governance experience. After that, an existing “Everyone” catch-all routing rule can no longer be deleted or changed, and the routing rule created for the runtime is permanent. Makers who match no routing rule cannot create apps at all. Plan your routing in the Power Platform admin center first. If someone in Copilot Studio has already built an app, governance is already initialized in your tenant.

Connector policy overlap. At launch I could not find how existing Power Platform DLP applies to these apps. That is now documented. For an existing environment group, it depends on two things: whether the group has an advanced connector policy (ACP), and whether the “Advanced connector policies only” switch is on.

Existing ACP	ACP only	What applies
No	Off	Classic data policies. If none applies, connectors are not restricted.
No	On	Nothing. Data policies are ignored and connectors are not restricted.
Yes	Off	Both. The most restrictive result wins.
Yes	On	Only the ACP. Data policies stay configured but are ignored.

Two of those four cases leave connectors unrestricted. There is also a display trap. For an existing group without an ACP, the Microsoft 365 admin center may report that no connectors are allowed, even when far more is possible. In mixed mode, it shows the ACP allow list but may not show restrictions from data policies. Check the effective policy in the Power Platform admin center before you tell your security team the answer.

Ownership and orphaned apps. The inventory is better than I expected. It shows the current owner (which can differ from the original creator), status, hosting region, and environment group, and Global Administrators and Power Platform Administrators can block or delete an app from there. The apps also appear in the Power Platform admin center inventory. What I still cannot find is an action to reassign ownership, or documented behavior when the owner’s account is removed. Copilot Studio has an ownership reassignment API for orphaned agents; I found nothing equivalent for runtime apps. Until Microsoft documents it, assume you need your own process.

Two smaller details belong in that process. Sharing an app does not grant access to its data; recipients still need their own permissions. And the reverse is also true: revoking someone’s access to an app does not remove their permissions on the underlying data. No single action does both.

Audit. The blog lists auditing among the organizational policies. The runtime documentation I read does not yet say which events reach Microsoft Purview, or at what level of detail. Verify before you rely on it for compliance.

Cost as a governance signal. I like the credit model more than most people will. Every launch and every connector call is a metered API call at 0.1 credits, so usage shows up as spend, and spend is something finance will actually look at. A chatty app that calls APIs in a loop becomes visible. The block after 20 operations or five minutes is a hard, early signal that a user is not licensed.

I’d push back on a common assumption here: that users with Power Apps Premium make the cost question go away. For them, normal use does not consume credits. That is good for the budget, but it also removes the signal, at least until they hit their daily request limits. For those users, use the usage analytics and the Monitor tab in the admin center instead, which show open success rate, session counts, and latency, and let you set alert rules.

One app, two places for cost. For apps built in Copilot Studio, build costs are managed per environment in the Power Platform admin center, while runtime costs are managed per user in the Microsoft 365 admin center. Microsoft also said Copilot Studio agents would come to Agent 365 cost management in October. Check that this has actually reached your tenant, and connect both views, before you publish a FinOps baseline.

The open questions I would put to Microsoft are now shorter. How do apps move to another platform when they outgrow the runtime? What happens to an app, its repository, and its connections when the owner is deprovisioned? Which runtime events reach Purview? When does preview end, and does the 20-operation grace period survive general availability?

Practical recommendations: the next 30 to 90 days

This is what I am recommending to customers right now, in rough order.

Decide routing before governance initializes. Look at environment routing in the Power Platform admin center now. Decide between an Everyone catch-all and security-group scoped rules, knowing that parts of this become permanent.
Review the default environment group and limit who can create. Copilot Studio app creation is on by default, and you can restrict it to specific Entra security groups. Leave CLI creation off until you have a defined developer audience. Keep external artifact deployment off.
Check the effective connector policy for existing environment groups. Look at the “Advanced connector policies only” switch and the data policies in the Power Platform admin center. Do not trust the Microsoft 365 admin center view alone.
Decide who owns the admin inventory. Apps > All apps is a new surface, but the Power Platform Administrator role already has full rights there. Give it to the team that owns the Power Platform inventory, with a weekly review and health alerts set up in Monitor.
Define a graduation path. Write down when an app must move to Power Apps or Azure: audience size, data sensitivity, need for a real Dataverse model, or business criticality.
Set the repository standard. Platform-managed Git or bring-your-own GitHub, decided centrally, because the choice cannot be changed per app later. If you bring your own, use a GitHub Enterprise Cloud organization and enforce repository visibility there.
Set up runtime billing deliberately. Users without Premium cannot run apps beyond the grace period until you turn on usage-based billing and create a spending policy for managed applications. Set per-user limits, decide whether “Auto-apply new services” (on by default) should stay on, and route credit requests into your existing approval workflow.
Check which users already hold Power Apps Premium. They run apps without consuming credits up to their request limits. The Power Apps rights included in Microsoft 365 do not count. That changes both your cost forecast and your pilot audience.
Pilot with one department. Pick one with a real backlog of small tools and a manager willing to own the outcome. Measure launches, API calls, and support requests for eight weeks.
Align with the Power Platform CoE. These apps live in Power Platform environment groups, so this is not a separate estate. Same connectors, same DLP intent, same orphaned-app process. Two governance teams with two rulebooks is the failure mode I would most like to avoid.

Conclusion: design the landing zone before the traffic arrives

I think Microsoft made the right architectural choice. You cannot govern every build tool when every employee, and soon every agent, can write code. Governing the place code runs is the only boundary that scales. Copilot Managed Runtime gives us that boundary inside Microsoft 365, with Entra, connectors, Git, and an inventory in one place.

But a boundary is not a design. The defaults are sensible but generic, the preview will change, costs are split across two admin centers, and the runtime is built on the same environments and routing rules as your Power Platform estate. Treat it as a landing zone: routing, policies, ownership, graduation rules, and cost controls, agreed before the first app gets popular.

The consequence I would plan for is not the business user with a tracker. It is Autopilot and similar agents building small tools for themselves, on the same runtime, under the same policies. When the builder is an agent with its own identity, the runtime is the only place left to govern. Better to get it right while the builders are still human.

Sources

Microsoft Copilot Blog, Build where you want, run with confidence: Now Microsoft hosts and manages the code created by Copilot, 25 September 2026: public preview, “governed by IT” wording, build experiences covered, Lovable example, admin center inventory, “central governance should not require centralized creation”, auditing listed as a policy area
Microsoft Learn, What is Microsoft Copilot Managed Runtime (preview), last updated 15 October 2026: four build paths, Frontier requirement for Cowork, inherited default governance policy, managedapps.cloud.microsoft portal, Apps > All apps
Microsoft Learn, Microsoft Copilot Managed Runtime SDK overview (preview), last updated 30 September 2026: SDK and CLI, 1,500+ connectors, GitHub Copilot plugin, repository options and limits, policy adherence, licensing, warning and block limits, automatic availability
Microsoft Learn, Copilot Managed Runtime overview and key concepts for admins (preview), last updated 13 October 2026: defaults per creation path, admin roles, security group scoping for Copilot Studio, external artifacts setting, build and runtime billing
Microsoft Learn, Copilot Managed Runtime default governance settings (preview), last updated 29 September 2026: default environment group, 18 connectors and 12 MCP servers, blocked actions, content security policy, permanent routing rule, connector policy evaluation for existing environment groups
Microsoft Learn, FAQ about Microsoft Copilot Managed Runtime (preview), last updated 25 September 2026: personal developer environments, governance initialization, Everyone catch-all rule, sharing and data access, mixed-mode connector display
Microsoft Learn, Copilot Managed Runtime licensing FAQ (preview), last updated 7 October 2026: what counts as an API call, 0.1 credits per call, Premium request limits, Microsoft 365 and Dynamics 365 Power Apps rights not covered, spending policy setup
Microsoft Learn, View and oversee apps in Copilot Managed Runtime across your tenant (preview), last updated 25 September 2026: inventory columns, block and delete, Monitor tab and alerts, roles
Microsoft, Copilot Credits Guide, October 2026: Copilot Managed Runtime as paid public preview, API call metering, pay-as-you-go price per credit in USD, Power Apps Premium request limits
Official Microsoft Blog, Introducing the new Copilot with Home, Code and Autopilot, 25 September 2026: new Copilot, split pricing (user subscription and usage-based billing), Agent 365 cost management scope and October plan for Copilot Studio agents, Autopilot
Microsoft Tech Community, New FinOps for AI capabilities: Control spend, measure value, and optimize for impact, September 2026: FinOps for AI context
Microsoft Power Platform Blog, What’s new in Power Platform: September 2026 feature update, 17 September 2026: model app-builder skill and canvas authoring agent plugin with MCP support generally available

Agents With Their Own Accounts: What Changes When Copilot Studio Agents Stop Borrowing Your Identity

Holger Imbery — Sat, 17 Oct 2026 00:00:00 +0000

On October 15, 2026, Microsoft announced agent accounts, business process memory, and triggers for Copilot Studio. This is less about what these agents can do and more about what they are: a new kind of principal in your tenant, with its own credentials and memory.

Introduction

In my customer projects, Copilot Studio discussions tend to come back to the same question: whose identity does the agent use when it does something? So far the honest answer has been “it depends”, and that becomes a problem once agents run recurring processes so that they keep working when nobody is looking.

I think an agent with its own account should be treated as a new principal, much closer to a service account than to a product feature. In practice, that means giving each agent a job description, scoped permissions, a named human owner, clear memory limits, a budget, and a plan for retiring it. If you cannot write that down, I would not give the agent an account yet. Keep in mind that Microsoft is rolling these features out through the Frontier program, which is early access, so details may still change.

What Microsoft announced

The announcement is a Microsoft Copilot Blog post by Jason Moore, Vice President of Product for Microsoft Copilot Studio, published October 15, 2026. It describes managed agents that belong to the organization and persist beyond any one person’s role or tenure.

Agent accounts. Microsoft says agent accounts let agents work in Microsoft 365 with their own credentials, “similar to how any person would”. People can reach the agent in Microsoft Teams and Outlook, @mention it in comments in Word, Excel, and PowerPoint, and hand it tasks that it continues between their interactions. Accounts also let agents work with other agents, tools, apps, and services using their own approved credentials and scoped permissions, without relying on any individual user’s or maker’s credentials. Work is attributed to the agent, and administrators can scope access and manage the agents’ lifecycle.

Business process memory. Microsoft says this memory carries users’ preferences and business process context into each new process cycle. Anything one person tells the agent about the process becomes a shared resource for everyone else. Makers guide how the retained context is used through instructions, and they decide which business records and policies are authoritative.

Triggers in the GitHub Copilot harness. Any agent built on the GitHub Copilot harness can be started by an external signal, such as an email, or on a set cadence, without an additional prompt.

Microsoft also says it plans to add access policies, quality, cost management, and lifecycle controls specific to these agents in the coming months. Microsoft also says agent refinements and a browser-enabled cloud computer for agents are coming.

Neither the announcement nor the what’s new page covers licensing, pricing, regional availability, or retention for agent accounts or business process memory. Please check these points in your own tenant before you plan anything.

Why it matters

When an agent runs on the user’s credentials , it sees only what that user can see. This is safe, but awkward for shared processes because the result depends on who asked.

When an agent runs on the maker’s credentials , it works for everyone but acts as one person. I have seen this go wrong more than once. The maker changes role, a connection breaks, and a process stops without anyone noticing. Or the audit log shows a named employee doing things that person never did.

When an agent runs on a shared service account , attribution stays blurred. If several agents share one, nobody can tell which agent did what.

Agent accounts address all three cases. My reading is that they give org-owned agents a much clearer, platform-supported answer to who did what. That helps with audits, incident response, and German works councils, who will want to know that agent activity cannot be mistaken for employee activity.

There is a second change. An agent you can email and @mention behaves like a colleague, so users will treat it like one. They will tell it things in passing, expect it to remember, and assume that someone is responsible for it. Every one of these expectations needs a governance answer.

The third change comes from triggers. Nobody has to start the agent anymore, so it can run at 03:00 on a Sunday because an email arrived. Risk and cost are no longer tied to office hours, and your monitoring should reflect that.

Architecture implications

Agent accounts and Microsoft Entra Agent ID

How do agent accounts relate to the Microsoft Entra Agent ID that Copilot Studio already creates? Here, I separate what is documented from what isn’t.

The What’s new in Copilot Studio page says that starting in July 2026, Copilot Studio automatically creates a Microsoft Entra Agent ID for every new agent, and you can no longer opt out at the environment level. The Microsoft Entra Agent IDs for Copilot Studio agents page explains that connector permissions are attached to the agent identity as API permissions, that admins can target them with Conditional Access, and that deleting an agent also deletes its Agent ID. That page says it describes agents powered by the standard harness, and the App registration, agent identities, and authentication page says Agent ID provisioning timing depends on the harness. The same page describes Entra Agent IDs as service principals with an “Agent” subtype and says that no one in your tenant, including tenant administrators, can generate tokens with the agent identity.

The October 15 post does not say whether an agent account is built on the Entra Agent ID, sits next to it, or is something else. It also does not say whether an agent account needs a license, has a mailbox in the usual sense, or shows up as a user object. The Agent 365 identity integration page refers to Agent 365 identity concepts such as agentic users, but I have not found any Microsoft statement that links them to Copilot Studio agent accounts.

For now I would govern the Entra Agent IDs you already have and confirm the identity model of agent accounts in your own tenant. I would not design an access model on the assumption that the two are the same object.

Microsoft’s pages give different dates for this change: March 18, 2026 on a Microsoft Entra page, May 2026 on the Copilot Studio identity pages, and July 2026 (no opt-out) on the what’s new page. Check your older agents, because some may still use legacy app registrations.

Credentials move from people to agents

With borrowed credentials, the agent’s access was inherited from a person. With agent accounts, someone has to design it. In my experience, the first permission list is almost always too broad, because the maker lists everything the process might ever need. I prefer to derive permissions from the process steps: for each step, which system it touches and whether it reads or writes. Grant that, and review it after the first few cycles.

Memory changes the data model

Copilot Studio already offers memory for agents on the GitHub Copilot harness. According to the what’s new page for June 2026, it captures user preferences and patterns and “stores them per user”. Business process memory works differently on purpose, because what one person tells the agent becomes available to everyone who works with it.

It is a shared knowledge base written through conversations, so the choice of authoritative records is the key design decision. If the instructions do not state clearly that the ERP record wins over a remembered comment, sooner or later a remembered comment will win.

Triggers change the runtime profile

Triggers make the agent event-driven, which raises the usual questions. What happens when 400 emails arrive in an hour, when the same signal arrives twice, or when a run cannot finish? I did not find published limits, retry behavior, or concurrency controls for these triggers in the sources I read, so I would test all three before going live.

Governance implications

A named human owner, not just a sponsor

According to the identity documentation, Copilot Studio adds the agent owner to the Entra Agent ID as a sponsor with limited permissions for “governance traceability” and “accountability for agent lifecycle.” That is a sensible default, but the maker is rarely the person who owns the business process. I would record both, plus a deputy.

Shared memory, retention, and the right to be forgotten

I expect the hardest discussions here, at least in the EU. People will tell the agent things about other people, for example, “Don’t send the forecast to Martin before Thursday; he’s on leave.” That is personal data under the GDPR, about someone who never talked to the agent.

The sources don’t say where business process memory is stored, how long it is kept, whether Microsoft Purview retention and eDiscovery cover it, or how to find and delete a single entry. If someone makes an erasure request under Article 17 or an access request under Article 15, you need to be able to say what the agent remembers about that person. Until Microsoft documents this, I would use instructions to keep personal data out of memory, tell users clearly that the memory is shared, and involve the data protection officer before the pilot starts. In many cases, a data protection impact assessment will be appropriate.

Do not assume that business process memory follows the retention and deletion rules of Teams chats or Exchange mail. Microsoft has not documented this. Treat it as an open question and check it before any personal data reaches the agent.

Triggers and cost when nobody is watching

The what’s new page for August 2026 says that agents, workflows, and apps powered by the GitHub Copilot harness use usage-based billing measured in Copilot Credits. Triggers are part of that harness. My reading is that every triggered run can therefore consume credits, even when no person is involved.

The failure modes are familiar: a mail loop between two agents, or a five-minute test schedule nobody changed back. Microsoft says cost-management controls for these agents are planned, which suggests they aren’t all available yet. Until they are, I would use the agent usage estimator before going live and review consumption per agent every week. I wrote about the wider cost picture in my October 10, 2026 article on agent FinOps.

Lifecycle and retirement

These agents are meant to outlive the projects that built them, so I would set a review date when each agent is created. If the owner doesn’t confirm the agent is still needed, switch off the triggers first, then remove permissions, then delete the agent. The documentation confirms that deleting an agent deletes its Entra Agent ID. The documentation doesn’t yet confirm whether it also removes the agent account and its business process memory, so test this during a pilot.

Practical recommendations

Pick the right processes first

Microsoft suggests starting with one shared business process, and I agree. Good candidates are stable , clearly owned , and recurring , and mistakes in them are visible and easy to reverse. Typical examples include weekly reporting, triaging incoming contracts, and collecting status updates before a steering meeting.

I would avoid processes with unclear ownership, processes that touch special categories of personal data, one-off projects, and anything where the agent would make a final decision with legal effect on a person. In Microsoft’s example, the finance team keeps authority over allocations and spending. I would treat that as a rule for every org-owned agent.

Personal agent or org-owned agent

I use the following table with customers. If most answers fall into the right column, the agent should be org-owned.

Question	Personal agent	Org-owned agent
Who benefits?	One person	A team or function
Should it outlive its creator?	No	Yes
Whose access should it use?	The user’s	Its own, scoped
Should memory be shared?	No, per user	Yes, per process
Does it start on its own?	Rarely	Often, by trigger
Who is accountable?	The user	A named process owner
Audit needs	Low	High, actions attributed to the agent

Mixed answers often mean two agents that are easier to govern separately.

A short readiness checklist

Before I give an agent its own account, I want the following points answered in writing:

Job description. A paragraph on what the agent does, for whom, and what it must never do.
Owner and deputy. A named process owner and a deputy, in addition to the maker.
Permissions. Systems and actions derived from the process steps, with read and write listed separately.
Identity. The agent’s Entra Agent ID checked in the Microsoft Entra admin center, and Conditional Access reviewed.
Memory rules. Instructions that name the authoritative records, and a notice to users that memory is shared.
Data protection. Data protection officer informed, a documented decision on an impact assessment, and a process for erasure and access requests.
Triggers. Sources, schedule, and expected volume documented, with a plan for duplicates and bursts.
Budget. Expected Copilot Credits per cycle and a named person who reviews usage.
Review date. The date when the owner must confirm that the agent is still needed.
Exit plan. The order for switching off triggers, removing access, and deleting the agent.

Use the Frontier phase to collect evidence

If your tenant is in the Frontier program, I would use the next weeks to answer the open questions rather than build a showcase. How does an agent account appear in Microsoft Entra? What do the audit logs show? Can you delete a memory entry? What does a triggered run cost?

Conclusion

With these features, Copilot Studio agents become participants in a process instead of tools that people use. Microsoft calls them digital teammates. I find that description useful as long as we follow it through: a teammate has a role, a manager, limits, and at some point leaves.

Borrowed credentials have been a weak spot in many agent projects I have seen, so clear attribution is a real improvement. But several controls are still on the way, and the documentation on identity, memory retention, and trigger limits is incomplete. Start with one stable, clearly owned, recurring process, write the job description before you build, keep personal data out of shared memory, watch credit consumption, and set a retirement date on day one.

Sources

Microsoft Copilot Blog (Copilot Studio), Delegate shared business processes to agents that are more persistent and proactive with Microsoft Copilot Studio, October 15, 2026: agent accounts, business process memory, triggers in the GitHub Copilot harness, planned controls, agent refinements, browser-enabled cloud computer, budget agent example, Frontier program rollout
Microsoft Learn, What’s new in Copilot Studio, last updated October 5, 2026: automatic Microsoft Entra Agent ID for every new agent from July 2026 without environment opt-out, per-user memory for GitHub Copilot harness agents (June 2026), usage-based billing in Copilot Credits (August 2026), agent usage estimator (April 2026)
Microsoft Learn, Microsoft Entra Agent IDs for Copilot Studio agents: connector permissions on the agent identity, Conditional Access, deletion of the Agent ID with the agent, move from app registrations, scope limited to the standard harness
Microsoft Learn, App registration, agent identities, and authentication: Agent IDs as service principals with an “Agent” subtype, provisioning timing by harness, agent owner added as sponsor, no token generation by tenant users
Microsoft Learn, Agent identity integration for Copilot Studio, last updated May 19, 2026: automatic Agent IDs, Agent 365 registry and governance integration, reference to agentic users
Microsoft Learn, Recreate Copilot Studio agents with Microsoft Entra Agent ID: legacy service principals, March 18, 2026 date for automatic agent identities, agent-specific audit trails and lifecycle governance
holgerimbery.blog, agent FinOps in the Microsoft ecosystem, October 10, 2026: my earlier article on agent cost management

Agent FinOps in the Microsoft Ecosystem - Rev1

Holger Imbery — Sat, 10 Oct 2026 00:00:00 +0000

This is the second post in the series on Copilot and agent costs. Part one was the price list: the Copilot license for everyday AI, and Copilot Credits for agentic work. This post is about what happens after you buy. Agent costs show up in four places (Copilot, Cowork, Copilot Studio, and Foundry), spread over three consoles, and each one has different controls. For each, I cover where you see the cost, what actually stops spending, and how to bring it down. Everything comes from Microsoft’s own pages.

This is a living article. I check it against Microsoft’s documentation, pricing pages, and announcements at the start of every month and update it when something changes. The changelog at the end lists every change.

What FinOps means when you run agents

FinOps comes down to three habits: make spending visible, give it an owner, then reduce it.

That works well for cloud costs, because they have a clear unit: an hour of a virtual machine, a gigabyte, a request. Agents don’t. One user question can start a plan, several model calls, a search through company data, a few tool calls, some retries, and sometimes other agents. It all happens in seconds, usually before any dashboard updates.

So you keep the three habits and count something else. A useful number is the cost of one agent session. A better one, if you can get it, is the cost of one result: one ticket solved, one document checked, one invoice cleared. Finance can work with that.

Three things make agents harder than normal cloud costs.

Costs can start before you go live. On one Copilot Studio harness, building, previewing, and testing an agent already use credits.
Without a person in the loop, nothing slows an agent down. Costs then follow how often the agent is triggered, not how many people use it.
The numbers are spread out. Copilot and Cowork report in the Microsoft 365 admin center, Copilot Studio in the Power Platform admin center, and Foundry in Azure. Nothing shows all of them together.

Four meters, three consoles

Where agents run	What you pay for	Where you see the cost	Can you set a hard stop?
Microsoft 365 Copilot	A license per user; agents are billed per use for people without one	Microsoft 365 admin center	Yes, a monthly limit per user
Copilot Cowork	Copilot Credits per task, always	Microsoft 365 admin center	Yes, a monthly limit per user
Copilot Studio	Copilot Credits per agent action	Power Platform admin center	Yes, a monthly limit per agent
Foundry agents	Model tokens, tools, storage, compute	Azure Cost Management	No, budgets only warn

Credit use in the first three comes out of one pool per tenant. Foundry is billed through Azure and is completely separate.

Copilot and Cowork: the Microsoft 365 admin center

Where it is and what it covers

The cost screen for Copilot Credits is in the Microsoft 365 admin center under Copilot > Cost management. Microsoft’s usage-based billing overview (updated September 25, 2026) calls it “a centralized place to govern and monitor AI experiences”. You can see usage by spending policy, user, group, agent, service, and funding source.

It covers fewer services than you might expect. The overview lists Cowork, apps built with Cowork, and the Work IQ API (for third-party agents). For Copilot Studio, the same page still sends you to “Copilot Studio pay-as-you-go” instead. Copilot Studio isn’t in there yet. More on that in the section on October.

Before any of this can run, someone has to switch it on. The Configuration tab is where you turn on usage-based billing, pick how you pay (pay-as-you-go, pre-purchase, or capacity packs), and link an Azure subscription. The USL and UBB page is clear: “Admins must set up a billing policy before a user can use” these experiences.

How spending policies work

Spending policies are the main control. The rules are simple once you’ve read them, but a few of them surprise people.

Policies can apply to the tenant, to groups, or to users. Individual users can only be added through security groups.
The default policy sets the tenant limit. Every other policy has its own limit and “doesn’t inherit the tenant-level limit.”
If a user is in several policies, only one applies: the one with the highest per-user limit, then the largest policy limit, then the newest. “The chosen policy applies in full and settings from other policies aren’t combined.”
When a user reaches the limit, “they lose access to agents and services for the rest of the month”. Moving them to another group doesn’t help: “Moving a user between groups or spending policies doesn’t reset the user’s consumption.”
Policies cap spending. They “don’t reserve or allocate Copilot Credits”.
For Cowork, a policy can also limit which AI models people can use. Microsoft calls these “model profiles”: a saved set of at least two models that you attach to a policy. They are “currently available only for Copilot Cowork”.
Credits are used in a fixed order: capacity packs first, then the pre-purchase plan, then pay-as-you-go.
You can change a policy’s billing method later. This used to be impossible. Since the setup page was updated on October 2, 2026, it says: “Changing the billing method doesn’t require you to delete and recreate the policy.” Scope, limits, alerts, and services stay as they are.

For Cowork, a spending policy does more than cap money. The Cowork admin page says: “A spending policy is an access control, not only a budget.” If someone isn’t in a policy, they can’t use Cowork.

The setting “Auto-apply new services” is on by default. Every new service Microsoft adds to usage-based billing is then covered by your existing policies without anyone deciding it should be. Microsoft’s own advice on the setup page: “Turn off the setting if you want to review and add future services manually.”

Who can do what

The setup page splits the work across roles, which helps if finance and IT share the job. Microsoft changed this on October 2, 2026: the AI and License admins can now edit policies, but no longer create them.

Role	What they can do
Global admin, Billing admin	Turn on usage-based billing, add and change billing methods
AI admin, License admin	Edit spending policies, limits, alerts, and billing methods, but not create new policies
AI Reader, Global Reader	Read-only access, good for finance

What users see

In Cowork, a user can type /cost to see what a task used and how many credits they have left this month. The /cost page (updated August 13, 2026) also says what it doesn’t do: “It does not provide month-over-month trends, usage history”. Microsoft says more is coming, including “new ways to view their credit consumption or request credits from their admin”, but gives no date.

Users can also ask for more credits. Admins can send those requests to their own IT portal or a ServiceNow workflow instead of handling them in the admin center.

The adoption report is not a cost report

The Microsoft Copilot Agents usage report (preview, updated August 18, 2026) shows active users (licensed and unlicensed), active agents, responses, and who built each agent. Data shows up “within an hour”. It has no cost or credit figures, covers only the last 7 or 30 days, hides user names by default, and leaves out two things: “SharePoint agents used in Teams aren’t currently included”, and “Cowork usage is not included”. Use it to see which agents people really use. Don’t use it to charge anyone.

The admin center figures are not your bill. The monitoring page says the Overview tab refreshes every 4 hours and the Consumption tab every 2 hours, and exports are “a point-in-time snapshot”. Use the monthly invoice for the real numbers.

How to keep costs down

Decide license or pay-per-use for each group, with real numbers. For licensed users, employee-facing agent use in Copilot Chat, Teams, and SharePoint is largely free (see part one for the exceptions). For heavy agent users a license can be cheaper than credits. For light users it’s the other way round. This is a buying decision, and it makes the biggest difference to your bill.

Turn on per-user limits from day one. Cowork work has no natural end. Someone who finds it useful will use it more next week.

Use approvals instead of raising everyone’s limit. Each request for more credits shows you what people really need.

Set one policy per Entra group. Then you can compare groups and see which team uses far more than the others.

Get the billing method right the first time , and check Auto-apply before Microsoft adds the next service.

Copilot Studio: the Power Platform admin center

Part one covers the credit rates for each agent action. Here I only repeat what you need to control them.

When the meter starts

The harnesses overview (updated October 1, 2026) says: “The harness you use affects the billing, features, and capabilities of what you build.”

Harness	What it’s for	When charging starts
Standard	Agents with topics and agent flows	When the agent is used, at the standard rates
Copilot Chat	Copilot Chat extended with your own knowledge	Billed per use, or included in the Copilot license
GitHub Copilot	Multi-step agents that reason and work with documents	With your first build action, before anyone publishes

The GitHub Copilot harness “charges credits from the moment you start building”, according to the billing overview for that harness (updated September 28, 2026). Previewing, testing, and creating evaluations all use credits. Credits cover model tokens, tools (including knowledge and MCP servers), and the harness itself. Places people assume are free aren’t either: “Developer environments and trial environments move to usage-based billing September 1, 2026.”

Four more rules from the billing rates page (updated August 3, 2026) matter for control:

Reasoning models cost more. You pay the feature rate plus the premium AI tools rate of 10 credits per 1,000 tokens.
Agent flows are only free one way. For licensed users, “the ‘No charge’ inclusion applies only to runs triggered via the ‘When an agent calls the flow’ trigger”. A flow started by a schedule or an event is billed.
Computer use isn’t included. “Computer-Using Agents (CUA) usage is not included in the Microsoft Copilot USL.”
Power Automate cloud flows are separate. They “use Power Automate licensing, not Copilot Credits” and aren’t affected by Copilot Studio limits.

Where you see the cost

In the Power Platform admin center, go to Licensing > Products > Copilot Studio. The capacity page (updated October 2, 2026) describes:

credits from the tenant pool that you assign to environments;
reports you can download by environment, agent, or user, including “the count of billed versus nonbillable credits” (the non-billed part is what your licensed users get free);
daily data for the current month and the last two full months, and monthly data for the past 12 months.

If you pay as you go, a billing plan links environments to an Azure subscription and creates a Power Platform account resource there. It’s hidden in the Azure portal by default; choose “View hidden types” to find it.

One limit matters for chargeback. For the GitHub Copilot harness, Microsoft says: “Discrete costs aren’t attributed to individual makers or end users.” You see costs per environment and per agent, not per person.

What stops spending

Per-agent limits. Each agent can have a monthly credit limit, with the status “Within limit”, “Nearing limit”, or “Over limit”. With the hard stop on, “The agent is automatically turned off once it hits the defined limit.” This is the setting to rely on when money matters. Azure budgets won’t do it: they “send notifications but don’t stop Copilot Studio consumption.”

The 125% rule on prepaid capacity. “Enforcement is triggered when a tenant reaches 125% of their prepaid capacity.” Custom agents are then switched off, and users see “This agent is currently unavailable. It has reached its usage limit.” Agent flows behave differently: once prepaid capacity is fully used, new flow runs are blocked while the agent keeps answering. So an agent can look fine while part of its work has stopped. An email goes to the tenant admin.

Pay-as-you-go has no cutoff. Extra use is billed to Azure: “With pay-as-you-go, enforcement doesn’t apply”. No outage, but no ceiling either. Choose which risk you’d rather have.

How to keep costs down

Look at how often agents ground in company data. Grounding costs 10 credits, a classic answer 1. An agent that searches SharePoint or Exchange on every turn costs about ten times as much as a simple one. This is often the biggest number in a Copilot Studio estimate, and often the easiest to cut.

Choose the right harness. The GitHub Copilot harness is right for real multi-step work, and it charges you to build as well as to run. Use the Standard harness where that isn’t needed.

Set a monthly limit with a hard stop on every production agent.

Keep environments contained. Give each environment its own credits and clear the option “Draw from the available capacity in my tenant”. This doesn’t stop use through a pay-as-you-go plan linked to the same environment. With environment groups, you can enforce it for a whole group through a rule called “Cost controls - Draw from tenant credit pool”; the environment setting then becomes read-only and can’t be overridden by scripts.

Move flows to the agent trigger where you can. Not every scheduled flow has to be scheduled.

One credit pool, two admin centers, one Azure bill

This is easy to miss because each side describes it in different words.

Credits are pooled for the whole tenant. Credits you assign to environments in the Power Platform admin center come out of the same pool that Cowork and the Work IQ API use. The Microsoft 365 admin page says this “reduces the prepaid capacity available for Cowork and Work IQ API services”. What the Microsoft 365 admin center shows as available is what you bought minus what’s already been given to environments.

So two teams take from one pool, usually without talking to each other. If your Power Platform admin hands out a lot of capacity, your Microsoft 365 admin sees available credits drop for no obvious reason. Put both people in the same monthly review.

Azure adds a third view. According to the page comparing the two views (updated September 25, 2026):

Cowork, Work IQ, and Copilot Studio all show up on the Azure bill “under the Microsoft Copilot Studio service rather than separate services”.
“Azure Cost Management doesn’t show consumption against Prepaid Capacity packs.”
To tell services apart on the bill today, put them in separate Azure subscriptions or resource groups. Microsoft says to “use service tags as they become available”, with no date.
Admin center totals and Azure totals won’t match. Microsoft: “Use the monthly billing record for reconciliation, not the usage dashboards.”

Foundry agents: Azure

What you pay for

Foundry works the opposite way to Copilot Studio. A credit hides a whole workflow behind one number. Foundry charges every resource separately, which is harder to forecast but much easier to assign to a team.

The Foundry Agent Service pricing page says there is “no additional charge for creating or running Foundry-native agents using prompts and workflows”. You pay for what the agent uses.

What the agent uses	How it’s charged
Models	Tokens, input and output priced separately
File Search (knowledge)	$0.11 per GB of vector storage per day, first GB free
Code Interpreter	$0.033 per session
Web Search and Custom Search	$14 per 1,000 requests
Hosted agents (Agent Framework, LangGraph)	The container compute they run on, per hour
Fabric, SharePoint, Bing grounding, Foundry IQ, Logic Apps connectors	Charged separately, on top of tokens

The cost planning page (updated August 27, 2026) adds three things that catch teams in the second month:

Fine-tuning is charged three times, for training, hosting, and inference. A fine-tuned deployment costs money while it exists, even if nobody uses it.
Failed calls aren’t automatically free: “HTTP status codes alone don’t determine whether usage is billed.”
There’s no emergency brake. OpenAI offers hard spending limits; Azure OpenAI “doesn’t currently provide this functionality.”

Where you see the cost

Azure Cost Management is the official record. Azure OpenAI sits inside the wider Cognitive Services group, so filter by service tier. Meters are named model-name-GUID. Partner and community models show up at resource group level, and some under “Global resources”, so look at the whole resource group, not only the Foundry resource.

The Foundry portal shows estimates. There’s an estimated cost per project and in the agent list. Use it for quick checks, and use Cost Management and the invoice for real numbers. The estimates leave out prompt agents, non-Foundry agents, and provisioned throughput.

Anomaly alerts are slower than agents. Azure compares each day with a forecast based on the last 60 days, and “Anomaly detection runs 36 hours after the end of the day (UTC)”. Alert rules work only per subscription, you get five per subscription, and each alert email is sent once. For normal workloads that’s fine. For an agent stuck in a loop, the money is gone before the alert arrives.

How to keep costs down

Match the deployment type to the work. Standard pay-per-token for development and uneven traffic. Provisioned throughput for steady production that needs predictable speed, but you can’t pause it: “Billing stops only when the deployment is deleted.” Provisioned quota is shared across supported models in a region and deployment type. If you buy a reservation, create the deployments first and buy after. A reservation doesn’t guarantee capacity.

Move bulk work to Batch. Jobs that can wait up to 24 hours run at “50% less cost than global standard”. It’s the most overlooked discount for bulk summarizing and classifying.

Use prompt caching, and check both sides. Cached input is cheaper on Standard deployments and up to 100% cheaper on provisioned ones. On GPT-5.6 models and newer, writing to the cache can cost extra. The prompt needs at least 1,024 tokens with an identical start, and caches aren’t shared between Azure subscriptions.

Treat the model router mode as a cost setting. Balanced picks cheaper models that stay within about 1 to 2% of the best quality. Cost mode allows about 5 to 6%. Quality mode ignores cost. The usable context window is limited by the smallest model behind the router.

What changes in October

On September 25 Microsoft announced that cost management will cover more services:

Cost management in Agent 365 is expanding beyond Cowork and Work IQ APIs to include Code and Copilot Managed Runtime, with support for agents built in Microsoft Copilot Studio planned for October.

Official Microsoft Blog, September 25, 2026

If it arrives as announced, Copilot Studio costs will show up next to Cowork in the Microsoft 365 admin center. Then you would see most of the credit pool in one place for the first time.

A note on the name. The blog calls it “cost management in Agent 365”. Agent 365 has been generally available since May 1, 2026, at $15 per user (€13.00 on Microsoft’s German page) or included in E7, and it’s managed in the admin center under Agents. But on Microsoft’s documentation pages, cost management sits under Copilot > Cost management , and the Agent 365 service description (updated October 1, 2026) still lists no cost features. I read “Agent 365” here as the name of the direction, and the Copilot area of the admin center as the place where you actually find the settings.

The same post announced more controls. Here is where each one stands as of October 6, 2026:

Announced	Status
Code and Copilot Managed Runtime in cost management	Not yet on Microsoft’s list of covered services in the admin center. The October 2026 Copilot Credits Guide now describes how both use credits. Managed Runtime is in paid public preview
Copilot Studio agents	“Planned for October”; still not documented on October 6, 2026
Managing spending policies through an API	Announced; no API documentation yet
Sending credit requests to your own approval workflow	Already available and documented
Choosing model families per user group, which also limits what Auto picks	Partly there: “model profiles” in spending policies, for Cowork only
Users see usage, remaining credits, and history in Copilot	Remaining credits yes; history not yet
Insights on which Cowork tasks pay off	Available in the Insights consumption dashboard, for Cowork and the Work IQ API only

What I couldn’t find anywhere yet:

whether “agents built in Copilot Studio” means all three harnesses or only the GitHub Copilot harness;
whether per-agent limits, environment allocation, and the 125% rule stay in the Power Platform admin center, move over, or are replaced by spending policies;
how user- and group-based policies will apply to autonomous agents and to people without a license, since Copilot Studio is managed per environment and agent today;
whether Auto-apply will put Copilot Studio agents under your existing Cowork policies automatically;
how capacity packs, the pre-purchase plans, and existing Power Platform billing plans carry over;
whether it starts as a preview, and the roadmap or Message Center ID.

Before Copilot Studio agents arrive, check whether Auto-apply is still on for your broad policies. If it is and Copilot Studio agents join, they may land under a limit that was sized for Cowork.

Microsoft’s own pages also disagree in places:

the blog says “Agent 365”, the documentation says Copilot > Cost management;
the blog says Code and Managed Runtime are covered, while the documentation page updated the same day doesn’t list them;
the Copilot Credits Guide (October 2026) says credit usage “is centrally managed through the Microsoft 365 admin center”, while the documentation still sends Copilot Studio to the Power Platform admin center;
the blog says users can see their usage history, while the /cost page says it shows none.

The documentation seems to lag the announcements. Check your own tenant.

How to charge costs back

Each platform gives you a different handle.

Copilot and Cowork: the spending policy. One policy per Entra group is your department unit, with per-user limits inside it. These are the only places with real per-user cost data.

Copilot Studio: the environment and the billing plan. The Power Platform account resource created by a pay-as-you-go billing plan can be tagged like any Azure resource. That’s how Copilot Studio costs get into your normal Azure cost model. Deleting the billing policy doesn’t delete that resource. Since there’s no per-user view, the way you lay out environments is your chargeback model.

Foundry: the project tag. The best handle of the four, and still in preview. “Every Foundry project is automatically tagged with a project tag on its underlying usage.” You don’t tag anything yourself; filter Cost Analysis by project. The preview covers models sold by Azure, including Azure OpenAI, but not models bought through Azure Marketplace.

And Azure itself: because Cowork, Work IQ, and Copilot Studio all appear as “Microsoft Copilot Studio” on the bill, use separate subscriptions or resource groups if you need them apart. For pre-purchase plans, use the amortized cost view to spread the cost over the year.

Here’s a pattern that works. This part is my advice, not Microsoft’s: one environment and one billing plan per business unit in Copilot Studio, with the account resource tagged to that unit; one spending policy per Entra group for Copilot and Cowork, with per-user limits; one Foundry project per use case, in a resource group that belongs to the business unit. Then one place where you bring it all together.

Bringing it all into one view

Can anything connect the four? Partly, and you have to build it.

Microsoft’s FinOps guidance

Microsoft’s FinOps guidance on Learn follows three phases (Inform, Optimize, Operate) and is “largely based on the FinOps Framework with a few enhancements”. It’s good guidance, but it doesn’t cover agents or Copilot Credits. The unit economics page comes closest to “what does one agent session cost”, and it points you to your own telemetry. Nobody hands you a cost-per-conversation number.

The FinOps toolkit and FinOps hubs

The FinOps toolkit is open source and released monthly. It includes FinOps hubs, Power BI reports, workbooks (including cost optimization and governance), the Azure Optimization Engine, PowerShell and Bicep modules, and open data. If you only need better Azure reporting for Foundry, the workbooks and Power BI reports may be enough.

FinOps hubs are Microsoft’s “virtual command centers for leaders throughout the organization to report on, monitor, and optimize cost”. Deploying one gives you a Data Lake Storage account, Data Factory for loading, Key Vault, and optionally Azure Data Explorer or Microsoft Fabric for analysis. The benefits that matter for agents: reporting across separate tenants, discount savings for EA and MCA accounts (where Foundry reservations show up), fast year-over-year queries, the FOCUS cost format, and room to add your own business data.

Microsoft publishes the cost: from $120 a month plus about $10 a month per $1 million of spend monitored. Most of that is the analysis engine: about $120 for a single-node Data Explorer cluster, or $300 for F2 Fabric capacity. Without either, it’s about $5 per $1 million monitored. For a large agent estate that’s small. For a small one, start with the workbooks and reports.

What a hub doesn’t see on its own

A hub loads Cost Management exports, so it sees what Azure bills. That covers all of Foundry, and Copilot Studio if you pay as you go. It doesn’t cover capacity packs, which Azure doesn’t show, or the per-user and per-policy detail from the Microsoft 365 admin center. So the realistic target is three feeds, not one screen:

Feed	What it covers	How it gets into the hub
Cost Management exports (FOCUS)	Foundry, plus Copilot Studio and Cowork billed through Azure	Built in
Power Platform consumption reports	Copilot Studio per environment and agent, including capacity packs	Your own export and Data Factory pipeline
Microsoft 365 Cost management views	Copilot and Cowork per policy, group, and user	Your own export and pipeline

Microsoft expects you to extend a hub this way. One rule: don’t change the built-in pipelines or the data in the msexports container, and give your own pipelines a clear prefix.

Sort out permissions early, because they cross teams. Exports need Cost Management Contributor (or the matching EA or MCA billing roles). Deploying the template needs Owner, or Contributor plus Role-Based Access Control Administrator.

Microsoft also shows how to put an agent on top of a hub, through a Kusto Query MCP server published to Teams or Microsoft 365 Copilot. It’s handy for quick questions like which agent grew most this month. It has the same gaps as the hub, and it’s an agent itself, so give it a spending limit too.

Cost Management exports usually run every 24 hours. Anything built on top inherits that delay. No hub gives you a live agent bill.

Why bother

For “what did this agent cost last month”, the admin center screens are enough. To run a portfolio, one data store helps in a few ways:

One total that finance accepts , instead of three reports pasted into a spreadsheet.
Chargeback that survives a reorganization , because costs follow environments, policies, projects, and tags, not someone’s spreadsheet.
Reporting across tenants , if you have an acquisition or a regional tenant.
Evidence for commitments like provisioned throughput, reservations, and pre-purchase plans.
A place for business numbers , so you can get from spend to cost per result.

Where to start

This order is mine, not Microsoft’s. It starts with what pays off fastest and leaves the building work for later.

Turn on the controls you already have. Per-agent monthly limits with a hard stop in the Power Platform admin center. Per-user limits and alerts in the Microsoft 365 admin center, with Auto-apply off until you’ve decided. Budgets and anomaly alerts on the Azure subscriptions that carry Foundry, knowing they only warn.
Give every agent and environment an owner. A cost nobody owns is a cost nobody reduces.
Set up the structure before volume arrives. One environment and billing plan per business unit, one spending policy per Entra group, one Foundry project per use case, and the Power Platform account resource tagged to a cost center.
Agree how the pool is shared. Decide how much capacity goes to Power Platform environments and how much stays for Cowork, and review it monthly with both admins.
Turn on Azure reporting. Create a FOCUS export, then use the toolkit’s Power BI reports and workbooks. For many companies, that’s enough.
Build a hub when several teams need the same data , then add the Power Platform and Microsoft 365 feeds.
Add business numbers, then an agent on top.

Steps one to four cost time, not money. Steps five to seven are engineering with a real bill. Teams often jump to step six because it’s the fun part, and find out months later that they have great reporting for agents that still have no limits and no owners.

In October, check Microsoft’s list of services covered by usage-based billing. When Copilot Studio shows up there, this post gets an update.

Sources

Official Microsoft Blog, Introducing the new Copilot with Home, Code and Autopilot, September 25, 2026: the cost management expansion, Copilot Studio planned for October, the other announced controls
Microsoft Learn, Usage-Based Billing and Cost Management for Copilot Credits, last updated September 25, 2026: where cost management is, which services it covers, Auto-apply on by default
Microsoft Learn, Managing AI experiences enabled by usage-based billing, last updated October 2, 2026: spending policy rules, which policy wins, model profiles, the shared pool
Microsoft Learn, Set up usage-based billing for Copilot Credits, last updated October 2, 2026: roles, billing method can be changed, order of credit use, Auto-apply advice, tenant limit not inherited
Microsoft Learn, Monitor Copilot Credit spending: refresh times, credit requests, custom request policies
Microsoft Learn, View Copilot Credit consumption in the Microsoft 365 admin center and on your Azure bill, last updated September 25, 2026: one Azure service name, capacity packs missing from Azure, reconciliation, service tags
Microsoft Learn, Understanding the user subscription license (USL) and usage-based billing (UBB), last updated September 25, 2026: billing policy required, more user views coming
Microsoft Learn, Check your credit usage for Cowork tasks with /cost, last updated August 13, 2026: what users see, no usage history
Microsoft Learn, Manage Copilot Cowork for your organization, last updated September 14, 2026: spending policy as access control
Microsoft Learn, Microsoft Copilot Agents usage report (Preview), last updated August 18, 2026: what the adoption report shows and leaves out
Microsoft, Microsoft Copilot Plans and Pricing: Enterprise, read September 29, 2026: employee-facing and API footnotes, Azure subscription for agents
Microsoft Learn, Harnesses in Copilot Studio, last updated October 1, 2026: the three harnesses and how they’re billed
Microsoft Learn, Overview of usage-based billing for the GitHub Copilot harness, last updated September 28, 2026: charging from the first build action, what credits cover
Microsoft Learn, Manage costs for agents powered by the GitHub Copilot harness, last updated August 28, 2026: no per-user attribution, budgets don’t stop use, developer and trial environments, the environment group rule
Microsoft Learn, Billing rates and management: Copilot Studio, last updated August 3, 2026: reasoning surcharge, flow trigger rule, computer use, Power Automate flows, the 125% rule
Microsoft Learn, Manage Copilot Credits and capacity for Copilot Studio, last updated October 2, 2026: reports, data retention, per-agent limits and hard stop, environment allocation
Microsoft Learn, Set up a pay-as-you-go plan, last updated December 16, 2025: billing plans, the hidden Power Platform account resource, tagging it for cost allocation
Microsoft Learn, Microsoft Agent 365: Service Description, last updated October 1, 2026: no cost features listed
Microsoft Learn, Agent management in Microsoft 365 admin center, last updated August 20, 2026: the Agents area of the admin center
Microsoft Security Blog, Microsoft Agent 365, now generally available, May 1, 2026: general availability and price
Microsoft Licensing, Copilot Credits Guide: October 2026: credits pooled per tenant, central management statement, Code and Copilot Managed Runtime billed in credits
Microsoft Learn, How to use the Consumption Dashboard in Insights, last updated September 8, 2026: Cowork and Work IQ consumption in Insights
Microsoft Copilot Blog, Copilot Managed Runtime public preview, September 25, 2026: Managed Runtime in public preview
Microsoft Azure, Foundry Agent Service pricing, read September 29, 2026: no charge for Foundry-native agents, tool prices, hosted agents
Microsoft Learn, Plan and manage costs for Microsoft Foundry, last updated August 27, 2026: fine-tuning, failed calls, no hard limits, meter names, portal estimates, project tag chargeback
Microsoft Learn, Provisioned throughput billing and cost management, last updated May 26, 2026: no pause, shared quota, reservation order
Microsoft Learn, Getting started with Azure OpenAI batch deployments, last updated June 5, 2026: 50% less than global standard
Microsoft Learn, Prompt caching with Azure OpenAI, last updated August 11, 2026: read discounts, write charges, 1,024-token rule
Microsoft Learn, Model router for Microsoft Foundry, last updated September 1, 2026: routing modes and the context window limit
Microsoft Learn, Identify anomalies and unexpected changes in cost, last updated June 26, 2025: 36-hour delay, subscription scope, five rules, one-time email
Microsoft Learn, FinOps Framework overview, last updated May 8, 2025: the three phases
Microsoft Learn, Unit economics, last updated April 2, 2025: measuring cost per unit yourself
Microsoft Learn, FinOps toolkit overview, last updated February 11, 2026: toolkit parts and monthly releases
Microsoft Learn, FinOps hubs overview, last updated April 1, 2026: components, benefits, cost estimate, permissions, msexports rule
Microsoft Learn, Configure AI agents for FinOps hubs, last updated May 18, 2026: agent on top of a hub, 24-hour exports
Previous article in this series: Understanding Microsoft Copilot Licensing - Rev1

Four open conflicts as of publication: where cost management lives (“Agent 365” or Copilot > Cost management), whether Code and Managed Runtime are covered yet, whether Copilot Studio is managed in the Microsoft 365 or Power Platform admin center, and whether users can see their usage history. Check each one in your own tenant.

Changelog

Date	Change
October 10, 2026	Rev1. First published as part two of the living series.

Understanding Microsoft Copilot Licensing - Rev1

Holger Imbery — Sat, 03 Oct 2026 00:00:00 +0000

This is a living article (only on my own blog; see canonical URL!). I check it against Microsoft’s pricing pages, licensing guides, and Learn documentation at the start of every month and update it when something changes. The changelog at the end lists every change.

Since September 25, Copilot has two price tags

On September 25, 2026, Jared Spataro described the new split on the Official Microsoft Blog. The per-user license (Microsoft calls it the USL, user subscription license) covers everyday AI. Usage-based billing (UBB) covers the heavy work. His wording: “Cowork, Code, and Autopilot … and frontier models like Astra and Fable all run on UBB.”

For the license, the post promises “the best possible quality at a fixed cost”: Copilot in Chat and in Word, Excel, PowerPoint, Outlook, and Teams, plus model selection. Auto, the default mode that picks a model for each request, “is at the heart of the USL.”

Microsoft published a Learn page on the same day, Understanding the user subscription license (USL) and usage-based billing (UBB). It calls the two kinds of work “everyday AI” and “advanced AI”. Everyday AI is summarizing meetings, drafting documents, and analysis. Advanced AI is “complex, long-running agentic work you hand off”: Cowork, Code, Autopilot, the newest frontier models, and some new agentic features in SharePoint.

The page also answers three practical questions.

Do credits replace the license? No. “UBB experiences consume Copilot Credits and require a USL for access.”
Can users run up a bill on their own? Not at first. “Admins must set up a billing policy before a user can use AI experiences that require usage-based billing.”
Who should pay? Microsoft suggests UBB “may be better funded by business units”. So IT buys the licenses, and the teams that want agentic work pay for the credits.

Put the base plan underneath, because you can’t buy Copilot without one, and you get three layers.

Layer	What it covers	How you pay	Who usually pays
Microsoft 365 base plan	The prerequisite	Fixed, per user	IT
Copilot license (USL)	Chat, Copilot in the Office apps, Auto, model choice	Fixed, per user	IT
Usage-based billing (UBB)	Cowork, Code, Autopilot, frontier models, Work IQ APIs, many agents	Copilot Credits, per use	Business units, if you follow Microsoft

The US enterprise page is clear about the first row: “A qualifying Microsoft 365 subscription is required to purchase Copilot.”

In August 2026, Microsoft renamed “Microsoft 365 Copilot” to “Microsoft Copilot”. Learn: “Microsoft 365 Copilot is now named Microsoft Copilot”. Most pricing pages still use the old name, so I use it wherever I quote it.

How we got here

The September 25 post named something that had been happening for a year. Here are the main steps.

Date	What changed
September 1, 2025	“Messages” in Copilot Studio renamed to Copilot Credits, same price
October 27, 2025	Copilot Credit Pre-Purchase Plan introduced
December 2, 2025	Copilot Business for small companies announced at $21
March 9, 2026	Microsoft 365 E7 announced (available May 1 at $99); Cowork in research preview
June 16, 2026	Cowork generally available, billed in credits
July 1, 2026	Base Microsoft 365 plans more expensive; Copilot price unchanged
September 25, 2026	License and usage-based billing split named; Code and Autopilot go on credits

That year, the $30 license price didn’t move. Almost every new feature that needs a lot of computing went onto credits instead.

What the Copilot license costs

These are Microsoft’s list prices as of October 2, 2026. Dollar prices are from the US pages. Euro prices are from the German pages and exclude VAT. Other countries and buying channels (EA or CSP) may have different numbers.

Plan	USD per user/month	EUR per user/month	Notes
Microsoft 365 Copilot	$30.00	€26.00	Paid yearly (monthly billing: $31.50; no euro price published)
Microsoft 365 Copilot Business	$21.00	€18.20	Up to 300 users
Copilot Business, current discount	$18.00	€15.60	July 1 – December 31, 2026
Business Standard + Copilot Business	$23.50	€20.36	Bundle, paid yearly
Business Premium + Copilot Business	$32.00	€27.73	Bundle, paid yearly
Microsoft 365 E7 (Copilot included)	$99.00	€91.92	Paid yearly

The US enterprise page shows “$30.00 user/month, paid yearly” and “Or $31.50 paid monthly (Annual commitment)”. The German enterprise page shows €26.00 per user per month, billed annually. It also offers monthly payments, but doesn’t show a monthly euro price.

Which base plans qualify is listed in License options for Microsoft Copilot (updated September 17, 2026). For the enterprise add-on that’s E7 (which already includes Copilot), E5, E3, F1, F3, the Business plans, Apps for Enterprise and for Business, Office 365 E5, E3, E1, and F3, the Teams plans, and standalone Exchange, SharePoint, OneDrive, Planner and Project, Visio, and Clipchamp plans.

What the license adds over free Chat is set out in the enterprise pricing matrix: priority model access, Work IQ, and semantic indexing. Voice shows the difference well: “10 mins/day for Copilot Chat users; 60 mins/day for Microsoft 365 Copilot users.”

Copilot Business

Copilot Business is the license for companies with up to 300 users. Microsoft launched it in December 2025. The launch post said: “For just USD 21 per user per month, Copilot Business brings…”. It also offered bundle prices “for a limited time only (until June 30, 2026)”.

A new discount now runs on the business pricing page: “This discount offer is available between July 1, 2026, and December 31, 2026.” The German page gives the same dates, with Copilot Business at €18.20, discounted to €15.60.

Read the small print before you plan with the lower number. The discount is only for “existing Microsoft 365 customers with an eligible Business plan”, and “promotional pricing applies to the first year only”. If you buy at €15.60 today, you pay €18.20 from the second year. Eligible base plans, according to Learn, are Business Premium, Business Standard, Business Basic, Apps for Business, and Teams Essentials.

Copilot Business doesn’t include any credits either. The pricing page also lists Cowork as “Metered” for Business customers.

Microsoft 365 E7

Judson Althoff announced E7 on March 9, 2026, on the Official Microsoft Blog: “Microsoft 365 E7 unifies Microsoft 365 E5, Microsoft 365 Copilot and Agent 365”. It became available “on May 1 for $99 per user”. Agent 365 is also sold on its own, “on May 1 for $15 per user”. E7 is “available with and without Teams.”

The E7 product page shows $99.00 per user per month, with E5 next to it at $60.00. The German E7 page shows €91.92, with E5 at €58.13. The German enterprise plans page lists Agent 365 on its own at €13.00 per user per month. The July price change left E7 alone: “Microsoft 365 E7 pricing is not changing as part of this update.”

E7 gives you the license, not a credit budget. Cowork, Code, and every other credit-based feature cost E7 users the same as they do for everyone else.

The base plans went up on July 1, 2026

Microsoft announced this in December 2025 in Advancing Microsoft 365: New capabilities and pricing update, and published the full tables in February 2026 in Microsoft 365 Pricing and Packaging Updates. The plans most Copilot customers sit on changed like this (list prices with Teams, per user per month, paid yearly). Microsoft published the before-and-after prices in dollars only. For Germany, I can only show today’s price.

Plan	US before	US from July 1, 2026	Germany today
Microsoft 365 E3	$36.00	$39.00	€37.78
Microsoft 365 E5	$57.00	$60.00	€58.13
Business Basic	$6.00	$7.00	€6.07
Business Standard	$12.50	$14.00	€12.13
Business Premium	$22.00	$22.00	€19.06

The same page lists Office 365, frontline, and Apps plans. Copilot was left out on purpose: the public FAQ says the change “does not apply to standalone Microsoft Teams or Copilot SKUs.” Existing customers keep their price until renewal. Part of the reasoning is new Copilot Chat features in the base plans, which the December post describes as “inbox and calendar awareness and access to Word, Excel, and PowerPoint agents”.

What people get without a license

Every eligible Microsoft 365 user has Copilot Chat. Manage Microsoft Copilot Chat (updated September 24, 2026) says it is “available at no extra cost for eligible users”.

It isn’t the same as having a license, and users can see which one they have. The Copilot Chat overview and the support article What Copilot license do I have describe three labels:

Label shown to the user	What they get
Copilot Chat (Basic)	Chat, but no Copilot in Word, Excel, PowerPoint, and OneNote
Microsoft 365 Copilot (Basic)	Standard access to Copilot in those apps
Premium / Pro	A licensed Copilot user

Learn adds that the in-app experience “might vary depending on your organization’s licensing and tenant configuration”.

Unlicensed users can still run up costs through agents. The E7 page footnote says: “An Azure subscription is required to use agents and is priced on a metered basis.” The rate on Meters for Microsoft Copilot pay-as-you-go services is “$0.01 per message”. That page still uses the old word, but it’s the same price as one Copilot Credit.

How Copilot Credits work

A year ago, Copilot Studio counted “messages”. Standard harness licensing records the change: “Starting on September 1, 2025, the common currency for agents changed from messages to Copilot Credits.” The price stayed the same.

Since then, credits have become the currency for much more than Copilot Studio. The Copilot Credits Guide (September 2026) says: “Copilot Credits serve as the common currency in this usage-based model.” One pool per tenant pays for Cowork, Copilot Studio agents, Dynamics 365 agents, Power Platform features, and the Work IQ APIs.

You can buy them three ways.

Option	Price	Commitment	Suits
Pay-as-you-go	$0.01 per credit	None; billed monthly via Azure	Getting started, uneven use
Pre-Purchase Plan (P3)	5% to 20% off	One year, paid up front	Large, predictable use
Capacity pack	$200 (€173.30) per 25,000 credits a month	Billed annually	Existing Copilot Studio setups

Both licensing guides give the pay-as-you-go rate as “Pricing: $0.01/Copilot Credit”. The Copilot Studio Licensing Guide, October 2026 prices the pack at “$200 per credit pack/month (billed annually)”. Unused pack credits don’t roll over. The German Copilot Studio page shows €173.30 in its comparison table, while its FAQ leaves the pack price blank. The US page has the same gap.

Microsoft introduced the Pre-Purchase Plan on October 27, 2025, in Scale your agent rollout with confidence, as “a one-year, pay-up-front purchase option for Copilot Credits”. It counts toward an Azure consumption commitment and renews automatically. The discount depends on how much you buy:

Credits bought up front	Discount
300,000	5%
1,500,000	6%
3,000,000	7%
15,000,000	8%
30,000,000	10%
75,000,000	12%
150,000,000	14%
225,000,000	17%
300,000,000	20%

You can’t undo a pre-purchase. The Cost Management page for Copilot Credit P3 says: “All purchases are final.” Unused credits expire at the end of the year, so size the plan on what you actually use, not on the discount.

Since February 2026, there is also an Agent Pre-Purchase Plan that covers Copilot Studio and Microsoft Foundry together. The September licensing guide: “Each ACU is worth $1 of Copilot Credit or Microsoft Foundry usage.” It has three tiers: 20,000 units at 5%, 100,000 at 10%, and 500,000 at 15%.

What uses credits

Spataro’s sentence names Cowork, Code, Autopilot, and frontier models. Other Microsoft pages add a few more. This is everything I could confirm.

Feature	Status	Source
Copilot Cowork	Generally available since June 16, 2026	Cowork launch post
Code	Rolling out to Frontier program tenants	September 25 blog post
Autopilot (formerly Scout)	Private preview from end of September 2026	September 25 blog post
Frontier models Astra and Fable	On usage-based billing	September 25 post, USL/UBB Learn page
Some Copilot in SharePoint features: image generation and editing, advanced autofill, site analytics	Credits rolling out with general availability, which started September 30, 2026	SharePoint blog, USL/UBB Learn page
Work IQ APIs	Nothing included in the license	Credits Guide
Computer use in agents	Not included in the license	Billing rates Learn page
Apps built in Copilot Studio	Paid public preview	Copilot Studio Licensing Guide

Copilot Cowork

Cowork was the first major Copilot feature that the license alone doesn’t cover. It started as a research preview in March and became generally available on June 16, 2026. The launch post says it is “billed on a usage basis, denominated in Copilot Credits”, and the June 2026 edition of the Credits Guide adds: “No Cowork entitlements are included with the Microsoft 365 Copilot subscription.” So each Cowork user needs a license and credits.

A task’s cost depends on the model, how much context it pulls in, how many tools it calls, and how long it runs. Microsoft gives rough examples:

Task	Credits (Microsoft’s examples)	At $0.01 per credit
Light	70–200	$0.70–$2.00
Medium	400–600	$4.00–$6.00
Heavy	about 1,500	about $15.00

Your own tasks won’t match these exactly, but they give you the order of magnitude. Frontier program tenants had a grace period and were “not billed until July 1, 2026”. Cowork ships switched off (“Cowork is off by default”), and admins can set spending limits for the whole tenant, for groups, and for individual users.

The pricing page line “Available via Frontier program, pricing final upon GA” refers to App Builder and Workflows agents, not to Cowork. Cowork’s billing is already final.

Code and Autopilot

Code lets anyone build small apps, dashboards, and automations. The September 25 post says “Code is rolling out to Frontier at the end of the month, with broad availability in the coming weeks”, and that it “will be in preview for Microsoft 365 Premium and Pro subscribers later this year.”

Autopilot is “a persistent, proactive and personal agent that keeps working even when you’re not”. According to the post, “Autopilot is expanding to private preview at the end of the month.”

Both use credits from day one. Both are built to run longer than a typical Cowork task, so I expect they’ll end up as the bigger items on the bill. That’s my view, not something Microsoft has said.

Copilot Studio agents: included or billed?

This is the question I get asked most. A licensed Copilot user talks to a Copilot Studio agent. Who pays for it?

Often nobody, as long as usage stays within limits. The billing rates page lists employee-facing use as “No charge” when the user has a Copilot license, and the agent runs under that user’s identity, with the note “Usage is limited to fair usage limits.” Standard harness licensing says that for licensed users in Copilot Chat, Teams, and SharePoint, “classic answers, generative answers, or Microsoft Graph tenant grounding have zero-rated usage”. Zero-rated means they cost no credits.

The trouble is in the exceptions. An agent uses credits when:

A flow starts on its own. Free runs apply “only to runs triggered via the ‘When an agent calls the flow’ trigger”. A flow started by a schedule or an event is billed.
It gives generative answers outside Agent Builder. They’re billed “unless the agent is created in Agent Builder in Microsoft 365” and don’t use tenant graph grounding.
It uses computer use. “Computer-Using Agents (CUA) usage is not included in the Microsoft 365 Copilot USL.”
It calls APIs. The business pricing page: “Does not include cost of API calls, including Work IQ API calls.”
It uses Work IQ. The September 2026 Credits Guide: “Work IQ APIs are not included as entitlements in the Microsoft Copilot license.” The Tools API costs 0.1 credits per call. The Chat and Context APIs vary by query; the June edition gave examples ranging from 20 to 150 credits per query. Work IQ used inside Copilot itself (chat, the Office apps, Researcher, Analyst, Facilitator) carries no extra charge. The older Retrieval API and Chat API stay free for licensed users, and the guide says, “This licensing model will continue for now.” I wouldn’t count on that lasting.
It’s built on the GitHub Copilot harness. Copilot Studio now has three harnesses (Copilot Chat, Standard, GitHub Copilot). The GitHub one “Requires Copilot Credits for LLM-powered maker experiences”, even while you’re still building.
The user has no license. All of the free rules above apply to licensed users only.

Before anyone promises a business unit that “agents are included with Copilot”, go through each agent’s triggers, tools, channels, and users. Scheduled flows, computer use, Work IQ calls, the GitHub harness, and unlicensed users all cost credits.

What a Copilot Studio agent costs per action

When an agent does use credits, Billing rates and management (updated August 3, 2026) sets the rates. These are for the Standard harness.

Action	Copilot Credits
Classic answer	1
Generative answer	2
Agent action	5
Tenant graph grounding	10
Agent flow actions	13 per 100 actions
AI tools, basic / standard / premium	1 / 15 / 100 per 10 responses
Content processing	8 per page
Voice, classic / GenAI / premium GenAI	10 / 35 / 75 per minute

The same page has four more rules that change the result:

Reasoning models cost extra: “Total cost = feature rate for the operation + text and generative AI tools (premium)”, and the premium rate is 10 credits per 1,000 tokens.
Computer use is charged at the agent action rate.
Your own models are billed separately: the rates “exclude bring-your-own-model configurations, including Azure Foundry models”.
Prepaid capacity has a hard limit: “Enforcement is triggered when a tenant reaches 125% of their prepaid capacity.” Custom agents then stop, and agent flows are blocked once capacity runs out.

Copilot Studio licenses

If you buy capacity packs, each pack is the tenant license: $200 for 25,000 credits a month. On top of that, “A Copilot Studio User License ($0) is required for each user that builds” agents, and Learn says you first need “a Copilot Studio tenant prepaid Copilot Credit pack subscription”. If you pay as you go or pre-purchase instead, makers don’t need a user license. They need the “Copilot Studio Author role”, a free security group in the Power Platform admin center.

The September guide’s change log lists a few more changes:

three harnesses since August 2026, with the standalone Copilot Studio license adding the GitHub harness, external channels, and users without a Copilot license;
“Default Dataverse Database capacity increased from 5 GB to 15 GB” in December 2025;
Managed Environments included in the “Copilot Studio for Microsoft Copilot license”, “only for features related to Copilot Studio”;
Apps built in Copilot Studio in paid public preview since September 2026, “billed through Copilot Credits”.

Announced, but not yet dated

Several changes from September 25 still have no firm date.

Usage limits on the license. The Learn page describes users who “Reach usage limits in the USL (coming soon)”. They’ll see a notice as they approach the limit. After the limit, “they have the option to continue with UBB by consuming Copilot Credits or, if applicable, reroute to Auto to continue their work.” The same page says some models are “included with fair use, such as GPT 5.6 and Sonnet, and others included with limits, such as Opus.”

There’s no date for the usage limits yet. When they arrive, part of what people do today at the flat license price will start costing credits. If you budget for 2027 now, leave room for that.

Better cost controls. The blog says cost management in Agent 365 “is expanding beyond Cowork and Work IQ APIs to include Code and Copilot Managed Runtime, with support for agents built in Microsoft Copilot Studio planned for October.” Admins get more control over spending policies and model choice, and users can see their own credit balance in Copilot. I’ll go through these in the next post.

New services join your billing policy automatically. Usage-Based Billing and Cost Management for Copilot Credits says: “The Auto-apply new services setting is enabled by default”. When Microsoft moves another feature onto credits, it can start using your budget without anyone deciding it should.

Partner purchases. Microsoft has moved this date. New Copilot Business licenses bought through a CSP partner will have pay-as-you-go credits switched on from December 1, 2026, not November 2 as first announced. The Partner Center announcement for October 2026 adds two details. The default limit is “4,000 Copilot Credits per user per month”, which admins can change. That’s up to $40 per user per month at the pay-as-you-go rate. And the change “will initially not be available” in several markets, including Germany, France, Italy, Spain, and the Netherlands.

Ignite. Microsoft points to Ignite, November 17–20, 2026, for the next round of news. Prices may move again after that.

Before the next budget round

Prices alone won’t give you a budget, but they will help you make a few decisions now.

Plan two budgets. One for base plans and Copilot licenses, fixed per user. One for credits, which depend on usage. If you bought Copilot Business at the discount, use the full price from year two.
Decide who owns the credit budget. Microsoft suggests business units. Agree on it before anyone switches on Cowork, Code, or Autopilot.
Don’t pre-purchase yet. Pay as you go for a few months, then buy a Pre-Purchase Plan based on real numbers. The purchase is final.
Buying through a partner? Talk to them before December 1, 2026, about how pay-as-you-go will be set up for new Copilot Business licenses, and agree whether the default limit of 4,000 credits per user per month suits you.

The price list only tells you what you could pay. What you actually pay depends on how you run things, and that’s what the next post in this series covers: where each of these costs appears, which admin center shows it, how to set billing policies and spending limits, how to charge costs back to the teams that cause them, and what to do once Microsoft puts a date on the usage limits.

Sources

Official Microsoft Blog, Introducing the new Copilot with Home, Code and Autopilot, September 25, 2026: the license and usage-based billing split, Code and Autopilot timelines, cost management expansion, admin and user controls, Ignite dates
Microsoft Learn, Understanding the user subscription license (USL) and usage-based billing (UBB), last updated September 25, 2026: everyday and advanced AI, UBB requires a USL, billing policy requirement, funding by business units, usage limits “coming soon”, model inclusion
Microsoft Learn, Usage-Based Billing and Cost Management for Copilot Credits, last updated September 25, 2026: auto-apply setting
Microsoft, Microsoft Copilot Plans and Pricing – AI for Business, read October 1, 2026: Copilot Business prices, discount terms, bundles, Cowork “Metered”, API calls excluded
Microsoft Germany, Microsoft 365 Copilot for business, German page, read October 2, 2026: euro prices for Copilot Business and bundles, discount dates, prices excluding VAT
Microsoft, Microsoft Copilot Plans and Pricing – Enterprise, read October 1, 2026: feature matrix, voice limits
Microsoft, AI for Enterprise Productivity - Microsoft Copilot, read October 1, 2026: $30.00 and $31.50 prices, qualifying plan requirement
Microsoft Germany, Microsoft 365 Copilot for enterprise, German page, read October 1, 2026: €26.00 price, no monthly euro price shown
Microsoft Germany, Copilot Studio pricing, German page, read October 1, 2026: €173.30 in the comparison table, pack price missing in the FAQ
Microsoft Learn, License options for Microsoft Copilot, last updated September 17, 2026: eligible base plans
Microsoft Learn, Manage Microsoft Copilot Chat, last updated September 24, 2026: rename to Microsoft Copilot, Copilot Chat at no extra cost
Microsoft Learn, Overview of Microsoft Copilot Chat, last updated September 10, 2026: the three Copilot labels
Microsoft Support, What Copilot license do I have, April 2026: the three Copilot labels
Microsoft Learn, Meters for Microsoft Copilot pay-as-you-go services, last updated August 18, 2026: $0.01 rate for agents in Copilot Chat
Microsoft Learn, Standard harness licensing – Copilot Studio, last updated August 3, 2026: messages renamed to credits, zero-rated usage, user license prerequisite
Microsoft Learn, Billing rates and management – Copilot Studio, last updated August 3, 2026: rates per action, reasoning surcharge, computer use, 125% limit, free use for licensed users
Microsoft, Microsoft Copilot Studio Licensing Guide – October 2026, October 2026: pack price, pre-purchase tiers, Agent Pre-Purchase Plan, $0 user license, Author role, harnesses, change log
Microsoft, Copilot Credits Guide – September 2026, September 2026: credits as common currency, pay-as-you-go rate, pre-purchase tiers, Work IQ not included in the license, Tools API rate, no extra charge for Work IQ inside Copilot
Microsoft, Copilot Credits Guide – June 2026, June 2026: no Cowork entitlement in the license, Cowork and Work IQ example credit ranges
Microsoft Learn, Copilot Credit P3 – Microsoft Cost Management, last updated July 17, 2026: purchases are final, expiry at end of term
Microsoft Copilot Blog, Scale your agent rollout with confidence: Introducing Copilot Credit Pre-Purchase Plan, October 27, 2025: introduction of the Pre-Purchase Plan
Microsoft Copilot Blog, Microsoft 365 Copilot Business: The future of work for small businesses, December 2, 2025: launch and $21 price, bundle offer until June 30, 2026
Microsoft Copilot Blog, Advancing Microsoft 365: New capabilities and pricing update, December 4, 2025, updated March 18, 2026: announcement of the July 1, 2026 price change, Copilot Chat features
Microsoft Germany, Microsoft 365 Enterprise plans and pricing, German page, read October 2, 2026: E3 €37.78, E5 €58.13, Agent 365 €13.00
Microsoft Germany, German pages for Business Basic (plan comparison), Business Standard, and Business Premium, read October 1, 2026: €6.07, €12.13, and €19.06
Microsoft Licensing, Microsoft 365 Pricing and Packaging Updates, February 16, 2026: old and new base plan prices, effective date
Microsoft Licensing, Microsoft 365 Packaging and Pricing Updates Public FAQ, March 24, 2026: Copilot excluded, E7 unchanged, prices kept until renewal
Official Microsoft Blog, Introducing the First Frontier Suite built on Intelligence + Trust, March 9, 2026: E7 contents and price, Agent 365 at $15, Cowork research preview
Microsoft, Microsoft 365 E7 for Enterprise and German page, read October 1, 2026: $99.00 and €91.92 prices, E5 at $60.00 and €58.13, metered agents footnote
Microsoft Copilot Blog, Copilot Cowork is now generally available, June 16, 2026: general availability, credit billing, example task costs, grace period, off by default
Microsoft Learn, What’s new in Copilot Cowork, last updated September 25, 2026: model change at launch
Microsoft Learn, October 2026 announcements – Partner Center, last updated October 1, 2026: pay-as-you-go default for new CSP Copilot Business licenses moved to December 1, 2026, default limit of 4,000 credits per user per month, markets where it starts later
Microsoft SharePoint Blog, What’s new in Copilot in SharePoint: October 2026, October 1, 2026: general availability from September 30, 2026, image generation and editing, advanced autofill, and site analytics use Copilot Credits

Changelog

Date	Change
October 2, 2026	Rev1. Renamed to “Understanding Microsoft Copilot Licensing - Rev1” and described as a living series. Partner (CSP) pay-as-you-go default moved from November 2 to December 1, 2026, with a default limit of 4,000 credits per user per month and a later start in Germany and other markets. Added the Copilot in SharePoint features that use credits. Sources moved to the Copilot Studio Licensing Guide (October 2026) and the Copilot Credits Guide (September 2026). Prices re-checked on the US and German pages: no changes. Removed the series intro at the top.
October 3, 2026	First published. Prices checked against Microsoft’s US and German pages on October 1, 2026.

Date

Change

October 2, 2026

Rev1. Renamed to “Understanding Microsoft Copilot Licensing - Rev1” and described as a living series. Partner (CSP) pay-as-you-go default moved from November 2 to December 1, 2026, with a default limit of 4,000 credits per user per month and a later start in Germany and other markets. Added the Copilot in SharePoint features that use credits. Sources moved to the Copilot Studio Licensing Guide (October 2026) and the Copilot Credits Guide (September 2026). Prices re-checked on the US and German pages: no changes. Removed the series intro at the top.

October 3, 2026

First published. Prices checked against Microsoft’s US and German pages on October 1, 2026.

Prompt Libraries Are Reusable Text - Skills Are Reusable Expertise

Holger Imbery — Sat, 19 Sep 2026 00:00:00 +0000

Every organization I work with has built a prompt library, and almost every one of them has watched it rot. Custom skills for declarative agents are the first mechanism in this ecosystem that fixes the cause rather than the symptom. This article explains what a skill really is, why it beats a prompt, and why you should build your first five in Agent Builder instead of reaching for Copilot Studio.

Every prompt library dies the same death

Most companies do the same thing in the same order. They buy Copilot licenses. They run training sessions. Then someone builds a prompt library.

It usually lives in SharePoint. It has a nice front page. It holds forty to four hundred prompts with names like Write executive summary or Create project kickoff.

For about six weeks, it works well.

Then it falls apart.

Someone improves prompt #17 and tells nobody. A second copy shows up in a Teams channel. A third gets pasted into an onboarding deck. A helpful colleague rewrites it for their own team. Now nobody knows which one is the real one, nobody tests any of them, and the quality a user gets depends on which copy they happened to find.

You cannot fix that with better folders. The problem is the thing itself. A prompt is just text.

A prompt library gives you reusable content. What it never gives you is reusable behavior — and behavior is what companies actually want to make consistent.

A skill is a folder, and that is the point

Custom skills for declarative agents are in preview right now, and the concept is almost disappointingly simple. A skill is a folder.

project-kickoff/
├── SKILL.md # required
├── templates/
│ └── kickoff-template.docx
├── references/
│ ├── project-methodology.md
│ └── governance-checklist.md
└── scripts/
    └── build-milestone-table.py

Only one file is required: SKILL.md. It holds the skill’s name and description in YAML front matter, plus the instructions that tell the model how to do the task. Those instructions must stay under 20,000 characters. Everything else — templates, reference material, scripts — is optional. And that optional part is where it gets interesting.

Microsoft describes a skill as “a modular capability that you add to a declarative agent to help it accomplish a specific task more reliably and repeatably.”

Look at those two words: reliably and repeatably. Not smarter. Not faster. Those are the words you use for a business asset, not a clever trick.

Microsoft just retired the way we taught this in 2025

There is a line in the documentation that deserves more attention than it is getting:

“Custom skills are a new, distinct component of a declarative agent. In earlier guidance, the word skills referred to task descriptions that you wrote inline within an agent’s instructions. Custom skills replace that approach.”

That is Microsoft ending the old habit of writing longer and longer instructions. Everything many of us taught last year — put the whole method in the instruction box, structure it with headings, hope the model keeps paying attention to all of it — is now the old way.

If you have ever written a long instruction block, you know the failure mode. The more you add, the more the earlier rules quietly stop being followed. There is a reason declarative agent instructions are capped at 8,000 characters.

The agent only loads a skill when it needs it

This is the most important technical reason a skill beats a prompt, and the one people skip past.

An agent does not load a skill until the task calls for it. The instructions and the files come into context on demand. Microsoft calls this progressive disclosure. The practical effect is that the agent stays focused even when you have many skills.

Here are the two shapes side by side:

Prompt library Skills
-------------- ------
Agent instructions Agent
  40 pages of method ├── Contract Review
  loaded on every single turn ├── Business Case
  all competing for attention ├── Risk Assessment
                                ├── Project Charter
                                └── Executive Briefing
                                (loads only what it needs)

Each skill gets its own 20,000-character budget, on top of the agent’s 8,000-character instructions — and it only costs you context when it is actually in play. That is not a small convenience. It changes how far you can scale before quality degrades.

Scripts beat improvised code

If a skill includes a script, the agent runs that script. It does not write fresh code each time and hope the math comes out the same.

For an ROI model, a scoring matrix, or a chart that must look identical in every business case going to the board, this is the difference between “usually right” and “provable”.

The sandbox those scripts run in is deliberately narrow, and you should know the limits before you promise anything:

Capability	Supported?
Internet or network access	No — no network access at runtime
Installing packages at runtime	No
Authenticated network calls	No
Packages already in the sandbox	Yes, but do not depend on one unless you confirmed it
Calling connectors, API plugins, MCP servers from a script	No — the agent can use them through the orchestrator, the script cannot

Supported script types are .py, .js, .mjs, .cjs, .ts, .mts, .sh, and .bash.

Those limits look restrictive written out like that. In practice they are exactly what a security architect needs to hear before approving anything, and they rule out almost nothing that a document-producing skill wants to do.

The knowledge travels with the behavior

A prompt can describe your template. A skill can contain it.

The approved Word file, the wording list, the governance checklist, the KPI definitions — all inside the package, sitting next to the instructions that know how to use them. A skill can carry Office documents, PDFs, Markdown, CSV, images, and structured data files, up to 350 files across all skills on an agent.

Sensitivity labels on those files are retained and honored. A labeled template does not stop being labeled because it sits inside a skill. Uploaded skill files are stored in tenant-scoped SharePoint Embedded containers — inside your tenant, under your control. User-defined permissions and Double Key Encryption are not supported in the sandbox.

The comparison, stated plainly

Prompt library	Skill
The user has to find the prompt	The agent finds the skill
The user pastes it in	Used automatically
Plain text	Instructions, files, and scripts
Hard to govern	A versioned package
Cannot be tested	Can be tested
Loaded every time	Loaded only when needed
Knowledge buried in text	Knowledge packed with behavior

A normal user should never know what a skill is

This is the part I care about most, and the part that usually gets lost in architecture debates.

The whole experience should be this:

Create a project kickoff document.

That is all. No prompt library. No searching. No copy and paste. No wondering which version is current. The agent recognizes the task, loads the kickoff skill, and the user gets the right structure, the right terminology, the required sections, and the right tone — without learning anything new.

Every time we ask users to understand the system before they can get good output, adoption drops. Skills are the first thing in this ecosystem that reliably moves the complexity out of the user’s head and into the asset.

Five skills I would build first

1. Executive briefing

Background, current status, risks, decisions needed, recommendation. The same shape every time. Leadership stops receiving five different interpretations of the word “summary”.

2. Meeting outcome

Not notes. Outcomes: executive summary, decisions, actions with owner and due date, open risks, items for escalation. The difference between a record of what was said and a record of what was decided.

3. Business case

Current state, future state, benefits, risks, financial model, ROI. This one earns its script — the ROI calculation belongs in a .py file, not in a fresh guess inside every document.

4. Architecture decision record

Context, decision, alternatives, consequences, risks, review date. Architects will like this one most, because an ADR that keeps changing shape is an ADR nobody can read three years later.

5. Project health check

Schedule, budget, scope, risks, dependencies, stakeholders — with explicit rules for green, amber, and red in the reference files, so “amber” means the same thing in Hamburg and in Lisbon.

Notice what those five have in common. None of them are clever. They are consistent. That is the entire point.

You do not need Copilot Studio for any of them

Whenever I present this, someone from the platform team says: fine, we will build these in Copilot Studio so we can govern them properly.

For these scenarios, that is the wrong reflex — and Microsoft’s own guidance agrees.

Look at what those five skills actually do. They draft, structure, summarize, assess, and format content the user can already see in Microsoft 365. They do not raise tickets. They do not write into SAP. They do not run unattended overnight. They do not need to appear on a public website or in WhatsApp. They do not branch through approval flows.

Microsoft draws the line clearly. Choose Agent Builder when you want to quickly create an agent for yourself or a small team, using natural language and existing content. Choose Copilot Studio when you need a broader audience, multi-step workflows, custom integrations, autonomous behavior, or lifecycle management across environments.

All five skills above sit on the Agent Builder side of that line.

	Agent Builder	Copilot Studio
Audience	Individuals or small teams	Department, organization, or external customers
Typical agent	Lightweight Q&A and content work on organizational knowledge	Multi-step workflows, business system integration, autonomous scenarios
Extra license	None beyond Microsoft 365 Copilot	Requires a Copilot Studio license
Governance home	Microsoft 365 admin center	Power Platform admin center, with finer-grained controls
Skills per agent	8	n/a
Skill package	`.zip`, up to 50 MB, 25 MB per file	n/a

Two more practical points in Agent Builder’s favor. You can ask it to create a skill from a plain description — describe the repeatable workflow you want packaged, then check what it produced under Configure → Skills. And you can upload a complete .zip you built yourself, which is the route I would take for anything that carries a real template.

One warning on that upload: you must upload the complete .zip. Uploading SKILL.md on its own does not work, and building a skill from individual file uploads is not supported in Agent Builder. If you work in the Microsoft 365 Agents Toolkit instead, the rule inverts — there you add the skill directory, and .zip is not supported.

The escape hatch that removes the last objection

The strongest argument for starting in Agent Builder is that you can reverse it.

You can copy an agent created in Microsoft 365 Copilot into Copilot Studio when you need advanced capabilities or broader integration. The core configuration and instructions are preserved. You do not start over.

So choosing Agent Builder is not a decision you have to defend for the next five years. You revisit it the day a skill genuinely needs a connector, a workflow, or an external channel.

My rule, stated plainly:

If the skill produces a document, an assessment, or a decision record — Agent Builder. If the skill has to touch another system — Copilot Studio.

Pushing a business case skill through Copilot Studio does not make it better governed. It makes it slower to build, more expensive to license, and dependent on a team that has real integration work waiting.

The honest caveats

It would be unfair to sell only the good side. This is a preview , and it behaves like one.

Frontier Program required Custom skills are in preview for organizations in the Microsoft Frontier Preview. Not every tenant qualifies.

Not available with Information Barriers Custom skills are not available in tenants that use Microsoft Purview Information Barriers. The restriction applies to both admin-deployed and user-created declarative agents.

No ISV distribution yet Support for independent software vendors to publish declarative agents with custom skills through Partner Center is not available yet. Microsoft explicitly tells ISVs not to submit such packages.

Scripts have no network access Covered above, but worth repeating because it catches people who assumed a script could call an API.

Skills and uploaded files don’t mix yet More on that below.

Sharing one skill across several agents isn’t supported yet More on that below too, because it is the question I get in every room.

“Not shared” does not mean “only once”

Let me answer the question directly, because the documentation does not.

The support matrix has a single row — reuse across agents: not supported at this stage of the preview — for both Agent Builder and the Agents Toolkit. That is the whole statement. No rule says a .zip may only be uploaded once.

So: nothing stops you from uploading the same project-kickoff.zip to three different agents. You can do that today. What you get is three separate copies , not one shared skill. The row is about linking, not uploading. No central skill library that several agents point to. A skill belongs to the agent you uploaded it to.

Why that matters in daily life: fix a small mistake in the ROI script, and you have to upload the file again to every agent that uses it. Nothing tells you which agent carries which version. A few months later, one agent is on version 3, and another is still on version 1 — and you are back where the prompt library left you, just with tidier files.

So keep the master copy outside Copilot: in Git, or in one properly governed SharePoint library. Treat every upload as a delivery from that master, never as the original. When real sharing arrives, you reconnect instead of rebuilding.

The most exciting version of this story — one project-kickoff skill used by the HR onboarding agent, the PMO agent, the transformation agent, and the portfolio agent at the same time — is where this is going. It is not where we are today.

The thing about uploaded files

One more limit worth planning around. Right now, an agent cannot have both skills and uploaded files. Microsoft lists this under known issues and says support is planned.

“Uploaded files” means files you upload to the agent from your own computer, under Knowledge on the Configure tab. Microsoft calls them embedded files. The content is copied into the agent exactly as it is at that moment. That is different from pointing the agent at a file in SharePoint or OneDrive, where the agent keeps reading the live document and picks up your later changes.

So if your agent already has files uploaded that way, you cannot simply add a skill to it yet. You have two options: point the agent at the same content in SharePoint or OneDrive instead, or put those files inside the skill package.

The second option is the better design anyway. A template or a list of definitions belongs right next to the instructions that use it — not in a separate pile of knowledge the agent has to work out how to apply.

Why this matters more than it sounds

Power Automate did not become important because flows were technically novel. It became important because it gave business automation a packaging format — something you could name, version, own, hand over, and audit.

Skills are that moment for enterprise know-how in Copilot.

Champions stop being prompt authors and become capability authors. Instead of teaching a thousand people to use prompt #17 correctly, you publish project-kickoff once, and everyone who comes after benefits without being taught anything.

Prompt libraries standardize what users type. Skills standardize how the work gets done.

What I would check before shipping

If you are going to start this month, work through this list first.

Confirm you are in the Frontier Preview , and confirm you are not running Purview Information Barriers. Those two answers decide whether the rest of the list matters at all.

Pick one skill, not five Take the document your organization produces most often and argues about least. Executive briefing is usually the right first move.

Put the master in source control before the first upload This is the single habit that prevents the prompt-library failure from repeating itself.

Move the templates into the package If the agent currently has uploaded files, that is a blocker today — and moving them into the skill is the better design regardless.

Write the description as a trigger, not a label The description in the YAML front matter is how the agent decides to load the skill. “Create approved project kickoff documents, including objectives, scope, stakeholders, governance, risks, milestones, and success metrics. Use whenever a user wants to start a project” works. “Kickoff skill” does not.

Test it with a user who has never heard the word skill If they have to be told the skill exists, the description is wrong.

Do not route it through Copilot Studio because it feels more serious Route it there when it has to touch another system. Until then, Agent Builder, no code, no extra license.

If you take one sentence to your next steering committee, take this one: prompt libraries are reusable text, skills are reusable expertise.

One thing to verify in your own tenant: the entire feature is in preview and behind the Frontier Program, so the limits quoted here — 8 skills per agent, 50 MB per package, 350 files, 20,000 characters of skill instructions — are the numbers documented on 4 September 2026 and are the kind of thing that moves during a preview. Check them against Microsoft Learn before you build a rollout plan on top of them.

Sources

Microsoft Learn, Custom skills in declarative agents (preview), last updated 4 September 2026: the definition of a skill, the “custom skills replace that approach” wording, progressive disclosure, the support matrix including the 8-skill and 50 MB limits, supported file and script types, the sandbox restrictions, sensitivity labels and SharePoint Embedded storage, the Frontier Preview and Information Barriers restrictions, the ISV note, the “reuse across agents: not supported” row, and the known issue about skills and embedded files
Microsoft Learn, Add custom skills to your declarative agent in Agent Builder (preview), last updated 4 September 2026: creating a skill from a natural-language description, the upload flow under Configure, the requirement to upload the complete .zip rather than SKILL.md alone, and the prerequisites
Microsoft Learn, Choose between Agent Builder in Microsoft 365 Copilot and Copilot Studio to build your agent, accessed 19 September 2026: the audience, agent type, capability, governance, and licensing comparison, and the ability to copy an agent from Microsoft 365 Copilot into Copilot Studio with configuration and instructions preserved
Microsoft Learn, Choose the right tool to build your declarative agent, accessed 19 September 2026: the no-code, low-code, and pro-code positioning of Agent Builder, Copilot Studio, and the Microsoft 365 Agents Toolkit, and the licensing prerequisites for each
Microsoft Learn, Add knowledge sources to your declarative agent, accessed 19 September 2026: embedded file content as a distinct knowledge source, supported in Agent Builder but not in the Agents Toolkit

Long-Running Business Processes in Copilot Studio: State Tables, Agent Flows and Multi-Agent Orchestration

Holger Imbery — Sun, 13 Sep 2026 00:00:00 +0000

How I built long-running processes, like invoice processing or purchase order handling, with the standard harness — no custom middleware, no side platform.

Why I stopped thinking in conversations

The first thing I had to unlearn in my projects was the idea that an agent is a conversation. A conversation is short, synchronous, and forgettable. A business process is none of those things. An invoice arrives on a Tuesday, sits in an approval queue for four days, gets rejected because a purchase order number is missing, comes back on Monday, and finally posts to the backend system (if there is any) two weeks after it first landed in the mailbox.

Nothing in that story fits into a chat turn. But it all fits into a state table.

My way of working is simple: the agent is not the process. The agent is a worker that picks up work, does one well-scoped thing, writes down what it did, and moves the item to the next state. The process lives in Dataverse. That single decision made long-running automation reliable for me — and I build everything I describe here with the standard harness: Copilot Studio, agent flows, Dataverse, connectors. No custom orchestration layer, no separate runtime to operate.

The state table is the process

Every long-running process I run has one central Dataverse table. For invoice handling, I call it Invoice Case. It is deliberately boring:

Column	Purpose
`CaseId`	Business key, used in every message and log line
`State`	Choice column — the only authority on where the item stands
`SubState`	Optional refinement inside a state (e.g. waiting on supplier)
`AssignedAgent`	Which specialized agent currently owns the item
`Attempts`	Retry counter, guards against loops
`NextActionAt`	When the item should be looked at again
`Payload`	Extracted structured data as JSON
`Confidence`	Extraction confidence, drives the human-in-the-loop branch
`LastError`	Plain-language reason for the last failure
`AuditTrail`	Append-only log of state transitions

The state list for invoices, in the order I actually use it:

Received → Classified → Extracted → Validated → Matched → PendingApproval → Approved → Posted → Closed

plus the two states that carry all the real-world mess: NeedsHuman and Failed.

Two rules I do not break:

Only one component may write State at a time Transitions go through a single agent flow that takes the current state and the requested target state, validates the transition against an allowed-transition list, and writes the new row version. Everything else reads state and proposes transitions.
Every transition is written before the side effect, and confirmed after it If the backend system posting call dies halfway, I want the table to say Posting with an attempt count, not Approved forever.

That is idempotency in practice. Because the state table is the source of truth, a retry is never a duplicate — it is a re-read of a row that already knows how far it got.

The orchestrator agent

An orchestrator sits on top of the table. It is a Copilot Studio agent with a deliberately thin job description: read the case, decide which specialist should handle the current state, hand over, and write the result back. It has no domain knowledge about VAT rules or supplier master data. It knows states and routing.

I give it exactly three kinds of tools:

an agent flow GetNextCases — pulls cases whose NextActionAt is due, ordered by priority
an agent flow TransitionCase — the guarded write described above
connected child agents , one per specialist capability

The orchestrator’s instructions are a routing table in prose, not a personality. Something like: “If State is Received, hand the case to the Classification agent. If State is Classified and the document type is Invoice, hand it to the Invoice Extraction agent. If confidence is below the threshold, transition to NeedsHuman and notify the queue owner.” Short, testable sentences. When routing gets more complex than that, the complexity belongs in the flow, not the prompt.

The trigger side is equally boring and equally important. Three entry points cover almost everything I have built:

Event-driven — a new mail with attachment, a file dropped into SharePoint, a Dataverse row created.
Scheduled — a recurring agent flow that sweeps due cases. This heartbeat makes “long-running” work possible. A process that waits four days does not need a session that stays open for four days; it needs a table row with a date and a sweeper.
Human-driven — an approver replies, a clerk fixes a field, someone asks the agent in Teams “where is invoice 4711?” and gets the state, the history, and the current blocker.

The specialists

The specialist agents hold the domain knowledge, and each one is scoped small enough that I can describe its job in one sentence.

Classifier. Decides what the document is — Invoice, credit note, dunning letter, delivery note, something else entirely. Cheap, fast, and it keeps the expensive extraction work off documents that never needed it.

Scanned-document extraction agent This is the one people ask about most. Scanned PDFs and photographed invoices are a different problem from digital PDFs, and I treat them as such. The agent runs the document through OCR/document intelligence, then reasons over the recognized content to produce the structured payload: supplier, invoice number, invoice date, net, tax, gross, currency, PO number, line items, IBAN. It returns per-field confidence, not just values — and I persist that confidence, because it is the switch that decides whether a human ever sees the document.

Digital PDF extraction agent Same output contract, different path: text layer first, OCR only as fallback. Same JSON schema so that everything downstream is indifferent to how the data was obtained. Agreeing on one schema across all extraction paths is the single highest-leverage design decision in the whole solution.

Validator Arithmetic, tax plausibility, IBAN format, duplicate detection against previously posted invoices, supplier existence in master data. Deterministic checks belong in flows; judgment calls belong in the agent. I keep that line clean.

Matcher Purchase order and goods-receipt matching — two-way or three-way depending on the client. Produces a match result and a deviation list, never a decision on its own.

Approval agent Determines the approver from amount, cost center, and delegation rules, sends an adaptive card, and waits. “Waits” here means: writes PendingApproval, sets NextActionAt for the reminder, and stops. Nothing stays in memory.

Posting agent Talks to the backend system through a connector, with the write-before/confirm-after pattern.

Communication and alerting agent Manages SLAs, deadlines, and escalations. When a case breaches its SLA target or an approval sits unattended, it sends reminders via Teams or email, escalates to backup approvers, and records every notification in the state table.

Supplier inquiry agent triggers an email back to the invoice sender whenever essential data is missing or invalid — like an absent PO number, unverifiable tax ID, or mismatched line items. It specifies the exact issue, attaches the reference, transitions the case to WaitingForSupplier, and sets a deadline so the process parks cleanly until a reply arrives.

Each specialist gets the case ID and reads what it needs from the table. I deliberately avoid passing large context between agents. The state table is shared memory: queryable, auditable, and survives restarts—three things a conversation context does not.

What the state table gives me beyond orchestration

Once the process lives in Dataverse, many things I used to build separately come for free.

Observability. A Power BI report over the state table is the process dashboard: how many invoices sit in each state, average dwell time per state, which supplier produces the most NeedsHuman cases, which extraction fields have the lowest confidence. That last one is my improvement backlog, generated automatically.

Human-in-the-loop that scales NeedsHuman is a queue, and a model-driven app over the same table is the clerk’s workplace. The agent prepares, the human decides, the agent continues. No screenshots, no re-keying.

Safe evolution Adding a new step to the process means adding a state and a specialist. Nothing else changes, because nothing else knew the process shape to begin with.

Explainability When someone asks why invoice 4711 took eleven days, the audit trail answers with timestamps and reasons. That conversation used to be the hardest part of the project.

What made the difference

Design the state list on paper, with the business, before touching the maker portal. If the states are wrong, no amount of prompt engineering rescues the solution.
Keep every agent’s instruction short enough to read out loud. Long instructions are undebuggable.
Put deterministic logic in agent flows, judgment in agents, and truth in Dataverse.
Make every operation idempotent and every transition guarded.
Store confidence and route on it. Automation that knows when to ask for help gets trusted; automation that is confidently wrong once does not.
Start with one document type and one supplier group, run it in production, then widen.

The technology stack here is unglamorous on purpose. The interesting engineering isn’t in the agent—it is in the table that remembers what the agent did.

Multi-Agent Orchestration in Copilot Studio - Pick the Harness First

Holger Imbery — Sat, 05 Sep 2026 00:00:00 +0000

The last article was about workflows and the agent node. This one goes one level up. Copilot Studio now runs three harnesses, and the harness you pick decides which multi-agent building blocks you are even allowed to use. Child agents, connected agents, A2A, and MCP are not four flavors of the same thing, and they are not all available everywhere.

The one sentence that should govern the whole design

Harness first, architecture second. Not because it is elegant, but because Microsoft states plainly that agents “can’t be transferred to the standard harness, and vice versa”. There is no runtime toggle. A harness change is a rebuild, and every multi-agent mechanism you plan on depends on which runtime you started in.

Microsoft’s own definition of a harness is deliberately narrow: it is “a runtime that exists between the two” — the model and the agent’s configuration — and it “determines when to call the model, what components to send it”. The white paper published on 1 September 2026 phrases it as “the operating layer between the model and the agent’s configuration”. The consequential sentence follows immediately: “The harness you use affects the billing, features, and capabilities.”

Three harnesses, from the harnesses overview page (last updated 27 August 2026):

Harness	Microsoft’s framing	Built for	Billing
GitHub Copilot	“the most capable option, built for reasoning-heavy agents”	“Complex, multi-step business processes”	Copilot Credits, consumption-based
Standard	“a dependable option for rule-based agents”	“Rule-based agents and structured conversations”	Existing Copilot Studio licensing
Copilot chat	“allows you to extend Microsoft 365 Copilot Chat”	Enterprise knowledge in Chat	Consumption or included with M365 Copilot

The GitHub Copilot harness reached general availability with the announcement on 2 September 2026: “The GitHub Copilot harness is now generally available”. That is the status to plan against. Note what is not GA inside it — the same blog marks connected agents “(in preview)”, along with Work IQ, memory, and user file upload, while skills, workflows-as-tools, and MCP-as-tool are GA. The Learn page for connected agents carries no preview banner, which is the first of two documentation conflicts worth knowing about.

Read the banner, not the marketing

The most reliable capability map in Copilot Studio documentation is not a comparison table. It is the one-line banner at the top of each Learn article.

“This article describes features used in agents … powered by the standard harness.” appears on Add a child agent, Agent-to-agent (A2A), Connect to an existing agent, and Manage Entra Agent IDs.
“Features in this article are used by agents or workflows powered by the GitHub Copilot harness.” appears on Skills overview, Tools overview, Connected agents overview, Add an MCP server as a tool, and Files the agent creates.

Read those two lists again. The classic multi-agent toolkit — child agents, A2A, connecting external agent types — sits under the standard banner. The new stack — skills, sandboxed files, MCP-as-tool, the new connected-agents surface — sits under the GitHub Copilot banner. That is not a rollout accident I expect to be corrected next month; it is the current architectural line.

When do you need multi-agent orchestration at all

Before the harness question, the honest question: does this need more than one agent?

Microsoft’s own guidance gives a usable threshold. Split the agent when it exceeds roughly “more than 30-40 choices of action”. Below that, you are adding orchestration latency and a second thing to govern for no return. The multi-agent patterns page frames the benefit as modularity: one agent calling others makes solutions “more modular, scalable, and manageable”.

My working rule, in the order I actually apply it:

One agent, more instructions. Cheapest. Works until the instruction file becomes a policy manual nobody re-reads.
One agent, more skills (GitHub Copilot harness). A procedure that belongs to this agent and loads only when relevant.
One agent, child agents (standard harness). An embedded specialist that needs its own tool budget, typed inputs, and trigger.
Connected agents. Separate ownership, separate lifecycle, separate security boundary, or multiple parents consuming the same specialist.
A2A. The specialist is not a Copilot Studio agent at all.

Steps 2 and 3 are in-agent complexity. Steps 4 and 5 are cross-agent work. Conflating those two categories is the single most expensive modeling mistake I see, and it produces either an unmaintainable god-agent or an org chart of agents nobody can trace a request through.

Which element lives in which harness

Element	Standard harness	GitHub Copilot harness	Why
Child agents	Yes	No	Documented only under the standard banner; skills absorb most of the use cases
Connected agents (Copilot Studio)	Yes	Yes	Both harnesses; new harness restricted to Copilot Studio-built agents
Connected agents (Foundry, Fabric Data, M365 Agents SDK)	Yes	No	Only the standard harness documents the external agent types
A2A	Yes	Not documented	The A2A article carries the standard-harness banner; no GitHub Copilot-harness A2A article exists
MCP servers as tools	Yes (needs generative orchestration)	Yes	Both, but the new-harness page is still marked prerelease
Workflows as tools	Classic agent flows	Yes, GA	“Workflows can give agents access to multistep deterministic automation”
Skills	No	Yes	Skills are a GitHub Copilot-harness construct
Sandbox/file generation	No	Yes	Native creation and editing of Word, Excel, PowerPoint, and PDF
Memory	No	Yes (preview)	New-harness capability

The practical consequence is blunt. If you need to reach a non-Copilot Studio agent today — Foundry, SAP, ServiceNow, a partner agent, your own framework — that work belongs in the standard harness. The new-harness connected agents page states it directly: “you can currently only connect other agents built in Copilot Studio”. A2A, Fabric, and M365 Agents SDK multi-agent support went GA back in April 2026 — on the standard side.

Child agents: more than delegation

The child agent is routinely undersold as “a sub-agent”. Read the Add a child agent page (updated 25 August 2026), and it is closer to a topic with an orchestrator inside it. Microsoft defines it as “a lightweight agent that exists within the context of your main agent”, and inline agents “share context with the main agent” — a child always receives the parent’s context, with no opt-out.

What you actually get, and what no skill offers:

Triggers. By default, “agents respond to users or triggers, based on their description”. But you can bind explicit events: a message is received, a custom client event occurs, an activity occurs, the conversation changes, it’s invoked, it’s redirected to, the user is inactive for a while, a plan completes, an AI-generated response is about to be sent.

Explicit invocation. “It’s redirected to” makes the child callable from inside a topic — deterministic hand-off, not description matching. You can also reference it with / from instructions.

Typed inputs and outputs. Each input carries a display name, description, and data type, with an optional “Make this input required”. Outputs are typed the same way. This is a contract, not a prose hand-off.

Validation and reprompting. A “Should prompt user” toggle, a Condition with a “Condition not met prompt”, up to two reprompts, and an “Action if no entity found” that escalates, sets a value, or leaves it empty.

Power Fx. Switch the condition builder to the formula editor, and the routing decision becomes an expression.

Priority and ordering. “A lower number indicates a higher priority”; ties are resolved “in the order of creation (oldest first)”. Child agents and topics share the same trigger set, so priority is how you keep them from fighting.

Post-completion behavior. After running: don’t respond (the default), write the response with generative AI, send a specific response, or send an adaptive card.

Its own orchestration and its own tool limits. “Because child agents have their own orchestration, they have their own limits for the number of tools.” Microsoft calls that separate limit one of the benefits — it is how you partition a parent that has outgrown its tool budget. The stated price is latency, “added by the added layer of orchestration”.

That last pair is the real reason child agents survive. They are a tool-budget partition with a typed interface and conversational control, inside one agent boundary.

Skills: reusable behavior, not a reusable agent

A skill in the GitHub Copilot harness is a different species. Microsoft describes skills as “self-contained sets of instructions and logic”, explicitly contrasted with tools “which connect to external services”. Selection is by relevance: “The orchestration runtime invokes a skill when a user’s request matches the skill’s purpose.”

The package is deliberately boring: a SKILL.md with “a YAML front matter (name, description) and instructions”, plus “Optional supporting files, such as scripts, templates, and reference documents”, zipped. Authoring is Build → Skills → Create from blank (the name takes “only lowercase letters, numbers, and hyphens”) or drag-and-drop upload of a .md or a ZIP.

invoice-reconciliation/
├── SKILL.md # YAML front matter: name, description + Markdown instructions
├── scripts/
│ ├── compare_invoice.py
│ └── create_report.py
├── templates/
│ └── reconciliation-template.xlsx
└── references/
    └── matching-rules.md

Because it is Markdown in a ZIP, a skill goes in Git, gets reviewed in a pull request, gets versioned and released independently, and gets attached to several agents. That is the genuine advance over a child agent, which lives and dies inside its parent. It also means an existing GitHub Copilot or Claude-style skill is a plausible starting point, where its instructions and assets fit the Copilot Studio runtime.

The second advance is reviewed code. Instead of the model regenerating a transformation each run, the skill ships a script that was tested once and behaves the same way every time. For reconciliation logic, format validation, or document assembly, that is the difference between a demo and something finance will sign off.

Child agent versus skill, side by side

	Child agent (standard)	Skill (GitHub Copilot)
Boundary	Inside one parent agent	Inside one agent, but portable across agents
Reuse	Not reusable outside its parent	Created once, added to multiple agents, exported, source-controlled
Invocation	Description match, explicit redirect, or bound trigger	Description match by the orchestration runtime
Interface	Typed inputs and outputs, required flags, validation	Instructions in Markdown; no typed contract
Conversation control	Reprompts, conditions, priority, adaptive-card completion	None; the agent owns the conversation
Own tool limit	Yes — a separate orchestration budget	No — it uses the agent’s tools
Executable assets	No	Scripts, templates, reference files in the sandbox
Versioning	Part of the parent agent’s lifecycle	Independent — Git, review, release

Read across the rows, and the trade is clear. You give up the typed contract and the conversational controls, and you get portability, reviewed code, and file work. A skill is not a drop-in replacement for every child agent, and anyone telling you the migration is mechanical has not tried it on a child agent with required inputs and two reprompts.

Where a skill wins: the behavior belongs to one agent, the capability is essentially instructions plus transformation logic plus templates, you want to attach it to several agents, and you do not need an independently governed identity.

Where a child agent still wins: you need an embedded specialist with its own knowledge and tools, you need explicit input/output variables, validation, event triggers, priority or conversational completion, and you want the child-specific tool limit while keeping everything inside one main agent.

The two limitations of skills nobody reads until it hurts

This is the section I would put in front of any team that has just watched a skills demo.

1. A skill is not a connection

A skill does not authenticate. It does not hold a credential. It is not a connector, and it cannot become one. Microsoft’s own framing separates the two categories precisely: skills are “self-contained”, while tools “connect to external services”.

So a skill can hold the classification logic, the HTML template assembly, the field validation, the draft body. It cannot read the shared mailbox. Reading or writing that mailbox is a Graph-backed tool, a workflow, a custom connector, or an MCP server — configured on the agent, governed by the platform, visible to the admin. The script inside the skill cannot obtain a token independently.

2. Skill code has no outbound network path

The widely reported behavior of the agent sandbox is that code running in it cannot call Microsoft Graph, cannot call an arbitrary REST API, cannot connect to a database, cannot send mail, cannot download a package at runtime, cannot write to SharePoint, and cannot reach an MCP server over HTTP from the script itself. Even where a networking library such as requests is present, the code cannot use it to leave the sandbox. The filesystem is a working area, not durable storage.

Caveat, and I want to be precise about it: these specifics — no egress, the Python version, the preinstalled library count, the temporary filesystem — are currently documented in Microsoft’s community engineering blog, not on Microsoft Learn. Learn confirms only that tasks run “in a secure sandbox governed by Copilot Studio”, plus concrete numbers on the output side: created files are capped at 10 MB per file with 28-day retention. Design for no egress, because that is what the runtime does, but do not quote it as a compliance control in an architecture board paper until it lands on Learn.

The pattern that follows from both limits:

Agent reasoning
 |
 +-- Skill instructions
 | |
 | +-- Local script execution in the sandbox
 | +-- Local file transformation
 | +-- Validation and calculation
 |
 +-- Governed tool <-- the ONLY way out
      |
      +-- Microsoft Graph
      +-- Dataverse / SharePoint / Dynamics 365
      +-- External REST API
      +-- MCP server

The restriction is a feature. No arbitrary egress means no arbitrary exfiltration path, and every external operation stays visible through Copilot Studio tooling, Power Platform data policies, connector controls, and DLP. It also breaks lifted-and-shifted skills. A GitHub Copilot CLI skill happily assumes it can pip install, clone a repo, hit an endpoint, read an environment variable, query a database, or start a local service. None of those assumptions transfer. Every network-dependent part has to be refactored into a formal tool before the skill is worth anything in Copilot Studio.

MCP and A2A are not competitors

They answer different questions, and teams conflate them weekly.

MCP connects an agent to tools. It is “a standard for exposing tools to an agent”. In the new harness you add one at Build → Tools → Add → Model Context Protocol, giving a name, description, server URL and authentication. On the standard side you must turn on generative orchestration to use MCP at all. Two limits worth planning around: “MCP servers count against the total number of tools”, and the number of concurrent instances “is capped” — Microsoft states the cap exists but publishes no integer. Governance is inherited: blocking Power Platform connectors in DLP “also blocks access to tools in connected MCP servers”.

A2A connects an agent to another agent. It is “an open standard for communication and collaboration between agents”, and it lets Copilot Studio “delegate tasks to another agent, not just call APIs”. Configuration is Agents → Add agent → A2A agent, where you supply the endpoint URL and the agent card is read from .well-known automatically. Authentication is none, API key, or OAuth 2.0. Two details that matter operationally: “A2A connections use the custom connector infrastructure”, so your existing connector governance applies; and the payload carries “Full chat history, not just the latest user utterance” — read that sentence again before you delegate to a partner agent outside your tenant.

And once more, because it is the single most load-bearing constraint in this article: A2A is documented for the standard harness only. There is no GitHub Copilot-harness A2A article as of early September 2026.

Connected agents in both harnesses

Connected agents exist on both sides, with different reach.

Definition is common: “separate agents with their own orchestration, tools, and knowledge”, and they “can bypass plan limits” — which is the second tool-budget escape hatch after child agents.

On the standard harness you add one at Agents → Add an agent → Copilot Studio. The source agent must be in the same environment, published, and have “Let other agents connect to and use this one” enabled. You choose whether to hand over context with the “Pass conversation history to this agent” option — the contrast with a child agent, which always receives the parent’s context, is exactly the security boundary you want when the specialist is owned by another team. Documented limits: an agent that has its own connected agents “can’t also use the same agent as a connected agent” elsewhere, and “Redirecting to Fabric Data agents isn’t currently supported”.

On the GitHub Copilot harness, connected agents are the principal delegation mechanism, and the orchestrator does more with the result than fire-and-forget. It folds connected-agent output back into a broader working context alongside files, tool results, and intermediate artifacts, and then decides whether to continue, retry, take another path, or stop. That continued orchestration is the actual difference from a single delegated call. The price is the restriction already noted: Copilot Studio agents only.

Vocabulary, because half the arguments are terminological

I use these five definitions on every engagement, and they end most of the debate:

Skill — behavior belonging inside one agent.
Connected agent — separately owned expertise, security boundary, lifecycle, or a reusable specialist with more than one consumer.
Child agent — an embedded specialist with typed contracts and its own tool budget, inside one parent, standard harness only.
Workflow — a deterministic multi-step process.
Tool — access to an external capability or system. Including MCP. Including the only way out of the sandbox.
Knowledge — information the agent may retrieve and reason over.

In-agent complexity becomes skills. Cross-agent work stays a connected agent. Everything that leaves the tenant boundary is a tool or A2A.

Money and identity, before the design review

Billing is the harness distinction with the sharpest edge. On the GitHub Copilot harness, “All usage is billed based on consumption and measured in Copilot credits”, covering “large language model (LLM) tokens, tools (including knowledge and MCPs), and the harness itself”. The timing is what catches teams: “Billing starts when you start building”, against the standard harness “which starts billing after publish”. Building, testing, and evaluating are all metered. The Power Platform admin guidance is equally direct — GitHub Copilot-harness agents are not covered by a Microsoft 365 Copilot license, they are “Billed for all usage”, the admin agent inventory now carries a Harness column, and developer and trial environments moved to usage-based billing on 1 September 2026.

Identity is now automatic. “Copilot Studio automatically creates a Microsoft Entra Agent ID for each new agent,” and you “can no longer opt out”. Connector permissions are “re-validated at runtime against Advanced Connector Policies (ACP) and DLP”. A dating conflict to be aware of: Learn says this changed “After May 2026”; the September blog says “as of July 2026”. Either way, plan for it rather than discovering it in a governance review.

DLP reaches skills too. Skills can be blocked wholesale at tenant level through the “Skills with Copilot Studio” connector classification, the same mechanism that governs HTTP, Power Platform connectors as tools, MCP, knowledge sources, channels, and event triggers.

The architecture I actually recommend

Not a migration. A portfolio.

Standard harness
 |
 +-- Front-door conversations, mandatory question sequences, validation
 +-- High-volume FAQ, intake, routing, support, case creation
 +-- Deterministic routing with topics, Power Fx, adaptive cards
 +-- A2A to Foundry, SAP, ServiceNow, partner and custom agents
 +-- Child agents where typed contracts and tool partitioning matter

GitHub Copilot harness
 |
 +-- Document-intensive and multi-file processing
 +-- Processes where every exception cannot be designed in advance
 +-- Multi-source research producing several deliverables
 +-- Iterative planning, retry, and recovery
 +-- Skills for reusable, reviewed operating procedures
 +-- Connected Copilot Studio agents for genuine cross-agent work

Shared layer
 |
 +-- Workflows for deterministic approvals, writes, notifications
 +-- MCP servers, connectors, REST tools for all governed external access
 +-- Dataverse, Microsoft Graph, Power Platform governance and DLP

Standard-harness agents are the responsive, controlled front door. Workflows own the approvals, the writes and the system updates, because that is where determinism is provable. GitHub-harness agents handle the heavy analysis, file processing, exception resolution, and curation. Skills encode the operating procedures. Connected agents represent independently owned domain specialists. Everything that touches an external system goes through a governed tool.

What I would check before shipping

Did you pick the harness before the canvas? It cannot be changed later without a rebuild.
Do you need an external agent? If yes, it is the standard harness today. A2A is not documented in the new harness.
Is that thing a skill or a connection? If it authenticates or leaves the sandbox, it is a tool. Always.
Have you refactored network-dependent skill code? pip install, direct API calls, and database queries don’t survive the move.
Where does the generated file go? The sandbox is temporary; files are capped at 10 MB and expire after 28 days. Persist through a tool or hand it to the user.
Are you paying to build? Usage-based billing on the new harness starts at authoring, not at publish.
Is the tool budget the actual problem? If so, a child agent or a connected agent partitions it. A skill does not.
Did you confirm the preview status yourself? Connected agents, memory, Work IQ, and user file upload are marked as preview in the blog; some Learn pages are still prerelease.

Neither harness supersedes the other. The standard harness owns deterministic conversation, mature channels, typed child agents, and documented interoperability. The GitHub Copilot harness owns reasoning, files, skills, and adaptive recovery. The interesting systems being built right now use both, connected by workflows and governed tools — and the teams that get it right are the ones who made the harness decision consciously, on day one, instead of discovering it in month three.

Sources

Microsoft Learn, Harnesses overview, last updated 27 August 2026: the definition of a harness, the three harnesses, comparison guidance, the “secure sandbox governed by Copilot Studio” wording
Microsoft Learn, GitHub Copilot harness overview, 26 August 2026: agents “can’t be transferred” between harnesses
Microsoft Learn, Add a child agent, 25 August 2026: definition, triggers, typed inputs and outputs, validation and reprompts, Power Fx conditions, priority, after-running behavior, separate orchestration and tool limits, latency trade-off
Microsoft Learn, Skills overview, 26 August 2026, and Create a skill / Add an existing skill, 3 August 2026: skills as self-contained instructions versus tools, SKILL.md and YAML front matter, packaging, authoring and upload paths, runtime selection
Microsoft Learn, Connected agents overview, 26 August 2026: new-harness connected agents, the Copilot Studio-only restriction
Microsoft Learn, Connect to an existing agent, 3 August 2026: standard-harness configuration path, pass-conversation-history option, connected-agent limits
Microsoft Learn, Agent-to-agent (A2A), 26 August 2026: standard-harness banner, endpoint and agent card configuration, authentication options, custom connector infrastructure, full chat history in the payload
Microsoft Learn, Add an MCP server as a tool, 29 July 2026 (prerelease), and Tools overview, 26 August 2026: configuration path, MCP counting against tool limits, concurrency cap, DLP inheritance
Microsoft Learn, Files the agent creates, 29 July 2026: 10 MB per file, 28-day retention
Microsoft Learn, Multi-agent orchestration patterns and best practices, 22 May 2026: modularity rationale, inline agents also known as child agents, shared context, the 30-40 choices-of-action split threshold
Microsoft Learn, Copilot credits overview, 31 August 2026, and Manage usage for the GitHub Copilot harness, 28 August 2026: consumption billing, what credits cover, billing at build time, the Harness column, 1 September 2026 change for dev and trial environments
Microsoft Learn, Manage Entra Agent IDs, 26 August 2026, and Data loss prevention, 15 May 2026: automatic agent identity, runtime re-validation against ACP and DLP, the Skills with Copilot Studio connector classification
Microsoft Copilot Studio Blog, New and improved: GitHub Copilot harness, agent skills, and richer context, 2 September 2026: GA of the GitHub Copilot harness, preview markers on connected agents, memory, Work IQ and user file upload, workflows and MCP servers as tools
Microsoft Copilot Studio Blog, New and improved: multi-agent orchestration, connected experiences, and faster prompt iteration, 1 April 2026: A2A, Fabric and M365 Agents SDK multi-agent GA, the Ask Microsoft sub-agent pattern, Coca-Cola Beverages Africa
Microsoft TechCommunity, White paper: choosing between the GitHub Copilot and standard harnesses in Copilot Studio, September 2026: the harness as operating layer, decision guidance
Microsoft CAT community blog, The new Copilot Studio agent sandbox: no outbound network path, Python runtime and preinstalled libraries, non-permanent storage, egress only through knowledge sources and tools. Not Microsoft Learn — treat the no-egress statement as community-sourced until it is published on Learn

Workflows in the Copilot Studio: What the Agent Node Actually Changes

Holger Imbery — Tue, 01 Sep 2026 00:00:00 +0000

The earlier articles in this series dealt with agents: the orchestrator, the loop, skills, connected agents. This one is about the other half of the platform. The new workflows experience, the deterministic backbone, and the agent node, which lets a flow hand one step over to an agent that reasons instead of following hard-coded logic.

Status first, because it moved

On 3 August 2026 Ryan Cunningham announced that the capability previewed over the prior two months is “now generally available for production use” under a new name: the GitHub Copilot harness in Copilot Studio. The workflow designer came with it, giving “a visual canvas to understand and edit workflows, including adding agent nodes and running workflow evals”. So the accurate statement is not that a standalone workflow designer shipped GA, it is that the harness the new designer runs on is GA. The Learn page for the agent node says the same thing from the other direction: its features “are used by agents or workflows powered by the GitHub Copilot harness”.

That scoping matters when you plan. Copilot Studio now runs three harnesses side by side: Copilot Chat for customizing Chat experiences, Standard for conversational, topic-based agents, and the GitHub Copilot harness for complex agentic processes. Microsoft has committed to continued support for the first two, for existing agents and for new authoring. Nothing forces a migration.

Also GA: computer use since May 2026, with the August update embedding computer-using agents into multi-step workflows, and A2A since April 2026. Still preview: adding a workflow or an MCP server as a tool for an agent. Run-only agent sharing, which lets you give business users the ability to trigger an autonomous agent without maker access, is reported to be in preview, but I could not confirm it on Learn or the Copilot Studio blog, so check its status yourself before you plan around it. Classic agent flows remain GA.

Budget before you build. Agents on the GitHub Copilot harness “use usage-based billing for all work, regardless of Microsoft 365 Copilot licensing”, priced on the models you pick, the organizational context and tools you attach, and runtime. The maker-side work is billed too: natural language authoring, evaluations and testing fall under the same meter. That is a different economic model from the fixed rate card the Copilot Chat and Standard harnesses stay on, and it is the single most common thing I see teams miss.

What actually changed

Figure 1: one canvas instead of a choice between fully structured and fully agentic.

The definition of a workflow has not moved. It is a trigger plus at least one action, running a rule-based path where the same input produces the same output. That predictability is why anyone lets a flow touch a financial record.

You could always call an agent from a classic agent flow. It was one line item in an AI-capabilities submenu, prose in and prose out. The flow was the star and the agent was a service it happened to phone. In the new designer the agent is a node on the canvas, sitting next to “read a SharePoint list” and “send an email”.

That sounds cosmetic. It is not, and the reason is the plumbing around the node rather than the node itself.

The agent node in practice

Figure 2: the agent node as a step among the deterministic actions.

When you drop an agent node you pick one of two things, and this is the part that surprised people who read the May announcements:

An existing published agent. It “runs with whatever instructions, tools, and knowledge it was already configured with”. You give it a Message for this run, with dynamic content from earlier steps.

A new agent for this workflow. An inline agent whose instructions, tools, knowledge and output shape are configured in the node itself and travel with the workflow. There is no separate Message field; the Instructions field doubles as the per-run prompt.

Inline agents are not reusable. The docs are blunt about it: an inline agent is scoped to its workflow, and if you build the same one twice you should promote it to a published agent and call that instead. My rule of thumb is that the second time I write the same inline instructions, it becomes a published agent.

Three settings on that node do more for reliability than anything else:

Output shape. You choose a text response, structured output with named fields, or custom structured output matching a JSON schema you define. Pick a structured shape and each field becomes its own dynamic-content token downstream. This is the whole game. A text response drops you back into string parsing. A schema lets the next node branch on priority == "high" or write straight to a Dataverse column.

Request human assistance when unsure. The agent emails the connection owner and waits for a reply before continuing. Turn it on where being wrong costs more than being slow.

Work IQ. Grounds the agent in the running user’s recent mail, Teams, calendar, OneDrive and SharePoint context. Useful when the workflow acts on behalf of a person. Note the naming drift: Microsoft now also uses Microsoft IQ for the organizational-data connection on the agent side, so do not assume a colleague means the same thing you do.

Testing and evaluation, which is where the time goes

Node-level testing is the feature I use most. You open the node’s Test tab, enter inputs manually or reuse inputs from a previous run, and inspect the output without executing the whole flow. Anyone who has debugged a fifteen-step flow by reading run-history JSON knows what that saves.

Evaluations build on top of a test run. You write test methods in natural language describing what a good response looks like, then get a pass or fail per grader with the evidence behind it. Failed results can come back with suggested improvements. The loop is configure, test, evaluate, improve.

Know the limits before you plan around them:

Evaluations only work for new agents created in workflows, not for called published agents.
You cannot select a custom model for evaluations.
Up to five AI-generated test methods per node, and 20 evaluation runs per node per day.
Evaluations run against the most recent test output, so change the instructions and you re-test before you re-evaluate.

That last constraint bites during a tuning session. Twenty runs a day disappears faster than you expect when three people are iterating on the same node.

Where determinism goes and where judgment goes

Figure 3: the backbone stays reliable; the node plugs in where judgment is needed.

This is the one decision the platform will not make for you.

Deterministic action when	Agent node when
The rule is stable and expressible as if-then	The decision needs reasoning over unstructured input
The step writes to a system of record	The step must orchestrate several tools to decide
You need same input, same output	You must pull and combine several sources
Compliance requires a fixed, provable path	The input varies too much for a fixed path
Latency and cost must be predictable	A person would apply judgment, not a lookup

The Graebel case Microsoft published is this rule in production. Relocation requests arrive as unstructured emails with unique instructions, attachments and edge cases, so a purely structured automation was too rigid. Their Service Order Agent, built with Copilot Studio and Azure AI, “transforms unstructured service order emails into compliant transactions within Graebel’s globalCONNECT platform, even where no workflow APIs were available”, and escalates exceptions through workflows when needed. Judgment where the input is messy, structure where the process must be governed.

Four ways to reach intelligence, and which caller owns the loop

Figure 4: who calls whom.

Teams conflate these constantly. Ask who calls, whose loop runs, and who owns the callee.

Mechanism	Caller to callee	Whose loop runs	Use for
Deterministic action	Flow to connector	None, rule-based	Provable, rule-expressible steps
Agent node	Workflow to agent	The called agent’s, bounded by the flow	A reasoning point inside a process
Connected agent	Agent to specialist agent	The specialist’s	Delegation inside the agent runtime
Skill	Agent to its own behavior	The calling agent’s	Behavior reused across agents
A2A	Agent to cross-platform agent	The remote agent’s	Foundry, SDK, third-party agents

The short version: the agent node is the flow’s way to reach an agent, connected agents are an agent’s way to reach an agent. Get it backwards and you rebuild the god-agent problem on a new surface, either as a workflow encoding judgment in an ever-branching condition tree or as an agent stuffed with process logic that belonged in a flow.

Both directions are now available. Adding a workflow or an MCP server as a tool for an agent is in preview, so the agent-calls-flow half is not yet something I would design a production system around.

A worked example: unstructured intake

Figure 5: the flow owns the process and the writes, the node owns the one judgment, a person handles exceptions.

Relocation order, invoice, vendor contract. Same shape every time.

TRIGGER
  When an email arrives in the intake mailbox
     |
DETERMINISTIC ACTIONS (provable, auditable)
  - Save the message and attachments to the case store
  - Create a case record in Dataverse (status = "received")
     |
AGENT NODE (the one reasoning point)
  - Reads the email and attachments
  - Classifies the request, extracts fields, flags edge cases
  - Returns CUSTOM STRUCTURED OUTPUT against a schema:
    {category, fields[], exceptions[], confidence}
  - "Request human assistance when unsure" is on
     |
DETERMINISTIC BRANCH (structure resumes)
  - High confidence and no exceptions -> file and advance
  - Otherwise -> human review node
     |
DETERMINISTIC ACTIONS
  - Write the outcome to the system of record (idempotent)
  - Notify the requester, close or route the case

Read the control flow. The flow owns the process and every write. The node owns the single judgment no condition tree could hold, and it hands back a schema-shaped result rather than prose. The human review node keeps a person on the branch that costs money.

The output schema is what makes this hold together. Without it, the next node is parsing free text and you have moved the fragility rather than removed it.

Boundaries I check before shipping

Everything from the earlier articles still applies: least privilege, idempotent writes, audit, treating imported agents and skills as supply-chain dependencies. The node adds four checks.

Do not claim determinism across the node. A workflow with an agent node is only as deterministic as its deterministic parts. Keep every side-effecting write in a deterministic action with an idempotency key, after the node returns and, where it matters, after a person has looked. The node decides, the deterministic step commits.

Untrusted content enters through the node. The node ingests whatever the flow hands it: an email body, an uploaded document, a portal field. That is the same surface as CVE-2026-21520, the “ShareLeak” indirect prompt injection rated CVSS 7.5, where an unauthenticated attacker planted a fake system-role instruction in a public SharePoint form field. Microsoft patched it on 15 January 2026, but in Capsule Security’s follow-up testing data still exfiltrated, which is the more useful lesson: treat the patch as a floor, not a control. Validate payloads, never let free-text content override instructions, keep human review on consequential branches.

Cost compounds. Usage-based billing covers building, testing and evaluating, not just running. An agent node in a loop over the day’s meetings is a different cost profile from one node on an intake trigger. Do not put a node where a deterministic action would do.

Identity and sharing. Starting in July 2026, Copilot Studio automatically creates an Entra Agent ID for every new agent and you can no longer opt out at the environment level. Plan for it rather than discovering it. If the point of the automation is to let business users trigger it, run-only sharing is the mechanism to watch, though I have not been able to confirm its status in Microsoft’s own documentation.

What I would tell a team starting today

Build on the new canvas if the work is a multi-step process with ambiguous decision points. That is what the GitHub Copilot harness is for, and it is GA. If you are customizing a Chat experience or shipping a topic-based conversational agent, the Copilot Chat and Standard harnesses are still the right answer and still supported. Pick the harness before you pick the canvas.

Start with the backbone. Write the deterministic steps first, run them, then find the one place a rule cannot express the decision and put the node there. Working the other way around produces an agent with a flow bolted on.

Define the output schema before you write the instructions. It forces you to state what the downstream steps actually need, and it usually shortens the instructions.

Use inline agents for the first version and promote to a published agent the moment a second workflow wants the same reasoning.

Test the node in isolation before you run the flow, and budget the evaluation limits into your tuning session.

The backbone stays boring. The reasoning plugs in where it earns its place. That is the whole design.

Sources

Microsoft Learn, Add an agent node to a workflow, last updated 22 July 2026: existing versus inline agents, instructions and message fields, tools and knowledge, output shapes, Work IQ, request human assistance, node testing and evaluations with their limits, usage-based billing note
Microsoft Copilot Studio Blog, More powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio, Ryan Cunningham, 3 August 2026: GA of the GitHub Copilot harness, the workflow designer with agent nodes and workflow evals, the three-harness model, usage-based billing
Microsoft Learn, What’s new in Copilot Studio: computer use GA May 2026, A2A GA April 2026, Microsoft IQ, automatic Entra Agent ID from July 2026, workflow and MCP server as agent tools in preview
Microsoft Learn, Agent flows overview: the classic experience, trigger and action anatomy, the deterministic contract
Microsoft Copilot Studio Blog, New and improved: Computer-using agents, a new workflows experience, and real-time voice experiences: the redesigned canvas, agent nodes, inline AI actions, remote MCP support, the Graebel Service Order Agent
Microsoft Copilot Studio Blog, New and improved: Agent governance, intelligent workflows, and connected app experiences: the deterministic definition of workflows, embedding agents in them
Microsoft Adoption, Graebel uses governed automation to modernize global relocation service orders with Microsoft Copilot Studio, last updated 21 July 2026
VentureBeat, Microsoft patched a Copilot Studio prompt injection. The data exfiltrated anyway, Louis Columbus, 15 April 2026, and the NVD entry for CVE-2026-21520, for the ShareLeak disclosure timeline and severity
Community coverage, treat as commentary and verify on Learn: RPABOTS.WORLD, Copilot Studio Rebuilt: Workflow Designer GA, CUA, and Run-Only Sharing Explained, August 2026, and WindowsForum’s thread on run-only agent sharing, which is the only place I found that capability described. Note that these also describe the 3 August release as a standalone Workflow Designer GA; Microsoft’s own announcement frames it as the GitHub Copilot harness reaching GA with the workflow designer included
Prior articles in this series, for the agent-first model, the orchestration patterns, and the skills versus connected agents boundary

Microsoft Copilot Cowork in Practice

Holger Imbery — Sat, 15 Aug 2026 00:00:00 +0000

In short Cowork went from preview to worldwide general availability in about three months, and most of the guidance still circulating is from the preview era. This is what I have run into since then: the enablement path, the Anthropic decision European tenants have to make, what the skills do well, and where they stop.

I keep this post updated in my own blog

What Cowork actually is

For two years we used AI to help with work: draft the mail, summarise the thread, sketch the deck. Cowork does the task instead. You describe an outcome, it plans the steps, executes them across your tenant, and stops for your approval before anything leaves it.

Under the hood it is an agentic orchestration layer inside Microsoft 365 Copilot. It reasons across calendar, mail, files, and Teams content through Work IQ, shows its progress step by step, and lets you pause, resume, or cancel mid-run.

The mental model I use with customers. Brief it like a colleague, approve like an auditor. The output is a finished task, not text.

Status, licensing, availability

Copilot Cowork reached worldwide general availability on 16 June 2026. Anything you read that calls it “Frontier opt-in only” predates that.

How you get it

License. A Microsoft 365 Copilot license is required.
Off by default. Admins decide when to switch it on and for whom. Staged, not automatic.
Billing. Usage-based via Copilot Credits (pay-as-you-go, roughly $0.01 per credit), with a pre-commit discount option. Tenant, group, and user spending limits, alerts, and usage reporting are available.
Bundled route. Cowork-class capability is also in Microsoft 365 E7, the Frontier Suite tier (see below).

Where it runs

Web: m365.cloud.microsoft
Desktop: the Microsoft 365 Copilot app for Windows and Mac
Mobile: the Microsoft 365 Copilot app for iPhone and Android (new since spring, when mobile was unsupported)

Acts on, not runs in. Cowork sends Outlook mail and posts to Teams, but you launch it from the Microsoft 365 Copilot app, not as an add-in inside Teams or Outlook. Older notes saying it “runs in Teams and Outlook” mean “acts on”.

The models

Cowork is multi-model and the lineup has already moved since GA. Today the picker offers Claude Opus 4.8 , Claude Sonnet 5 (which replaced Sonnet 4.6 at GA as the efficient everyday choice), the Sonnet+Opus Advisor pairing, GPT 5.5 , and Claude Fable 5 in preview. Image generation runs on ChatGPT Images 2.0. The fine-tuned “Cowork 1” model was announced as coming soon in June and has not shipped yet, so do not build a business case on it.

Leave the picker on Auto and Cowork chooses. Two things deserve an admin’s attention: Fable 5 is off by default and has to be turned on in Copilot settings, and it is one of the preview models that require data retention by the model provider, which is a different contractual track from the subprocessor arrangement (next section). The residency consequence of the Anthropic dependency is the section after that, and for European tenants it is the one that decides the project.

Enabling it

Short sequence, but the mechanism changed at GA and this is where preview-era runbooks now fail. Cowork is no longer managed under All Agents > Cowork, and the agent-based access control from the preview no longer governs who can use it. Access hangs off billing instead: admins enable usage-based billing, and that is what opens Cowork to users.

Licensing. Target users hold a Microsoft 365 Copilot license.
Enable usage-based billing in the Microsoft 365 admin center, with Copilot Credits and spending limits configured before anyone starts. This is the step that grants access, not a Cowork on/off switch.
Set discoverability and scope access. Decide whether Cowork is discoverable to end users, and scope through security groups. If you make it discoverable without enabling billing, users can request access from inside the app and you approve or decline on policy, cost, and compliance. Pilot rings first.
Decide the Anthropic setting. Default in most commercial clouds, a deliberate opt-in for EU, EFTA, and UK.
Pre-decide governance: sensitivity labels, your approved-use matrix, audit and SIEM telemetry. Note what is not yet on the menu: Purview data loss prevention is still not supported for Cowork, so do not plan a control around it.
Open Cowork. Web, desktop, or mobile app, then select Cowork.

First run. A chat input, a side panel for files, suggested prompts (Catch me up, Organize my inbox, Prep for a meeting), a Tasks view in the navigation, and an output panel where generated files land.

To take it away again, scope through the same security groups or manage availability in Copilot settings. Group-based and reversible.

What “subprocessor” means here

For most tenants the Anthropic dependency is invisible plumbing. What your legal team cares about is the contract behind it.

Subprocessor status. Anthropic operates as a Microsoft subprocessor under Microsoft’s Product Terms and Data Protection Addendum. Breach notification, incident response, and data-handling obligations run through Microsoft, not through a separate Anthropic agreement.
Copyright cover. Microsoft’s Customer Copyright Commitment applies to Anthropic models inside the products it covers, including Microsoft 365 Copilot and Copilot Studio.
There is a second track, and it matters. Some newer Anthropic models are offered as “preview models with data retention”. For those, Anthropic acts as an independent data processor, not a Microsoft subprocessor , under Anthropic’s own commercial terms and DPA. They are off by default everywhere, including in regions where the other Anthropic models are on by default, and they have to be enabled separately. Claude Fable 5 in Cowork’s picker is one of them, so this is live, not theoretical.
What retention means there. Anthropic, not Microsoft, stores most inputs and outputs for up to 30 days. Content flagged by Anthropic’s trust and safety classifiers can be held for up to two years, and classification scores for up to seven. Cowork shows a banner while such a model is selected. Anthropic does not use retained data for training without your express permission. If your legal position rests on the Product Terms and DPA, that position does not cover these models.
Why two providers. Pairing a drafting model with a reviewing model from another vendor is the same idea behind Researcher’s Critique capability.

EU Data Boundary and the Anthropic switch

In every EU project I have run, this is the decision that sets the timeline. Microsoft made it an explicit, informed choice rather than a hidden default, which is helpful, because you can document it.

The facts, current as of August 2026

Anthropic is a Microsoft subprocessor under the Product Terms and DPA.
Anthropic-processed requests are currently excluded from the EU Data Boundary and, where applicable, from in-country processing commitments.
For EU, EFTA, and UK tenants, Anthropic models are off by default. An administrator opts in. The setting appears, but it is set to “No users”.
If you opted in previously under Anthropic’s separate commercial terms, you have to opt in again. The toggle went back to off.
Preview models with data retention stay off even after you opt in. They are a separate switch and a separate contract.
Cowork does most of its reasoning, drafting, and tool work on Anthropic models. So for a European organisation, enabling Anthropic is in practice the enabling step.

Where the setting lives

Microsoft 365 admin center → Copilot → Settings → View all → “AI providers operating as Microsoft subprocessors”. Select Anthropic and save. You need the AI Administrator or Global Administrator role. (Older notes call the sub-node “Data Access”. The current path is “View all”.)

How I run the enablement

Treat it as a governed project with six steps. Done once, they hold for the life of the rollout.

Confirm the contractual position. Ask your Microsoft account team for written confirmation that Anthropic is engaged as a subprocessor under the Product Terms and DPA, and file it in the vendor risk register.
Document lawful basis and transfer mechanism. Processing happens outside the EU Data Boundary, so record the data flow in your RoPA and apply the same transfer discipline you use for other non-EUDB services.
Define an approved-use matrix. Which roles, business units, and data classifications may use Anthropic-routed features. Start where value is high and sensitivity is moderate: drafting, research, summarising non-regulated content.
Use the controls that actually exist. Sensitivity labels are supported and are inherited by the documents Cowork creates, with the highest-priority label winning when several sources are used. So are DSPM for AI, auditing, Insider Risk Management, communication compliance, eDiscovery, and data lifecycle management. Data loss prevention, data classification, and Compliance Manager are not supported for Cowork. Build the guardrail out of labels and detection, not DLP, and test it end-to-end before you widen the ring.
Turn on telemetry. Prompts and responses land in the unified audit log, along with events like starting a conversation, adding or sharing a skill or plugin, running a scheduled prompt, starting a browser task, uploading a file, and Cowork writing an artifact to OneDrive. Pull those into your SIEM and validate coverage during the ramp.
Roll out in rings. Informed pilot, feedback, expand. The opt-in is reversible and group-scoped.

The framing that gets a yes. The Anthropic toggle is a contractual and governance decision, not a technical one. Once those six steps are done, you can approve Cowork with a compliance story you can defend and an audit trail to back it.

Two things European admins get wrong

What “off” actually means. Copilot’s base models are OpenAI GPT and Anthropic sits on top as an opt-in layer. Microsoft’s wording is that some features are only available when Anthropic models are enabled, and that certain features may no longer be accessible if you turn Anthropic off. Since Cowork does most of its work on Anthropic models, expect it to be unavailable or badly degraded rather than quietly falling back to GPT 5.5. Tell your users that before they file the ticket.

The EU app-level setting (3 April 2026). A separate switch, “Copilot in M365 apps with Anthropic models in EU/EFTA and UK”, makes Anthropic the default model for Copilot in Word, Excel, and PowerPoint. It is on by default only for tenants created after 25 March 2026; older tenants should check the Message Center. It still routes data outside the EU Data Boundary, so it belongs in the same governance story.

The 13 built-in skills

Cowork’s behaviour is packaged as skills the agent loads on demand, using the open Agent Skills format. You do not pick one. Cowork matches your prompt against each skill’s description, then streams what it is doing (“Preparing to create Word documents”, “Composing your email”). Naming a skill works too: “Use the Deep Research skill to compare these three proposals.”

#	Skill	What it does
1	Word	Create and edit Word documents end-to-end.
2	Excel	Build and edit spreadsheets, including formulas.
3	PowerPoint	Generate decks from content or templates.
4	PDF	Produce PDFs, including from other formats; read PDFs as input.
5	Email	Read, draft, and send Outlook mail, with approval.
6	Scheduling	Find times, send invites, manage RSVPs.
7	Calendar Management	Review and reorganise calendar entries, defend focus time.
8	Meetings	Prep, summarise, extract action items.
9	Daily Briefing	Assemble an overview from email, calendar, and Teams.
10	Enterprise Search	Search your Microsoft 365 environment, with citations.
11	Communications	Draft audience-tailored updates, announcements, escalations.
12	Deep Research	Multi-step investigation across attached and indexed sources.
13	Adaptive Cards	Render structured output as visual cards.

Beyond that list, Cowork also generates images (ChatGPT Images 2.0, saved to your session and your OneDrive output folder) and, in Frontier, can drive a local Edge browser to finish web tasks using the sign-ins you already have. The browser tab runs on your machine, so your existing conditional access, DLP, and browsing policies apply, a tenant setting called Cowork Browsing turns the capability on or off, and every browser task is written to the unified audit log.

Still not there: no built-in Power BI skill, though the Fabric IQ plugin brings Power BI and Fabric data into Cowork. No access to files on your local disk. Third-party tools arrive through plugins rather than as built-in skills.

Custom skills with SKILL.md

The 13 are the floor. Each user can add up to 50 custom skills as SKILL.md files.

Where they live. OneDrive, under /Documents/Cowork/skills/, one subfolder per skill with a SKILL.md inside, for example /Documents/Cowork/skills/weekly-report/SKILL.md. Cowork picks them up at the start of each session, no admin toggle. Added one mid-session? Start a new task.

The file is no longer the only route. Since GA there is a Customize page that hosts your skills and your plugins in one place. You can build a skill through a guided conversation, upload one as .md, .zip, or .skill, and share a skill or plugin with specific people, re-sharing to push updates. I still author in the file and use the page for distribution, because a file in Git is reviewable and a guided conversation is not.

Anatomy. YAML frontmatter with name and description, then Markdown instructions:

---
name: weekly-report
description: Compiles a weekly status report from my calendar, email, and Teams
  activity. Use when I ask for "my weekly report" or "wrap up the week."
---

# Weekly Report

When invoked, do the following:

1. Pull all meetings I attended in the past 7 days from my calendar.
2. Identify action items I committed to, from meeting notes and follow-up emails.
3. List open items still awaiting my response.
4. Summarise key decisions made in Teams channels I own.

## Output
Produce a Word document titled "Weekly Report, [date range]" and save it to
/Documents/Reports/Weekly/. Cap each section at 6 bullets; use a direct tone.

The description does the work. Cowork decides when to invoke a skill from the description field alone. “Helps with reports” gets ignored or fires at the wrong moment. “Use when I ask for my weekly report or ‘wrap up the week’” fires reliably. Put the trigger phrase in the description. This is the single most common fix I make to other people’s skills.

The standard behind it. SKILL.md is the open Agent Skills standard, originally from Anthropic and now supported by Claude Code, VS Code Copilot, Gemini CLI, Cursor, JetBrains Junie, and 30 or more other tools. Examples at github.com/anthropics/skills, spec at agentskills.io.

Limits worth knowing: custom skills are not validated by Microsoft , so review their output, especially anything that mails externally or edits shared content. They cannot bypass approvals, and they cannot reach data the user could not already open.

Prompts that hold up

Skills work best when you brief an outcome and let Cowork assemble the steps. Patterns I keep reusing:

Email

“Read my unread emails from the past 24 hours. Group them by project. For anything from marketing about the spring campaign, draft a reply summarising the latest results from the attached CSV and propose a 30-minute review next Tuesday between 10 and 12. Show me each draft before sending.”

It triages, drafts from the thread plus attachments, and prompts before each send. “Catch me up on the Acme account” quietly combines Email, Enterprise Search, and Meetings into one brief.

Scheduling and calendar hygiene

“Find 30 minutes next week with Sarah, Tom, and me. Avoid Mondays. Book a room if available, send the invite ‘Spring campaign review’ with an agenda I’ll dictate, and propose two backup times.”

“Review next week’s calendar. Flag back-to-backs longer than 3 hours, identify meetings without a clear agenda, and propose declines for anything I’m only optional on. Show me the proposals before acting.”

Scheduling moves things forward, Calendar Management cleans up. Both improve sharply with explicit constraints. Private events are respected and never surfaced.

Meetings and briefings

“Prepare me for Monday’s quarterly review with the CISO. Pull her last month of meetings with my team, open action items from those notes in Teams, and status updates sent via email. Produce a one-page briefing I can share 24 hours in advance.”

Daily Briefing is the obvious scheduled prompt: “Every weekday at 7:00 AM, run my morning briefing and save it to /Documents/Briefings/.” Easiest automation to set up, best return per minute invested.

Since July there is a second kind of automation worth knowing: event-driven tasks that fire when a matching email arrives or a Teams message is posted, including when you are @mentioned. You describe what to watch for, Cowork proposes the automation, you confirm it. Both kinds run with your permissions, still ask for approval before sending or posting unless you pre-authorise, carry rate limits and loop protection, and show up on the same Scheduled page.

Documents

“Draft a 2-page board memo on Q1 results. Use the attached financial summary and the previous board memo as references. Direct tone, no jargon. Save to /Documents/Board/.”

Document skills produce real files in OneDrive or SharePoint, not inline text. They show up in the side panel and persist afterwards; Download All grabs a session’s outputs as a zip. Chains are common: “build the deck, save it to OneDrive, and post a link in #leadership” touches three skills, and each external action is approved separately.

Search and research

“Run a competitive analysis of our top three competitors using the product team’s research files and the industry reports in /SharePoint/Industry. Produce a Word document with an executive summary and an Excel comparison matrix. Flag capability gaps. Use Critique.”

Enterprise Search is the broad sweep across mail, calendar, files, Teams, OneNote, and SharePoint, answering with citations and bounded by existing permissions. Deep Research is the multi-step synthesis, optionally routed through Researcher’s Critique. Treat the citations as your audit trail for anything you forward outside the company.

Approvals, pause, and the Tasks view

Approvals. Before sending mail, posting in Teams, or scheduling a meeting, Cowork shows a preview of the content (recipients, subject, body, time, channel), a risk-level indicator for medium and high risk actions, and a Show parameters option for the technical detail.

You then hit the action button, open the dropdown next to it to approve and skip similar prompts for the rest of the session, or cancel. For mail and Teams messages the dropdown is scoped: skip only for one recipient, only for a domain, or always for that action. Use the narrowest scope that gets you through the task, and never widen it in a conversation touching external recipients.

Pause and resume. Pause finishes the current step and halts, a hard pause stops immediately, resume continues, cancel ends the task. Lose the network and it reconnects and picks up where it stopped.

Tasks is your working record. Two views: Recent, in reverse chronological order with filters for In progress, Needs input, Done, and Failed, and Scheduled, which appears once you have at least one scheduled prompt or event-driven task and lets you edit, pause, resume, or delete each. Click any task to jump back into its session. When Cowork needs something from you, the status reads Needs user input until you answer. For the actual audit trail, go to the unified audit log, not this view.

Grounding it properly

Output quality tracks context almost linearly. A vague prompt against an empty workspace gives generic text. The same prompt with three well-chosen attachments gives something you can send.

Three ways to add context: drag and drop from your device, use Add work context to pull files, people, meetings, and chats from OneDrive, SharePoint, or Teams, or reference a path in the prompt (“use /Documents/Brand/guide.pdf”).

What has measurably lifted quality for my customers:

A brand and tone kit. One folder with the style guide, a sample memo, and a glossary. “Match the tone and structure of the attached memo.” The output starts reading like your team.
A context pack per recurring task. For a weekly report: last period’s deliverable, a definitions file, the data source. Attach the folder and the output stays consistent across cycles.
Source pinning. “Only state facts from the attached document. Flag anything I need to verify separately.” This is the cheapest hallucination control available.

Hard numbers. Attachments under 200 MB each. Prompts up to 250,000 characters. Files must sit in OneDrive, SharePoint, or Teams, with no local-drive access. Cowork cannot read encrypted files , even ones you can open yourself. Work IQ grounds it automatically and within permissions, but explicit attachments are per-task and are not re-read later, so reattach or reference the path.

Limits

Lead with these in your enablement material. Users should meet the boundaries in training, not on a Friday afternoon.

By design: no local file access, no file deletion in OneDrive or SharePoint (Cowork creates and edits, users delete), no reading encrypted files, no Microsoft validation of custom skills, 200 MB per attachment and 250,000 characters per prompt.

Regional and governance: Anthropic off by default in EU, EFTA, and UK with admin opt-in, and a fresh opt-in required if you had enabled it under Anthropic’s own terms before; preview models with data retention off everywhere until separately enabled; only non-federal GCC can opt in among government clouds, processed outside the FedRAMP-authorised US Government cloud, with federal GCC, GCC High, DoD, and other sovereign clouds excluded and no toggle shown; use limited to Anthropic-supported countries and regions.

Compliance surface: supported today are DSPM and DSPM for AI, auditing, sensitivity labels including inheritance, encryption without labels, Insider Risk Management, communication compliance, eDiscovery, and data lifecycle management. Not supported: data loss prevention, data classification, and Compliance Manager. Cowork interactions also show in activity explorer but not on the Apps and agents dashboard or the AI observability page. Validate your own coverage before you rely on any of it as regulatory evidence.

The trade honestly stated. Cowork gives up some autonomy and breadth in exchange for keeping AI-driven actions inside auditable, policy-governed, compliance-covered infrastructure. For regulated enterprises that trade is the reason to buy it.

Re-check monthly: the model lineup, which turned over inside two months at GA; the skill list and custom-skill cap; regional availability and the EU, preview-model, and GCC settings; billing; the plugin catalogue; and whether DLP support for Cowork has landed. It was announced as coming at GA and as of mid-August it still has not.

What is coming: E7, Agent 365, Researcher, plugins

Microsoft 365 E7, the Frontier Suite. Generally available 1 May 2026 at $99 per user per month. It bundles E5, the Entra Suite, Microsoft 365 Copilot including Cowork, and Agent 365. Microsoft’s own pitch is that the suite costs less than buying those parts separately, so the business case rests on whether you would have bought Agent 365 governance and Cowork-class capability anyway.

Agent 365, the control plane for agents. Generally available 1 May 2026 , $15 per user per month standalone or included in E7. It extends Microsoft’s user-management stack to AI agents: central identity, security, and compliance across Copilot Studio agents, custom agents, partner agents, and Cowork itself. Some parts, including shadow-agent discovery and Windows 365 for Agents, are still preview. Start your agent inventory now, even if it is Cowork plus two Copilot Studio agents.

Researcher with Critique. One model drafts, a second model from a different provider reviews for accuracy, completeness, and citation integrity. Microsoft reports a DRACO score of 57.4, about 13.8% above single-model approaches.

Read that benchmark carefully. Those figures are Microsoft’s own evaluation, not independently verified, and I could not trace them to a current primary Microsoft source when I last checked. The baseline is also described slightly differently across Microsoft’s materials. If you quote it, say “Microsoft-reported” and do not hang a decision on it.

Plugins. At GA, Cowork opened to partner plugins with nine live: Enosix, Harvey, LSEG, Miro, monday.com, Moody’s, Morningstar, S&P Global Energy, and TeamsMaestro. Adobe, Atlassian, Box, Canva, CB Insights, Databricks, MoneyForward, and Templafy were announced as next. On the Microsoft side, Fabric IQ and the Dynamics 365 Sales, Customer Service, and ERP plugins are GA, with Sales and Customer Service enabled by default and disableable in the admin center. The catalogue moves, so check the App Store rather than any list, including this one. Plugins are how third-party tools reach Cowork, built on the same package format and skill standard as your own SKILL.md files, and admins control which ones are visible. Since June you can also upload your own plugin package and share skills and plugins with named colleagues, so a curated team library is worth starting now.

Checklist

Admins standing up Cowork:

Confirm Copilot licenses, then enable usage-based billing with Copilot Credits, spending limits, and alerts in place first.
Set discoverability, scope access to a pilot security group, and decide how you handle access requests.
Make the Anthropic decision using the six steps above, documented, and decide separately whether preview models with data retention are allowed at all.
Test sensitivity labels and their inheritance end-to-end, wire the audit log into your SIEM, and note that DLP does not yet cover Cowork.
Publish an approved-use matrix and a short user guide that leads with the limits.

Your first two weeks as a user:

Set up one scheduled Daily Briefing and refine its format.
Build one custom skill, starting with weekly-report, and sharpen its description.
Run one document workflow with grounding attachments end-to-end.
Use the Tasks view as your audit trail and approve external actions deliberately.

Where this leaves you

Cowork closes the gap between deciding something needs doing and it being done. The briefing that cost thirty minutes of tab-switching is drafted before your first coffee. The weekly report that depended on one person remembering scattered threads gets assembled, cited, and formatted by a scheduled skill. That payoff shows up for teams that invest in the setup: sharp skill descriptions, grounded attachments, disciplined approvals.

The obligations come with it. Every action Cowork takes goes out under your name and your organisation’s compliance posture. The subprocessor decision, the DLP wiring, the label hygiene, the spending limits: none of that is governance theatre, it is what makes the capability safe to scale.

In Europe there is one more layer. The EU AI Act and GDPR do not block Cowork, they require documented intent. Enabling third-party models deliberately, keeping audit trails, and telling employees what is happening is work you can show to customers, regulators, and candidates.

So: start narrow, learn fast, govern from day one, expand on evidence. One team, one skill, one scheduled briefing, two weeks. Then read the Tasks log, fix the prompts, add the next use case. The organisations that will look back at 2026 as a turning point are not the ones with the broadest rollout. They are the ones that built the smallest trustworthy foundation first.

Sources

Microsoft:

Standards and background:

Agent Skills standard, agentskills.io · Anthropic Skills examples, github.com/anthropics/skills
My 14-part Cowork series (April to May 2026) at holgerimbery.blog

Cost optimization for agentic systems

Holger Imbery — Sat, 08 Aug 2026 00:00:00 +0000

Summary lede: With agents, a single request can fan out into model calls, retrievals, retries, and tool actions that cost far more than the prompt suggests. Here’s how I measure, allocate, and govern that full cost — not just the token line — and tie it to outcomes.

Why read this: It walks through the real cost of an agent workflow, maps it to Microsoft’s three agent surfaces, and sets up the controls before the bill runs away from you.

Why “Agent FinOps,” and why now

For about a decade, cloud FinOps gave finance and engineering a shared language for variable spend: tag it, allocate it, optimize it. Token pricing stretched that language but kept the anchor — a human prompt, a single response. Agents cut the anchor. One request can set off a plan, several model calls, retrieval, tool actions, retries, and sub-agents, all in seconds and usually finished before the dashboard updates.

A few numbers set the stakes. Industry coverage of the FinOps Foundation’s 2026 State of FinOps report puts inference at about 85% of enterprise AI spend — the cost is in running models, not building them. A May 2026 Microsoft Research study of agentic coding found that models can’t reliably predict their own token usage (self-prediction correlated with actual use at about 0.39), and that the same task can vary by up to 30x in total tokens. Agentic tasks can burn up to 1,000 times more tokens than a simple chat, and agents make an estimated 3–10x more model calls than chatbots for the same user-facing job.

The failure stories are concrete: organizations that spent an annual AI budget in four months, a company that capped AI spend at $200 a week after too many surprises, and a single agent stuck in a reasoning loop that billed about $4,700 of compute in one afternoon before anyone noticed. Around 96% of organizations report AI costs higher than expected once workloads hit production.

What I see in projects is that the surprise is rarely the model itself — it’s everything around it. And as of this summer, the meter starts earlier than it used to: on Copilot Studio, building an agent now draws credits, not just running one. That’s what Agent FinOps is for: measuring, allocating, and governing the full cost of an agent workflow, then tying that cost to a business outcome. On the Microsoft stack, that means spanning three very different meters.

Why agent costs behave differently

The common mistake is to budget for the visible inference line and stop there. In cost reviews, the raw token figure usually lands 40–60% below the real cost of an agentic workload once you count the machinery around it. Four cost centers do the hiding:

Hidden cost center	Why it escapes the budget
Retry & failure recovery	Agents retry on tool errors, rate limits, and validation failures. A 15% step-failure rate with two retries can double the token count — yet most estimates assume zero retries.
Embedding & retrieval	Every RAG step adds embedding and search calls. Cheap on their own, they compound across dozens of retrievals per session and land on a different line item.
Guardrail & safety calls	Moderation, PII detection, and policy checks are separate model calls — sometimes two or three in sequence — usually owned by a platform team and never billed back to the product.
Orchestration & compute	The framework, context store, tool servers, and memory run on compute that scales with session time, not tokens. A 30-minute task runs 30 minutes of infrastructure.

So the unit that matters is not cost per token but cost per agent session — and, where you can get it, cost per outcome: per ticket resolved, per document reviewed, per invoice exception cleared. That is the number that connects to the P&L, and the one Agent FinOps exists to defend.

The Microsoft agent estate: three surfaces, three meters

Microsoft customers now build and run agents in three places, each with its own cost model. Treating them as one estate — rather than three separate invoices — is most of the job.

Surface	Cost unit	How you pay	Primary controls
Copilot Studio	Copilot Credits (≈ $0.01)	Pay-as-you-go, prepaid credit packs, or annual prepurchase	Power Platform admin center: per-environment and per-agent caps
Microsoft Foundry Agent Service	Model tokens + tool & compute charges	Pay-as-you-go, provisioned throughput, batch, or Agent Commit Units	Azure Cost Management: budgets, quotas, token-per-minute limits, tags
Copilot Cowork	Copilot Credits ($0.01)	Pay-as-you-go or prepaid P3 volume plan	Off by default; tenant / group / user budgets, alerts, usage reports

Copilot Studio — the Copilot Credit meter

Copilot Studio meters agents in Copilot Credits, the common currency Microsoft adopted when it renamed the earlier “messages” unit on 1 September 2025. Each credit is worth about one US cent, and how many you spend depends on what the agent does, not how many words it writes. The published rates make the gradient clear:

Agent activity	Copilot Credits	M365 Copilot licensed user
Classic (authored) answer	1	Included
Generative answer	2	Included
Agent action	5	Included
Tenant Graph grounding (per response)	10	Included
Agent flow actions (per 100)	13	Included
Content processing (per page)	8	Included
Premium AI tools (per 10 responses)	100	Included

Two design facts drive most of the bill. First, grounding costs about ten times a plain reply: a tenant-Graph-grounded response bills at 10 credits against 1 for a classic answer, so an agent that reaches into SharePoint or Exchange on every turn costs roughly ten times a simple chatbot. On its own, that single factor moved a pilot’s projected cost more than any model choice did. Second, autonomy adds up quietly — Microsoft’s own guidance notes an agent with deep reasoning and autonomous triggers can use up to 100 credits (about $1) per 10 auto-triggered interactions, roughly $0.10 each with no human in the loop.

Usage by people already licensed for Microsoft 365 Copilot is included at no extra charge, which turns “how much per message?” into “credits or licenses?” For everyone else, there are three ways to buy: pay-as-you-go at $0.01 per credit through an Azure subscription; prepaid packs (for example, 25,000 credits for $200 a month — an effective $0.008 per credit, about 20% below pay-as-you-go); and an annual prepurchase of Copilot Credit Commit Units usable across eligible products. Bring-your-own models, including Azure Foundry models, are billed separately.

There’s a third fact that changed the math this year, and it’s easy to miss. The August 2026 licensing guide moves the meter upstream: the LLM-powered maker actions you use while building — natural-language authoring, evaluation, and preview — now draw Copilot Credits. Only manual, non-LLM configuration stays free. In other words, the cost clock can start before a single user ever talks to the agent. Publishing itself is still free; it’s the act of designing with AI that now bills.

How much building costs depends on the harness — the scaffolding that lets an agent plan, reason, hold context, and call tools. Copilot Studio ships three, and they meter differently:

Harness	What it’s for	When credits are consumed
Copilot Chat	Customize Microsoft 365 Copilot with your own knowledge — e.g. an onboarding agent answering from SharePoint	LLM-powered build actions draw credits; employee-facing runtime in Microsoft channels is included in the Microsoft 365 Copilot license, under the user’s identity and fair-use limits
Standard	Rule-based conversational agents with predefined topics and flows — e.g. an IT agent routing laptop requests through approval	Same as Copilot Chat: LLM-powered build actions draw credits; employee-facing Microsoft-channel runtime is license-included
GitHub Copilot	Agentic, end-to-end process automation — e.g. an accounts-payable agent that reads invoices, matches purchase orders, and routes exceptions	Credits during creation and runtime — the runtime is not zero-rated by the license

The takeaway for FinOps is that “building” is no longer a free, pre-production zone. The GitHub Copilot harness — the one you reach for exactly when the work is most autonomous and most valuable — bills you to build it and bills you to run it, license or no license. The old mental model, where cost only showed up once real users arrived, is gone. Budget the build, not just the run.

Microsoft Foundry Agent Service — tokens, tools, and reserved capacity

Where Copilot Studio hides cost inside a single credit, Foundry Agent Service exposes the underlying resources directly — the code-first path developers want. There’s no charge for creating or running a Foundry-native agent itself; you pay for what it consumes:

Component	How it is billed
Model inference	Foundry Models token consumption — input and output priced separately, output typically 4–8x the input rate.
File Search (knowledge)	$0.11 per GB of vector storage per day (first 1 GB free).
Code Interpreter	$0.033 per session.
Web Search / Custom Search	$14 per 1,000 transactions.
Hosted agents (Agent Framework, LangGraph)	Billed on the underlying container compute per hour.
Tools, Fabric, SharePoint, Bing grounding, Foundry IQ	Separate charges and licenses, on top of tokens.

Because the meter is granular, real bills routinely run 15–40% above a token-only estimate once Azure AI Search, fine-tuned-model hosting, and monitoring are added. The biggest lever is picking the right deployment type per workload:

Standard (pay-per-token) — no idle cost, scales with usage. The default for development, spiky traffic, and anything still being validated.
Provisioned Throughput (PTU-hour) — reserved model capacity billed hourly whether or not a request comes in. Predictable performance and lower effective cost for steady, high, latency-sensitive production.
Batch — large asynchronous jobs at roughly 50% off standard, with a 24-hour target turnaround. Underused, and the biggest single discount for summarization or bulk classification.
Priority processing — pay-per-token at a premium for lower, more consistent latency where it genuinely matters.

The expensive mistakes are mismatches. Provision PTUs for a workload that only spikes a few hours a day and you pay around the clock for part-time capacity; run a high-volume production app on pay-as-you-go and you invite variable cost and rate limits at the worst moment. PTU capacity can’t be paused — billing stops only when you delete the deployment — so sizing it correctly (Microsoft ships a capacity calculator) is the core of provisioned cost optimization. For committed, predictable volume, Agent Commit Units apply a 5% discount at entry tiers and up to 15% at higher volumes across tokens, storage, search, and compute.

Copilot Cowork — delegated work behind a meter

Cowork is the newest surface and, for FinOps, the most instructive. Released worldwide on 16 June 2026 for eligible Microsoft 365 Copilot customers, it takes on long-running, multi-tool work and returns a finished result rather than a draft — scheduled tasks run in the cloud whether or not a laptop is open, with the Microsoft Graph connection keeping governance in the task flow.

Autonomy here comes with a meter. Each task consumes Copilot Credits based on model use, retrieved context, tool calls, and runtime — the same four drivers that make agentic spend hard to forecast, now rolled into one variable charge. Credits are $0.01 each under pay-as-you-go, with a prepaid P3 volume plan available; customers in Microsoft’s Frontier early-access program got a grace period before charges began.

What makes Cowork a useful template rather than a liability is its governance posture: it’s off by default, and admins can restrict access and set budgets, alerts, and usage reports at tenant, group, and user levels. (Microsoft’s claim that more than half the Fortune 500 used the preview is its own figure and isn’t independently corroborated.) The lesson holds beyond Cowork: delegating more work saves time but creates a variable charge someone has to own.

A unified Agent FinOps operating model

Cloud FinOps rests on three practices — visibility, accountability, and optimization. Agent FinOps keeps the structure but changes the attribution logic, because the unit of cost is a whole workflow, not a single call. Here’s how each practice maps onto the Microsoft controls above.

Visibility — measure the full workflow

Tag every agent session at the orchestration layer with product, feature, user tier, and session ID — the equivalent of tagging cloud resources. Without it, spend is one undifferentiated number.
Budget seven lines, not one: model calls, retrieval, tool calls, cloud/orchestration, observability, human review, and failure/retry. The token line is the visible bill, rarely the whole bill.
Use the native meters: the Copilot Studio usage estimator and Power Platform analytics, Azure Cost Management dashboards and Foundry’s OpenTelemetry tracing, and Cowork’s tenant/group/user usage reports.

Accountability — give every workflow a cost owner

Cap at the right altitude: per-environment and per-agent limits in Copilot Studio; budgets, quotas, and token-per-minute limits per deployment in Foundry; tenant/group/user budgets in Cowork.
Alert before, not after: fire warnings at 70% and 90% of budget, not at 100% — when the capacity is already gone and users hit an “agent unavailable” error.
Name an owner per workflow, the way each team owns an Azure budget, so what reads as “innovation” to a product team never reads as uncontrolled burn to finance.

Optimization — reduce cost without blocking velocity

Match the model to the job. Routing to a frontier model when a small one delivers the same quality can be a 100x+ multiplier for zero added value.
Match the workload to the deployment. Move bulk, non-urgent work to Batch; reserve PTUs for steady, latency-critical paths; keep dev and spillover on pay-as-you-go.
Prune the inputs. Trim system prompts, compress retrieved context, cache aggressively, and bound retries — input tokens drive most agentic cost.
Stage the autonomy. Move through observe → advise → act-with-approval → act-autonomously, granting full autonomy only where monitoring, rollback, and accountability are strong enough. Every checkpoint you remove is one that could have caught a runaway loop.

A practical playbook

Before you deploy:

Define the workflow as a product unit — trigger, expected output, value signal, cost ceiling, human-review rule, and stop condition — before it reaches production.
Estimate consumption in a pilot. Use the Copilot Studio usage estimator or the Foundry capacity calculator, and treat the result as an informed starting point, not a guarantee.
Decide credits vs. licenses. If a cohort will lean heavily on agents, a Microsoft 365 Copilot license that zero-rates employee-facing usage may beat metered credits — and sometimes the reverse is true.
Turn on caps and alerts from day one. Keep Cowork and new agents scoped, off, or budget-limited until you’ve watched real usage.

In production:

Review cost per outcome weekly, not just total spend. A rising cost-per-ticket is the earliest sign a workflow is drifting.
Watch the hidden lines — retries, retrieval, guardrails, long-running sessions — not only the token meter.
Re-tier and re-deploy quarterly as models and prices change; Foundry pricing in particular moves fast.
Escalate autonomy only after the monitoring and rollback around a workflow have proven themselves.

Metrics that matter

Metric	What it tells you
Cost per outcome	The P&L-relevant unit — per resolved ticket, reviewed document, or cleared exception. Hardest to get, most important.
Cost per agent session	The true unit of agentic spend, capturing the retries, retrieval, and runtime that per-token views miss.
Cost per token / per inference	Useful diagnostics for model and prompt efficiency — never the whole story.
Retry & failure rate	A direct driver of hidden cost; small defects become recurring spend when retries are unbounded.
Budget burn vs. forecast	Tracked per environment, agent, and team, with alerts well before 100%.
Autonomy level	How much spend runs without a human checkpoint — the risk multiplier behind every other metric.

Is there a single pane of glass?

Not yet — no single native screen spans all three surfaces. Microsoft is converging on one, and there’s a clear “closest thing” at each layer.

On the Copilot side, the designated single pane of glass is the Copilot Control System (CCS), surfaced in the Microsoft 365 admin center and built on three pillars: security and governance, management controls, and measurement and reporting. A lifecycle Agent Cost Management approach sits on top of it — estimate, set up billing, track and forecast, then actively control. Because Copilot Studio and Cowork both meter in Copilot Credits, CCS with the Power Platform admin center covers both: per-user and per-agent consumption reports, real-time high-consumption alerts, historical trends, per-user and per-agent limits, departmental chargeback, and the Agent Usage Estimator for forecasting before deployment.

Where it stops being unified is Foundry. Foundry bills through Azure — tokens, tools, and compute — so its cost lives in Azure Cost Management, a separate plane. CCS integrates with Azure Cost Management for deeper analysis, but you’re still crossing two portals.

Layer	Single-pane candidate	What it covers
Copilot Studio + Cowork	Copilot Control System + Power Platform admin center	Credits, per-agent/per-user usage, limits, alerts, chargeback
Foundry	Azure Cost Management	Tokens, tools, PTU / compute
Everything, normalized	FinOps toolkit → FinOps hubs (FOCUS)	Azure + Microsoft 365 + other-cloud cost and usage in one store

For a true view across everything, the practitioner path is Microsoft’s open-source FinOps toolkit — specifically FinOps hubs, which normalize cost and usage through the FOCUS standard (FinOps Open Cost and Usage Specification) into a single Data Explorer or Power BI store, and can even be queried by an AI agent. Commercial FinOps platforms offer the same consolidation. The thread to watch is Copilot Credits becoming the common currency across the Copilot estate — though it does not yet fold the Azure-billed Foundry side into the same screen.

The bottom line

Agents change the economics of software from a seat you buy to a meter that runs. Copilot Studio, Microsoft Foundry, and Cowork each expose that meter differently — a credit, a token-and-compute stack, a delegated-work charge — but the discipline is the same: measure the full workflow, give every agent a cost owner and a ceiling, tie spend to outcomes, and grant autonomy only as fast as your controls can keep up.

The teams that build this layer early — while their agent estates are still small — treat it as an engineering routine. The ones that defer meet it later as a board conversation about a bill nobody forecast, when the spend is large, the patterns are entrenched, and the only lever left is cutting features instead of cost. The tools already exist; it’s mostly a matter of turning them on before you need them.

Sources

Microsoft Copilot Studio — Billing and licensing — https://learn.microsoft.com/en-us/microsoft-copilot-studio/billing-licensing
Microsoft Copilot Studio — Billing rates and management — https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-messages-management
Microsoft Copilot Studio Licensing Guide — August 2026 (harnesses; build-time credit consumption)
Microsoft Azure — Foundry Agent Service pricing — https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service/
Microsoft Learn — Provisioned throughput billing and cost management — https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput-billing
WinBuzzer — Microsoft’s Copilot Cowork is Now a Metered Agent Consuming Credits (Jul 2026) — https://winbuzzer.com/2026/07/20/microsoft-made-copilot-cowork-a-metered-agent-in-june-xcxwbn/
TechRepublic — AI Agent Cloud Costs Are Making Enterprise Budgets Harder to Predict (Jul 2026) — https://www.techrepublic.com/article/news-ai-agent-cloud-costs/
Institute of AI PM — Agentic FinOps: How to Govern AI Agent Costs (Jun 2026) — https://www.institutepm.com/knowledge-hub/agentic-finops-guide
CIO — 5 ways for CIOs to avoid AI bill shock (Jul 2026) — https://www.cio.com/article/4190605/5-ways-for-cios-to-avoid-ai-bill-shock.html
Microsoft — Take Control of Agent Costs (Power Platform Blog, Jul 2025) — https://www.microsoft.com/en-us/power-platform/blog/2025/07/21/agent-costs-controls/
Microsoft Learn — Copilot Control System management controls — https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/management-controls
Microsoft Learn — Configure AI agents for FinOps hubs — https://learn.microsoft.com/en-us/cloud-computing/finops/toolkit/hubs/configure-ai

Creating Skills for Copilot Studio Agents: How to use the SKILL.md and Behavior-as-Code

Holger Imbery — Sat, 01 Aug 2026 00:00:00 +0000

Summary Lede : In the latest Copilot Studio agent experience, a Skill is the place where you include the detailed knowledge of how your organization carries out a task—information that a model cannot work out on its own. Each Skill is a compact unit consisting of a name, a description, and Markdown instructions that the orchestrator loads only when the task matches. If the instructions alone are not sufficient, a Skill may also contain scripts, templates, and reference files.

We explore what a Skill is, how to write a SKILL.md file, how to bundle code and resources, how the orchestrator chooses a Skill, and how Skills should be authored, managed, and governed. It deals exclusively with the new Markdown-based Skills; the earlier Bot Framework ‘skill’ is merely given the same name, with the differences being explained in section 11.

Why read this

You want to write your first SKILL.md and get it right the first time.

You have a lot of procedural guidance in one big instruction block and want a better, modular way to organize it.

You need to bundle scripts and resources with your Skill and want to understand what runs and where.

The word ‘skill’ is confusing because of the old Bot Framework skill—section 11 explains the difference.

What a Skill is and what it isn’t

A skill shows the agent how to deal with a group of tasks; it is defined by three things: a name, a description, and Markdown instructions.

Figure 1 — Where a Skill fits. Knowledge supplies the facts, Tools carry out the actions, and a Skill provides the know-how needed to carry out a task. The orchestrator then brings these together when required.

It helps to compare Skills to the other components inside an agent:

A tool connects to an external service. A Skill doesn’t.
Knowledge supplies reference facts. A Skill doesn’t.
A Skill provides the procedure—the step-by-step way your organization does something that the model can’t figure out on its own.

Knowledge -> facts the agent can look up
Tools -> actions the agent can take
Skills -> the know-how to use both well

There are two important things to know. First, the format is not unique to Copilot Studio: Skills use the Agent Skills open format, which started with Anthropic and is now also used by GitHub Copilot and Claude Code. Second, a Skill guides the agent instead of forcing it. The model still looks at the situation and decides whether to follow the Skill exactly or adjust. The Skill just makes sure the right procedure is available when needed.

Why factor behavior into a Skill

A Skill is just a set of instructions, so you might wonder why separate them at all. There are four reasons: two apply almost everywhere, and two depend on your situation.

Manageability. Each Skill is a focused unit you can review and version on its own, instead of one instruction blob that keeps growing.
Context management. Skills load only when needed. By default, the agent keeps just the names and descriptions, and brings in the full instructions when a task matches. This means that having ten Skills only adds ten short descriptions per turn, not ten full sets of instructions, so the context window stays small.
Accuracy. A Skill can include detailed guidance on using tools—such as which tool to use, which parameters are important, how to write a query, what to check before calling, and what to do if a tool returns nothing. This guidance loads only when it’s relevant. With large or overlapping toolsets, this can make tool calls more reliable. However, it depends on your use case, so please test it rather than assuming it will work.
Speed and cost. When you guide the agent to the right approach, it does fewer searches, tool calls, and reasoning steps before answering. This also depends on your use case, so be sure to measure it.

Anatomy of a SKILL.md

Every Skill is the same shape: YAML front matter (name and description) followed by a Markdown body (the instructions).

---
name: architecture-review
description: Reviews solution designs for compliance with enterprise
  architecture standards. Use when the user asks for architecture
  validation, design critique, platform fit, or governance review.
  Do not use for cost estimation or licensing questions.
---

# Objective
Review a solution architecture and identify risks, gaps, and recommendations.

# Process
1. Identify the business goal.
2. Extract the proposed architecture.
3. Check integration, security, data, and governance concerns.
4. Identify missing decisions.
5. Produce a concise review with risks and recommendations.

# Rules
- Do not assume undocumented requirements.
- Separate facts from recommendations.
- Highlight open questions.
- Prefer enterprise platform standards where applicable.

Figure 2 — Anatomy of a SKILL.md file. The YAML front matter acts as routing metadata, and the Markdown body contains the behavior. The front matter (name and description) is what the runtime reads to decide when the Skill applies. The Markdown body is the behavior, and it loads only when the Skill is activated.

Naming. Use only lowercase letters, numbers, and hyphens, with no hyphen at the start or end (for example: customer-support-escalation). Choose a clear, descriptive kebab-case name. When you download a Skill, the file uses this name, so a good name makes for a good filename. The open format limits names to 64 characters and descriptions to 1024.

The description is important. It acts as routing metadata for the runtime, not just a comment for people. The orchestrator reads it to decide if the Skill fits a request. For example, ‘Helps with architecture’ is too vague and may activate at the wrong times. A good description explains what the Skill does, when to use it, and when not to use it. This helps the orchestrator choose the right Skill at the right time.

Adding code: bundling scripts and resources

For many Skills, instructions alone are enough. If you need to include more than just text, package everything as a ZIP file with SKILL.md at the root and any supporting files you need. The open format uses this folder structure, and Copilot Studio supports it now:

my-skill/
├── SKILL.md # required: metadata + instructions
├── scripts/ # optional executable code (e.g. Python)
├── references/ # optional documentation the Skill can consult
└── assets/ # optional templates and other resources

Two things to know about the code part:

Bundled scripts run in the agent’s sandbox when needed. A Skill can include a Python script and reference it in its instructions; the script loads when the Skill is selected. For example, the CAT gallery’s PowerPoint Deck Designer builds decks from a JSON spec using python-pptx in the agent’s Python container, without needing an external Azure Function. Microsoft’s CAT team plans to release a detailed guide on scripts and resources, so check runtime details in Preview as they may change.
Skills can also point to the agent’s own tools, not just bundled scripts. Instructions can say ‘use the order-lookup action here,’ referring to actions, flows, connectors, or MCP servers the agent already has. This is a soft pointer: the Skill names the capability but does not bind to it or grant access. If the agent does not have that tool, the step cannot be completed. Even if the tool exists, the orchestrator still decides whether to use it.

How the orchestrator finds and runs your Skill

You don’t call a Skill directly. The orchestrator selects it from its name and description when the conversation matches, then follows the instructions step by step, including reaching for the right tool at the right moment.

Figure 3 — Progressive disclosure. Only names and descriptions sit in context by default; on a matching prompt, the orchestrator loads that Skill’s full instructions (and any bundled scripts or resources), then the agent acts on its general instructions plus the Skill plus the knowledge and tools it needs.

This works because Copilot Studio registers knowledge, tools, and Skills in the same way: only their metadata is kept in context by default, and the full content loads on demand when a prompt matches. The agent’s top-level instructions are the exception—they are always loaded in full. This approach is called progressive disclosure, or dynamic loading, and it helps keep large agents manageable.

Agent context (always): general instructions
In view by default: metadata for Knowledge A,B,C · Tools A,B,C · Skills A,B,C
User prompt -> orchestrator evaluates: which Skill matches?
Match: Skill B -> load Skill B's full instructions (+ optional scripts/resources)
Agent acts on: general instructions + Skill B + the knowledge/tools it needs

The reasoning view is your main place for debugging. You can watch the orchestrator load a matching Skill and see how it follows the instructions. Use this view to adjust when Skills activate:

Fires too often → the description is too broad.
Never fires → too narrow, or it doesn’t match the words your users actually use.

Creating a Skill in Copilot Studio: three ways

Prerequisite for all three: an agent created in the new experience. Skills live in the Skills area of the agent’s Build tab.

Path A — create from blank

Open your agent and select the Build tab.
In the components panel, select Skills.
In Add skill , select Create from blank.
Fill in the three pieces that matter: Name (kebab-case), Description (what it does, when to activate, and when not to), and Instructions (Markdown: steps, response formats, constraints, edge cases).
Select Create. The Skill appears in the components panel.

Next, test it in the Preview tab to make sure it activates and works as expected. Skills you create from blank remain editable.

Path B — with chat assistance

You can also create a Skill by drafting it in a chat, instead of starting from scratch. The result is the same portable Skill, but the chat helps you shape the name, description, and instructions. You can refine it later in the configuration panel.

Path C — author externally and upload

If you prefer your own editor and source control, you can write the Skill as a file and upload it. In the components panel, select Skills , then Add skill and choose Upload a skill. Drag and drop the file onto the upload box or browse to it. The system will check the file and add the Skill.

Accepted upload format	Contents
Markdown file (`.md`)	Skill name and description in YAML front matter, plus Markdown instructions.
ZIP package (`.zip`)	Must include a SKILL.md (front matter + instructions). May optionally include supporting files: scripts, templates, reference documents.

Current scope. Once you add a Skill, it belongs to that agent. If you add the agent to a Power Platform solution, the Skill moves through your ALM lifecycle with it. As of mid-2026, there is no shared, cross-product catalog—distribution is per agent—but a better way to share Skills is being developed.

Writing instructions that actually work

Write the body in Markdown and cover at least five things:

The task the Skill handles, stated up front.
Step-by-step guidance for how the agent should respond.
Formatting for the response — length, structure, what to emphasize.
Edge cases and how to handle them.
Tool references , where they apply.

Write the description as routing metadata. This is the part that makers most often get wrong.

Name specifically: HR Leave Eligibility Triage, not HR Help.
Say when to use it — and when not: “Use for leave eligibility and required documentation. Do not use for payroll or benefits enrollment.”
A good test: if two reasonable makers would disagree about when the Skill applies, the description is not specific enough yet.

Pick the shape the job needs. A Skill can take whatever form fits the task. This menu helps when you’re deciding what to write:

Think of a Skill as a…	Useful when the job is…	Example
Reference manual	Understanding a proprietary data model or schema the model doesn’t know	Documenting your data model so a data tool returns the right thing
Specialist you call in	A narrow area of expertise needed only occasionally	Region-specific tax rules, applied only when that region comes up
Playbook	There’s a known set of plays for a recurring situation	Triaging a support request: classify, then route by category
Standard operating procedure	A task must be done the same, compliant way every time	Handling a refund within policy windows and approval limits
Briefing pack	The agent needs background before it can act well	Onboarding context read before answering HR questions
Checklist	Certain validations must not be skipped	Pre-submission validation before a record is created
Protocol	There are firm rules for a sensitive case	What to do when a user reports a suspected security incident
Runbook	An operational task has defined steps and failure handling	Run a pipeline: discover, analyze, add an ROI pre-scan, format the result
Template	Output must follow a fixed structure or house style	Generating a standardized report to a fixed format

Start simple and improve your Skill based on Preview testing. It’s better to have a small, correct Skill than a large, vague one. You can add edge cases after the main process works.

A worked example, end to end (illustrative)

This is an example package that follows the documented format. Use it as a pattern, not as official sample text.

SKILL.md:

---
name: customer-support-escalation
description: >-
  Use when a customer reports an issue a previous reply did not resolve,
  requests a refund or credit above the standard threshold, or explicitly
  asks for a supervisor, manager, or human agent. Do not use for general
  product questions or order-status lookups.
---

# Customer support escalation

## When to use this skill
Activate when the user:
- Reports an issue a prior response did not resolve
- Requests a refund or credit above the standard threshold
- Explicitly asks for a supervisor, manager, or human agent

## Steps
1. Acknowledge the concern and apologize briefly.
2. Collect the order or case number, a one-line summary, and the desired outcome.
3. Use the **Create Ticket** action to open a ticket with priority = High.
4. Confirm the ticket number and the expected response window.

## Response format
- Keep responses under 120 words.
- End every response with the ticket number in **bold**.

## Edge cases
- If no order number is available, ask once, then proceed with the email on file.
- Never promise a specific refund amount; state that a specialist will confirm.

Package it as a ZIP with SKILL.md at the root and any resources the instructions refer to:

customer-support-escalation.zip
├── SKILL.md
├── scripts/
│ └── format_ticket.py # optional helper the instructions can reference
├── assets/
│ └── escalation_reply.md # optional response template
└── references/
    └── refund_policy.md # optional reference document

There are two code mechanisms here: step 3 points to the agent’s Create Ticket action (a tool the agent must already have), while scripts/format_ticket.py is a bundled script that the Skill includes and references directly.

Managing Skills across their lifecycle

The Skills section of the Build tab lists every Skill on the agent. From there:

View — the section shows everything you’ve added.
Edit (blank-created Skills) — select it, update Name , Description , or Instructions , then Save and re-test in Preview.
Download — open the Skill’s panel. For a Skill you created from blank, use the Download icon. For an uploaded Skill, use the menu and select Download. The file downloads as Markdown (with name and description in the front matter, plus instructions), and the filename matches the Skill’s name.
Replace (uploaded Skills) — edit the file in your editor, then … → Replace and browse to it. You can also swap in a different Skill.
Delete — select the X and confirm. Deletion is permanent for that agent, so download the Skill first if you might want to keep it.

Should it be a Skill, an instruction, or a new agent?

Two decisions come up constantly.

Figure 4 — Where a piece of guidance belongs. If the agent can infer it from a good tool or knowledge description, leave it out. If it’s true in every conversation, put it in instructions. If it’s only needed sometimes, make it a Skill.

Instruction, or a Skill? By the time you’re weighing this, one thing is settled: the agent can’t infer this on its own. The only question is where it goes.

Is it something the agent can infer from tool/knowledge descriptions?
        └─ Yes -> leave it to the agent; don't write it down
        └─ No -> Is it true in EVERY conversation, for every scenario?
                     └─ Yes -> put it in the agent's INSTRUCTIONS
                     └─ No -> make it a SKILL (situational, loaded on demand)

Tone, the agent’s role, and always-on guardrails are always true, so they go in instructions. Anything that applies only in certain situations should go in a Skill.

Skill, or a new agent? Before Skills, the instinct for every distinct task was another specialized agent. But three tasks that share the same audience and knowledge boundary are often one agent with three Skills, not three agents. Two things still point to a separate agent:

It would stand on its own. An HR assistant and an IT support agent serve different audiences behind different security boundaries — build the agent.
If one agent has too many tools, its accuracy can drop as the context gets crowded, and adding more Skills won’t fix it. When this happens, split the work into a separate agent and let it handle that part. Test this with your own agent to see what works best.

The naming trap: this is NOT a Bot Framework skill

Keep this one clean. Copilot Studio has used the word skill before, and the two meanings are unrelated.

Figure 5 — The naming trap. There are two different things called Skill: the new SKILL.md Skill and the legacy Bot Framework skill. They only share a name; the format, runtime, and how you use them are different. In this article, ‘Skill’ always means the new Markdown format.

Term	Legacy (classic) meaning	New-experience meaning
Skill	An externally registered bot capability (Bot Framework / Microsoft 365 Agents SDK), added via a manifest URL	A Markdown-based reusable instruction module (SKILL.md)
Format	Manifest / registration-based; hosted bot endpoint	SKILL.md — YAML front matter + Markdown package
Where it runs	An external Azure Bot Service bot	Inside the Copilot Studio agent (new experience)
How it’s invoked	Trigger phrases + an allow-listed skill call	The orchestrator matches the Skill’s description
Primary value	Integration with external, pro-code bot logic	Modular, reusable behavior and instruction reuse

The classic sense is still real and still documented: you can convert a bot into a skill and register it via a manifest , and Copilot Studio supports skills built on Bot Framework SDK 4.12.0+ and Microsoft 365 Agents SDK v1.0.0+. Microsoft’s guidance on using a classic chatbot as a skill is explicit that it applies to classic chatbots only and isn’t available for Copilot Studio agents.

How to tell which one a document means: a SKILL.md, YAML front matter, or a ZIP package means the new model. A skill manifest , an allow list, an Azure Bot Service bot, or “classic chatbot” means the legacy model — and it doesn’t apply to the agents here. Throughout this article, **skilSkilleans the new Markdown format.

Treat Skills as a trust surface — and a governed asset

A Skill affects how the agent behaves, and since it can now include scripts, it is a trust surface. Treat any Skill you did not write—whether it comes from the community, is generated by AI, or reused from another environment—like untrusted code: review it before adding it. Check for prompt injection, instructions that misuse tools, or anything that does not match what the SkilSkillsupposed to do.

Reuse has pros and cons: one SkilSkill improve many agents, but a bad Skill can spread problems just as widely. Governance needs to keep up with this:

Store shared Skills in version-controlled repositories ; use pull requests for changes to the important ones.
Give each Skill an owner , and keep a changelog for production ones.
Keep descriptions precise and testable —they are routing metadata (see sections 3 and 7).
Avoid broad, overlapping Skills that compete for activation.
Separate policy knowledge (→ Knowledge) from procedure (→ Skill).
Test with realistic user requests, and review high-impact Skills with security, compliance, legal, or architecture stakeholders.

Because Skills are just Markdown files, they can be version-controlled, used with Git, reviewed through pull requests, and moved between agents. This keeps behavior as a long-lived, inspectable asset. Many call this Behavior as Code : a Center of Excellence maintains approved Skills, an architecture board owns review Skills, legal publishes controlled guidance, and delivery teams own documentation Skills—all reviewed and versioned.

You don’t have to start from scratch — the CAT Agent Skills gallery

You don’t have to write every SkilSkillm scratch. Microsoft’s Customer Advisory Team (CAT) publishes CAT Agent Skills, a gallery of skills for your AI agents. These are community-contributed instruction and script bundles you can download as Markdown (and scripts) and add to Cowork, Copilot Studio, or Scout. The gallery lets you filter by platform (Copilot Studio has about 42 entries at the time of writing) and by type—Skills, Plugins, Automations—with tags like productivity, documents, automation, governance, and presentations.

A few entries teach authoring as much as they do a job:

Skill	What it does	Why it’s a good example
Skill Authoring Coach	Helps makers design concise, reusable Skills with clear triggers, instructions, resources, and packaging	A meta-skill — use it to write better Skills
PowerPoint Deck Designer	Builds decks from a JSON spec with python-pptx, running natively in the agent’s Python container	Shows a Skill that bundles a script and runs code in the sandbox
Knowledge Source Router	Routes searches to the right region-specific source so answers stay locally accurate	A pure procedural Skill — behavior, not data or actions
Iterative File Editing	Version-numbers each edited file so every update actually lands	A tiny Skill fixing one specific behavior — the ideal narrow scope
Universal Document Converter	Converts between Markdown, HTML, PDF, Word, PowerPoint, and Excel offline with sandbox libraries	Self-contained, no-external-dependency packaging
Brand Voice Pass	Rewrites drafts to a house style	A classic Center-of-Excellence governance Skill, reused across agents

The main idea is not any single entry, but the operating model. Because these are Markdown packages using the open Agent Skills format, a gallery like this works like a package registry for behavior : you can browse, download, add, and adapt them. Treat any imported Skill like a third-party dependency: read it, test it, and version it before using it in production (see section 12).

A creating-skills checklist

Agent created in the new experience ; you’re working in Build → Skills.
Name is kebab-case , no leading/trailing hyphen, ≤64 characters.
Description reads as an activation contract — what it does, when to use it, and when not to (≤1024 characters).
Instructions cover task, steps, formatting, edge cases, and tool references.
Any scripts/templates/reference files are bundled in a ZIP with SKILL.md at the root; the body references them explicitly.
Tool usage is via soft-pointers to capabilities the agent actually has.
Validated in Preview , and checked in the reasoning view for correct activation (not too broad, not too narrow).
A copy kept in source control for versioning, review, and reuse.
Confirmed you’re building a SKILL.md skill , not a legacy Bot Framework skill manifest.

Conclusion

Creating a Skill is meant to be simple: write a SKILL.md file, describe when it applies as if you were programming a router, add scripts or resources only if needed, upload it, and watch it work in the reasoning view. The key is to focus on the description and scope—a precise trigger, a narrow job—and to treat each Skill as a reviewable, versioned asset, not just a quick prompt.

If you follow this approach, you get what the model is designed for: instructions stay lean because situational behavior is kept in modules that the orchestrator loads only when needed. Since Skills use the open Agent Skills format shared with Claude and GitHub Copilot, behavior you write once can be reused elsewhere. That’s why SKILL.md is becoming a building block beyond Copilot Studio.

Sources

Microsoft Learn — Skills overview for agents (preview)
Microsoft Learn — Create a skill for an agent (preview)
Microsoft Learn — Add an existing skill to an agent (preview)
Microsoft Learn — Manage and delete skills in an agent (preview)
The Custom Engine (Microsoft CAT) — Modern Agents Have Skills Now — Here’s How They Work in Copilot Studio
Microsoft CAT — CAT Agent Skills gallery
Microsoft Learn — Use a classic chatbot as a skill in a Bot Service bot (legacy Bot Framework skills — classic only)
Anthropic — Agent Skills overview (SKILL.md, YAML front matter, progressive disclosure)

Copilot Studio Reimagined: The New Agent Experience, the Agentic Orchestrator, and the SKILL.md Revolution

Holger Imbery — Sat, 25 Jul 2026 00:00:00 +0000

Summary lede Microsoft’s 2026 rebuild of Copilot Studio is far more than a coat of paint. Beneath the reduced tab count and the natural-language authoring surface sits a fundamental shift in how agents are designed, orchestrated, and maintained.

The classic model centered on topics, triggers, and conversation paths. The rebuilt experience introduces a new agentic orchestrator , reusable Skills authored in Markdown , Memory as a first-class capability, a redesigned workflow experience, and tighter alignment with Microsoft IQ and Microsoft Foundry (formerly Azure AI Foundry).

The result is a platform that increasingly resembles an agent engineering environment rather than a chatbot builder.

Figure 1 — The core shift: from predicting every conversation path to describing an agent’s capabilities and letting the orchestrator decide how to combine them.

Why read this :

Read this if you opened Copilot Studio after Build 2026 and wondered where the familiar tabs, topics, and configuration surfaces went.

Read it if you spent the last year designing agents around generative orchestration, child agents, and topic structures, and want to understand Microsoft’s new direction.

And read it if the phrase SKILL.md keeps appearing in discussions about Copilot Studio, GitHub Copilot, Claude, and modern agent architectures — because it is now the same idea in all of them.

This article examines the architecture behind the new experience, explains what the orchestrator changes in practice, and explores why reusable Markdown-based skills may become one of the most important design patterns for enterprise AI agents.

What changed, in one paragraph

The rebuilt Copilot Studio replaces the classic, conversation-centric architecture with an agent-centric model. Instead of authoring explicit topics, flows, and branching logic, you describe the agent in natural language and the system generates the underlying configuration. The agent is assembled from a small set of capability components — Skills, Tools, Knowledge, and Connected Agents , complemented by Memory (preview) — and a new agentic orchestrator decides at runtime how to combine them. Reusable SKILL.md files let behavior be modularized and shared across many agents.

The short version:

Old Copilot Studio: Design the conversation.
New Copilot Studio: Design the agent's capabilities.

One important nuance the marketing sometimes blurs: the new agent experience runs alongside the classic experience, and the two are not convertible in either direction. This is a parallel platform, not an in-place upgrade.

From conversation design to agent design

For years, Copilot Studio inherited concepts from its chatbot origins. A typical implementation included topics, triggers, branching logic, topic transitions, explicit conversation paths, and deterministic fallback behavior. Designing an agent often meant predicting every possible user journey.

That model worked well for structured support bots, FAQ scenarios, guided intake flows, and transactional assistants. But it became hard to maintain when agents needed to do more complex work — interpret ambiguous goals, work across multiple systems, select tools dynamically, call specialized agents, handle large documents, recover from partial failure, or execute multi-step tasks without a hand-authored branch for every path.

The new model moves responsibility away from hand-authored conversation paths and toward the orchestrator. Instead of modeling every branch, makers define:

what the agent knows ,
what actions it can perform,
what expertise it should apply,
which agents it can collaborate with,
and what constraints it must obey.

The orchestrator determines how these components combine to accomplish the user’s objective. This is a different engineering mindset. In the classic model, the maker designs the dialog. In the new model, the maker designs the operating environment of the agent.

The new authoring experience

One of the most visible changes is the simplified authoring surface. Microsoft reduced the workspace from nine configuration tabs to four :

Build · Preview · Evaluate · Monitor

It’s worth being precise here, because it is easy to conflate two different things:

The four tabs above are the workspace — where you build, test, evaluate, and monitor an agent.
The five capability components below are what you actually assemble inside the Build tab.

Figure 2 — The four workspace tabs are distinct from the five capability components. Behavior maps to Skills, actions to Tools, context to Knowledge, delegation to Connected Agents, and continuity to Memory.

Skills — reusable behavior

Skills define how an agent should approach a specific type of task. They are self-contained sets of instructions written in Markdown , and they can be created, uploaded, reused, exported, and shared across agents.

Tools — external actions

Tools let the agent do something outside the language model itself: Power Automate flows, connectors, APIs, MCP servers , and Microsoft 365 or business-system actions.

Knowledge — grounding

Knowledge gives the agent trusted context: SharePoint, Dataverse, uploaded files, enterprise data, and organizational data through Microsoft IQ.

Connected Agents — delegation

Specialized agents that can be delegated work. This enables multi-agent patterns where one agent acts as a front door, router, supervisor, or coordinator while others provide domain-specific capabilities.

Memory (preview) — continuity

Persistent, per-user context that survives across sessions. Memory is a maker-toggled capability that lets an agent remember details from prior interactions and apply them later. It does not replace durable business state in systems such as Dataverse — more on that distinction in §14.

The most important architectural consequence: behavior is no longer trapped inside one giant instruction block or hidden across many conversation branches. It can be factored into reusable, named capabilities.

Behavior -> Skills
Actions -> Tools
Context -> Knowledge
Delegation -> Connected Agents
Continuity -> Memory

The agentic orchestrator: the real innovation

The interface redesign is visible. The orchestrator redesign is transformative.

Microsoft describes the new experience as being built on a new agentic orchestrator — its words: built on “a new coding harness and CLI layer,” with “stronger instruction adherence and long-horizon task execution.” It supports recursive task execution , can “process large volumes of content,” and can “produce rich file outputs.” Microsoft Learn frames it as an enhanced orchestration runtime that improves reasoning quality and response quality, particularly over Microsoft 365 data — and, unlike the classic experience, this enhanced model is not configurable ; every agent in the new experience uses it.

Unlike earlier models that leaned on predefined flows, the new orchestrator behaves like a modern AI agent runtime. Its responsibilities include:

interpreting user intent,
selecting relevant skills,
choosing appropriate tools,
combining grounding sources,
delegating work to connected agents,
validating intermediate results,
and generating the final answer or artifact.

This matters because modern enterprise agents rarely operate as simple question-answering bots. They need to perform work , plan , and decide when to retrieve information, call a tool, delegate, or ask for what’s missing. The orchestrator is the layer where that decision-making happens.

A note on the model. Copilot Studio’s model picker surfaces multiple frontier models (including Claude models). You will see community posts describing the orchestrator as powered by Claude but there is no official orchestrator product name beyond “the agentic orchestrator”, and the model is selectable rather than a fixed brand. Treat “powered by Claude” as shorthand for Claude models are available not as an official label.

Planning instead of branching

The difference is easiest to see side by side.

Figure 3 — The classic model walks a predefined path (User → Topic → Branch → Action → Response). The agentic model hands a user goal to an orchestrator that reasons, plans, and assembles the work at runtime.

This seemingly subtle change introduces a completely different way of thinking. The agent is no longer navigating a predefined conversation — it is executing a plan.

That does not mean deterministic workflows disappear. They remain essential for approvals, state transitions, compliance checks, and business-critical processes. But their role changes. In the classic model, deterministic logic often carried the conversation. In the new model, deterministic logic becomes the guardrail, workflow backbone, or execution layer around an agentic core.

Figure 4 — A practical enterprise pattern: an agentic core reasons and adapts, while a deterministic layer (workflows, connected agents, validation) provides the guardrails and executes the controlled steps.

This is much closer to how modern agent systems are being built across the wider AI ecosystem.

Skills: the most important new capability

Among all the new features, Skills may prove the most strategically important.

Microsoft defines skills as reusable capabilities that extend what an agent can do. Crucially:

Unlike tools , they do not connect to external services.
Unlike knowledge , they do not provide reference material.
Skills provide procedural expertise and reusable behavior — they tell the agent how to approach a class of tasks.

Examples:

how to review an enterprise architecture proposal,
how to classify an incoming support request,
how to write a customer-facing incident summary,
how to create a governance-compliant project document,
how to evaluate whether a process should be automated,
how to prepare a Power Platform solution review.

Previously, this kind of procedural guidance lived in one of three places: the main instruction block, topic-specific prompts, or undocumented maker knowledge. Skills give it a dedicated, reusable home.

What is a SKILL.md?

At its simplest, a skill contains a name , a description , and a set of instructions written in Markdown. Copilot Studio’s format is deliberately standard: YAML front matter (name, description) plus a Markdown body, packaged — when you need to ship more than instructions — as a ZIP that contains a SKILL.md file and optional supporting files such as scripts, templates, and reference documents.

The orchestrator examines the description to decide whether the skill is relevant to a request. If it is, the instructions are loaded into context. If it is not, they stay out of the active context window. This solves one of the most persistent problems in enterprise agent design: instruction bloat. Instead of thousands of lines of always-active instructions, behavior is separated into focused, reusable modules.

A typical SKILL.md looks like this:

---
name: architecture-review
description: Reviews solution designs for compliance with enterprise
  architecture standards. Use this skill when the user asks for architecture
  validation, design critique, platform fit, or governance review.
---

# Objective
Review a solution architecture and identify risks, gaps, and recommendations.

# Process
1. Identify the business goal.
2. Extract the proposed architecture.
3. Check integration, security, data, and governance concerns.
4. Identify missing decisions.
5. Produce a concise review with risks and recommendations.

# Rules
- Do not assume undocumented requirements.
- Separate facts from recommendations.
- Highlight open questions.
- Prefer enterprise platform standards where applicable.

Figure 5 — The front matter is not documentation for humans; it is routing metadata for the runtime. The body is the task behavior, loaded only when the skill activates.

The consequence is important: the description is routing metadata for the agent runtime , not a human-facing comment. A vague description produces unpredictable activation. A precise one — stating what the skill does and when to use it — helps the orchestrator select the right capability at the right time. (In the wider open format, the practical limits are a name of ≤64 characters and a description of ≤1024 characters.)

How the orchestrator loads behavior

Skills are only half the story. The other half is how they reach the model — and this is where the design earns its keep.

Copilot Studio registers knowledge, tools, and skills the same way: only their metadata — names and descriptions — sits in context by default. The full content is pulled in on demand , when a prompt matches. The agent’s own top-level instructions are the exception: those are always loaded in full.

Figure 6 — Progressive disclosure: the orchestrator keeps only names and descriptions in view, then loads a skill’s full instructions (and any bundled resources) when its description matches the request.

This pattern — often called progressive disclosure or dynamic loading — is what keeps large agents manageable. As one Microsoft community write-up puts it, ten skills cost you ten short descriptions, not ten full sets of instructions, in every turn. The practical benefits:

Manageability — each skill is a focused unit you can review and version on its own.
Context economy — the context window stays lean no matter how many skills exist.
Accuracy — a skill can carry precise tool-use guidance, brought into context only when relevant (validate this per agent rather than assuming it).
Speed and cost — nudging the agent toward the right approach cuts round-trips (again, measure it).

Why SKILL.md changes enterprise architecture

The significance of the format extends beyond Copilot Studio. Because skills are Markdown files, they become version-controlled, Git-native, reviewable through pull requests, shareable across teams, portable between agents, and maintainable as long-lived enterprise assets.

This is what some now call Behavior as Code. Instead of embedding organizational know-how inside prompts, teams maintain curated repositories of reusable capabilities:

/skills
  /architecture-review SKILL.md
  /power-platform-governance SKILL.md
  /customer-incident-summary SKILL.md
  /proposal-quality-check SKILL.md
  /brand-voice SKILL.md

Figure 7 — A new operating model: a Center of Excellence maintains approved skills, an architecture board owns review skills, legal publishes controlled guidance, marketing owns brand voice, and delivery teams own project-documentation skills — all version-controlled and reviewed.

This enables a new operating model. A Center of Excellence can maintain approved skills. Architecture boards can define review skills. Legal and compliance can publish controlled guidance. Marketing can own brand and tone. Delivery teams can create reusable documentation skills. Once authored, these capabilities are reused across many agents — turning agent behavior into a governed, reusable, inspectable asset.

One open format, many runtimes

Here is the part that makes SKILL.md more than a Copilot Studio feature: it is not a Microsoft invention. Microsoft states plainly that Copilot Studio skills are “based on the Agent Skills open format, an open standard originally developed by Anthropic,” and that you can “import skills you already have, including existing GitHub Copilot or Claude Code skills.”

That means the same anatomy now appears across vendors:

Anthropic Claude — Agent Skills: a SKILL.md with YAML front matter (name, description) and a Markdown body, plus optional bundled resources, loaded via three-level progressive disclosure.
GitHub Copilot / Visual Studio 2026 — skills follow the agentskills.io specification: a directory containing a SKILL.md with the same required front matter, discovered from paths such as .github/skills/, .claude/skills/, and .agents/skills/.
Microsoft Copilot Studio — the new-experience Skills described throughout this article.

Figure 8 — The same open format across three runtimes: a directory plus SKILL.md, YAML front matter (name + description), a Markdown body, optional resources, and progressive disclosure. Behavior written once can travel between agents and vendors.

The strategic implication is large. For the first time, a piece of behavior — not code, not a model, but the procedural know-how of how your organization does something — can be written once and run across multiple agent runtimes. Skills become portable enterprise assets in the same way that container images or OpenAPI specs are.

Reality check. Convergence is real, but maturity varies. Visual Studio 2026 ships built-in Microsoft skills but keeps them off by default while it measures whether their token cost is justified — a reminder that “portable” does not mean “free,” and that every skill you load has a context window and cost footprint worth evaluating.

Skills versus tools versus knowledge

The distinction is worth internalizing, because clean separation is one of the most important architecture disciplines in the new model.

Component	Purpose	Example
Instructions	Overall identity and behavior	“You are a procurement support agent.”
Knowledge	Information retrieval and grounding	SharePoint policies, Dataverse records, product docs
Tools	Performing actions	Create ticket, update CRM, send approval request
Skills	Task-specific expertise	“How to review a vendor onboarding request”

A tool might create a SharePoint document. A skill explains how that document should be created according to organizational standards. Knowledge provides the policy that should be referenced. Instructions define the agent’s overall role. The orchestrator combines all of these at runtime.

A mature design therefore does not ask, “Should this be a prompt, a tool, or a knowledge source?” It asks a more precise question:

General behavior? → Instructions
Task-specific procedure? → Skill
Reference information? → Knowledge
External action? → Tool
Specialist ownership? → Connected agent

The naming trap: two different meanings of “skills”

There is one real source of confusion. Copilot Studio has used the word skills before, and the two meanings are unrelated.

Term	Classic meaning	New-experience meaning
Skill	An externally registered bot capability (Bot Framework / Microsoft 365 Agents SDK), added via a manifest URL	A Markdown-based reusable instruction module (`SKILL.md`)
Purpose	Connect to a pro-code bot capability	Provide task-specific behavior
Format	Manifest / registration-based	SKILL.md / Markdown package
Primary value	Integration with external bot logic	Modular behavior and instruction reuse

The classic sense is still documented: you can “convert those bots into a skill and register that skill” via a manifest, and Copilot Studio supports skills built on Bot Framework SDK 4.12.0+ and Microsoft 365 Agents SDK v1.0.0+. When reading documentation or community posts, check which meaning is intended. In this article, skill means the new Markdown-based format unless stated otherwise.

Connected agents and agent specialization

The new experience also strengthens agent collaboration. An orchestrator can understand a request, select relevant skills, use appropriate tools, and delegate to connected agents. (Support for connecting to other agents — via the open A2A / Agent2Agent protocol, Microsoft Foundry agents, and the Microsoft 365 Agents SDK — actually predates the Build 2026 rebuild, arriving around Ignite in late 2025, and now folds cleanly into the new model.)

This creates a natural architecture for enterprises with specialized agents: HR, finance, procurement, architecture, IT support, governance, and customer-operations agents. Skills become the reusable expertise layer shared across those ecosystems. Multiple agents might use the same Executive Summary skill, the same Risk Classification skill, or the same Policy Compliance Review skill.

The separation is clean:

Connected agents define ownership boundaries.
Skills define reusable behavioral patterns.
Tools define system actions.
Knowledge defines grounding.

That separation makes multi-agent architectures easier to reason about and to govern.

Memory and Microsoft IQ

Memory adds another dimension. Classic agents required makers to explicitly persist every piece of state that needed to survive a conversation. For business state , that is still the right approach: a case status, approval decision, contract value, or onboarding step should live in a durable business system such as Dataverse.

But not every form of continuity is business state. Some context is about preferences, patterns, and how work tends to happen. That is where Memory becomes interesting. Microsoft’s Memory (preview) maintains a separate memory store for each user , per agent, in a tenant-scoped store; it captures useful signals, saves them, and applies them on future interactions. (Notably, a user’s memories for an agent are deleted after 28 days of inactivity — Memory is a continuity aid, not a system of record.)

Figure 9 — A simple routing rule: durable business records belong in Dataverse or a business system; learned, contextual continuity belongs in Memory (per-user, per-agent, tenant-scoped).

A useful rule of thumb:

Structured process state -> Dataverse or business system
Learned contextual continuity -> Memory

Accuracy note. The official Memory documentation describes a per-user, per-agent, tenant-scoped file store. It does not describe Memory as being backed by Dataverse. Dataverse remains the place for durable business records and is reachable as a knowledge/tool source — but it is not the Memory backing store. Keep the two mentally separate.

Microsoft IQ then provides the broader grounding layer. It is best understood as an umbrella : a set of capabilities — Work IQ (how people work), Foundry IQ (an organization’s policies and authoritative documents), Web IQ (context from the web), and Fabric IQ (business entities and data) — that form the enterprise intelligence layer of the Microsoft stack. Copilot Studio consumes Microsoft IQ as a grounding source. The design center moves from individual bots to shared agent infrastructure :

From: One bot with its own topics and data
To: Many agents · shared governance · shared knowledge ·
       shared tools · shared skills · shared protocols

Convergence with Microsoft IQ and Microsoft Foundry

Perhaps the most strategic development is neither the orchestrator nor the UI. It is platform convergence.

Microsoft is aligning Copilot Studio, Microsoft Foundry (the rebranded Azure AI Foundry, positioned at Build 2026 as “the platform for building, hosting, and governing long-running AI agents”), Microsoft IQ , MCP , A2A , Microsoft 365 Copilot , and multi-agent architectures around a common foundation.

Figure 10 — Low-code and pro-code remain distinct entry points, but they increasingly share a runtime (orchestration, tools, skills, MCP, A2A), a grounding layer (Microsoft IQ), and a governance layer (Microsoft 365, Entra, Purview, Defender, Agent 365).

This does not mean low-code and pro-code become the same thing. They remain different entry points for different audiences. But the gap narrows:

Low-code makers -> Copilot Studio
Pro-code teams -> Microsoft Foundry
Shared runtime -> Orchestration, tools, skills, MCP, A2A
Shared grounding -> Microsoft IQ (Work / Foundry / Web / Fabric IQ)
Shared governance -> Microsoft 365, Entra, Purview, Defender, Agent 365

On governance, the pieces are real and named. Microsoft Defender, Entra, and Intune provide visibility and runtime protection for agents; Microsoft Purview logs agent activity for traceability; and Agent 365 introduces agent-management capabilities — including an agent registry that surfaces unmanaged local agents. (Precision matters: the Agent 365 SDK is generally available , but several surrounding capabilities are still in preview — don’t blanket-label all of Agent 365 as GA.)

The instruction for platform teams is simple:

Do not standardize only on the authoring tool. Standardize on the architecture.

Organizations don’t have to choose between low-code and pro-code. They can pick the most appropriate authoring environment while sharing common principles: governed access, reusable skills, clear ownership, connected agents, auditable tool use, and enterprise grounding.

Governance implications

The new model increases flexibility — which increases the need for discipline. Skills especially need governance. If a skill can define how an agent behaves, it should be treated as an enterprise asset.

Recommended practices:

Store shared skills in version-controlled repositories.
Use pull requests for changes to important skills.
Define owners for each skill.
Keep skill descriptions precise and testable (they are routing metadata — see §7).
Avoid broad, overlapping skills that compete for activation.
Separate policy knowledge from procedural skill guidance.
Test skills with realistic user requests.
Maintain a changelog for production-relevant skills.
Review high-impact skills with security, compliance, legal, or architecture stakeholders.

The same skill may influence many agents. That makes reuse powerful — but it also means a poorly written skill can propagate flawed behavior across many agents. In the classic world, bad logic was often trapped inside one topic or one bot. In the new world, reusable behavior scales quickly — so review and governance must scale with it.

What architects should do now

The rebuild does not mean every classic agent should migrate immediately. A more nuanced approach:

For new agents

Start with the new experience where the required capabilities are available. Design around Skills (task-specific behavior), Tools (actions), Knowledge (grounding), Connected Agents (delegation), Memory (continuity), and Workflows (deterministic process control). Remember that agents built here cannot be converted back to the classic experience.

For existing classic agents

Do not migrate reflexively. Classic agents still matter, especially where topic structures are stable, tested, and operationally reliable. Consider migration when:

the agent needs a significant redesign,
instruction complexity has grown too large,
topic branching has become hard to maintain,
multi-agent delegation is required,
or reusable skills would clearly simplify the design.

For platform teams

Begin building a skills strategy now. Ask:

Which procedural behaviors are repeated across agents?
Which review processes should be standardized?
Which skills require central ownership, and which can be team-owned?
How should skills be tested?
Where should SKILL.md files live, and how are they versioned and released?

The earlier this discipline is established, the easier it will be to scale agent development responsibly.

Choosing between the new experience and classic — a decision guide

Because the two experiences run in parallel and are not convertible , the practical question isn’t “when do I migrate everything?” — it’s “which experience fits this workload?” Here is a concrete way to decide.

Figure 11 — A side-by-side decision guide: choose the new experience when the value comes from reasoning and adaptivity; keep classic when it comes from predictability and a fixed script.

Reach for the new agent experience (production-ready preview) when:

You are building a brand-new agent and can design it natively.
The work is open-ended and multi-step — the agent must reason, plan, and adapt rather than follow a script.
You want reusable Skills shared across several agents.
You need multi-agent delegation to specialists (connected agents).
A single agent’s instructions have grown large and tangled , and modular Skills would simplify it.
You need Memory , large-content processing, or rich file outputs.

Good fits: a cross-system service agent that triages a request and acts across CRM, ticketing, and SharePoint; a document-heavy analysis-and-drafting agent; a front-door agent that orchestrates HR, finance, and procurement specialists.

Stay on (or keep building in) the classic experience when:

Existing topic structures are stable, tested, and operationally reliable — don’t fix what isn’t broken.
The interaction is deterministic, transactional, and single-turn (place an order, check status).
You need strict, auditable, compliance-locked dialog where every path is scripted on purpose.
A capability you depend on isn’t available in the new experience yet — some classic features haven’t carried over.
You have no appetite to re-test a working production agent right now.
You need workflows in production today — the new workflows experience is public preview , which Microsoft says is not for production, even though the new agent experience is a production-ready preview.

Good fits: an FAQ or guided-intake bot; a regulated, scripted process where deviation is a defect; a simple order-status lookup.

The rule of thumb: choose the new experience when the value comes from reasoning and adaptivity ; keep classic when it comes from predictability and a fixed script. And when you do move an agent, plan the redesign — don’t port the old topic tree one-for-one.

Ready-made behavior — the CAT Agent Skills gallery

You don’t have to author every skill from scratch. Microsoft’s Customer Advisory Team (CAT) publishes CAT Agent Skills, described as “the gallery of skills for your AI agents”: community-contributed, drop-in instruction and script bundles you can download as Markdown (and scripts) and add to Cowork, Copilot Studio, or Scout.

The gallery filters by platform (Copilot Studio, Cowork, Scout) and by content type (Skills, Plugins, Automations), with tags such as productivity, content, documents, automation, and marketing. A few representative entries — useful both as ready-made building blocks and as worked examples for authoring your own :

Skill	What it does	Why it’s a useful example
Iterative File Editing	Gives each edited file a version-numbered name (`report_v1.docx`, `report_v2.docx`…) so every update actually lands in the chat	A tiny skill that fixes one specific, real Copilot Studio behavior — the ideal narrow scope
PowerPoint Deck Designer	Builds polished decks from a JSON spec with `python-pptx`, running natively in the agent’s Python container (no Azure Function needed)	Shows a skill that bundles a script and runs code in the sandbox
Knowledge Source Router	Routes knowledge searches to the right region-specific source (Americas, EMEA, APAC, Global) so answers stay locally accurate	A pure procedural skill — behavior, not data or actions
Brand Voice Pass / Brand Template Enforcer	Rewrites drafts to a house style; ensures decks and docs start from the approved brand template	Classic center-of-excellence governance skills, reused across agents
Meeting Analyzer	Extracts decisions, action items, persona profiles, and hidden insights (unspoken tensions, implicit risks) from a transcript	A rich, opinionated skill with a clear output contract
Universal Document Converter	Converts between Markdown, HTML, PDF, Word, PowerPoint, Excel/CSV, and text — fully offline, using only sandbox libraries	Demonstrates self-contained, no-external-dependency packaging
Microsoft AI Platform Advisor	Interviews a customer and recommends the right platform (M365 Copilot, Agent Builder, Copilot Studio, Foundry, or Agent 365 as the governance layer)	A decision-framework skill — a good template for advisory agents
Skill Authoring Coach	Helps makers design concise, reusable skills with clear triggers, instructions, resources, and packaging	A meta-skill: use it to write better skills

The point isn’t the individual entries — it’s the operating model. Because these are just Markdown packages on the open Agent Skills format (§7, §10), a gallery like this behaves like a package registry for behavior : browse, download, drop in, and adapt. Treat an imported skill the way you’d treat any third-party dependency — read it, test it, and version it before trusting it in production (§16).

Getting started — CAT’s three on-ramps

Moving to modern agents is “a different mental model, not just a new UI,” and Microsoft’s CAT team packaged the on-ramp into three resources, each answering a different question.

Figure 12 — CAT’s three resources: a deep-dive deck to grasp the concepts, a deployable mini-site to see them run, and a migration plugin to try them on a real agent.

Understand it — the Technical Deep Dive deck. Built for builders and architects as a decision framework, not a feature tour. It covers where to build what (agent vs. workflow, and which piece belongs where), how to build modern agents and workflows, how to upgrade without simply porting the old design , and an honest read on what’s improved and what isn’t supported yet.
See it run — the mini-site and sample. A real, deployable Power Platform solution (not screenshots with a story), built around BlastBox Omega , a retro-future game store “run by agents.” Two scenarios make it concrete:
- Self-Serve Card Reissue — an agent handles a member request end to end, gating a real write action behind an identity check and handing back a generated file.
- Block Party Trade-Up — the flagship, where a parent agent coordinates specialist agents to untangle a messy, multi-part request and settle it with a downloadable document.
Upgrade it — the migration plugin. Install the Copilot Studio plugin for AI coding agents and send /migrate with your agent’s environment, tenant, and URL. It pulls the classic agent, analyzes its structure, proposes a modern architecture, and builds an upgraded agent to test:

/mcs-assistant:migrate Upgrade this agent to modern orchestration:
https://copilotstudio.microsoft.com/environments/<ENV_ID>/bots/<BOT_ID>
from tenant <TENANT_ID>. Use a capable AI model.

The guiding principle behind all three is worth pinning above your desk:

Every behavior belongs in the smallest component that makes it reliable and inspectable. Instructions carry what’s always true, Knowledge the searchable facts, Tools the system actions, Memory the persistent context, Skills the situational procedures, and connected agents the real specialist domains.

Or, as the CAT team puts it more bluntly: “a modern agent shouldn’t be one instruction blob with 43 tools and a prayer.”

On migration, mind the word propose. The plugin is “a fast assistant, not a ‘make my architecture correct’ button.” The anti-pattern to avoid is turning “every topic into a Skill and every variable into memory just because they existed — that’s archaeology with YAML.” Instead: understand the task, keep the outcomes that must work, map each responsibility to the smallest right component, then run evals against the core journeys and treat the generated agent as a first draft to inspect and compare against your old tests.

Conclusion

The new Copilot Studio is not simply a modernized interface. It represents a transition from conversation design to agent engineering.

The combination of an agentic orchestrator , modular Skills , SKILL.md portability , Connected Agents , Memory , Microsoft IQ , and stronger alignment with Microsoft Foundry creates a fundamentally different development model than the one that defined Copilot Studio for the last several years.

For architects, the most important takeaway is not the reduced tab count. It is the emergence of reusable behavioral assets — versioned, shared, governed, and loaded dynamically by an increasingly capable orchestrator. The long-term significance of Build 2026 may be summarized in a single sentence:

Microsoft is transforming Copilot Studio from a chatbot builder into an enterprise agent engineering platform.

And because it rests on an open Agent Skills format shared with Claude and GitHub Copilot, SKILL.md may become one of the key building blocks of that transition — not just inside Copilot Studio, but across the industry.

Sources

Microsoft Learn — Agents overview (preview): Microsoft Copilot Studio (new experience)
Microsoft Learn — Skills overview for agents (preview)
Microsoft Learn — Memory (preview) for agents
Microsoft Learn — Configure skills for use in Copilot Studio agents (classic Bot Framework / M365 Agents SDK skills)
Microsoft Learn — Connect to another agent over A2A
Microsoft Learn — Add other agents to an agent (overview)
Microsoft Learn — Fabric IQ overview (Microsoft IQ: Work IQ, Foundry IQ, Web IQ, Fabric IQ)
Microsoft Learn — Agent Skills in Visual Studio (agentskills.io spec)
Microsoft Copilot Studio Blog — Meet the new Copilot Studio: rebuilt for more complex, multi-step work
The Custom Engine (Microsoft) — Modern Agents Have Skills Now — How They Work in Copilot Studio
The Custom Engine (Microsoft) — New Orchestrator, New Rules? CAT’s Got You (migration, samples, deep-dive deck)
Microsoft CAT — CAT Agent Skills gallery
Microsoft Security Blog — Microsoft Build 2026: securing code, agents, and models (Agent 365, Entra, Purview, Defender)
Anthropic — Agent Skills overview (SKILL.md, YAML frontmatter, progressive disclosure)
GitHub Docs — Custom skills in the Copilot SDK
Microsoft Build 2026 — Event dates (June 2–3, 2026)