DEV Community: Holger Imbery

Contact Center Intelligence one month in: what to prepare before the GA dates

Holger Imbery — Thu, 12 Nov 2026 00:00:00 +0000

1. Introduction

For years, my talks with contact center teams went the same way. They liked what Microsoft was doing with AI in Dynamics 365 Customer Service. Then they told me, in a friendly way, that they would not move their contact center. They ran Genesys or another platform, they had a lot of routing logic, years of fine tuning, and a contract that still had a long time to run. So the AI discussion ended there.

Contact Center Intelligence (CCI) is Microsoft’s offer for exactly these customers. It brings Microsoft AI to contact centers that stay on their current platform. The preview has been public for about a month now, and the roadmap points to general availability in November. For me, that means it is time to stop reading announcements and start preparing.

In this article I share how I approach that preparation. I will not repeat the feature list. Instead, I go through the questions I ask customers at the moment. Which CCI features do you really need? Which connector does your setup depend on? What does voice biometrics mean for your governance? And how will Copilot Credits show up in your cost model?

2. What Microsoft announced

First, I want to keep apart what is documented and what is only on the roadmap.

The CCI What’s new page on Microsoft Learn was last updated on October 20, 2026. The October 2026 preview content covers:

Genesys Cloud and a universal connector
Quality assurance
Real-time and historical dashboards
Voice biometric authentication
Reuse of Copilot Studio agents and Foundry

The launch post on the Dynamics 365 blog came out on October 21, 2026. I see it as background. For what is really in the preview, the Learn page is the better source.

The Customer Assist agent page on Learn (updated October 22) has one detail I think many people will miss. You create agents from the CCI portal, using the same builder as Copilot Studio. I come back to this later.

On November 4, the Copilot Studio blog said that the customer conversation harness is now in preview. If you want to see where Copilot Studio is going with agents for customer conversations, read the Copilot Studio October update together with the CCI pages.

The next part comes with a warning. Two public roadmap entries, both dated October 28, point to November:

Roadmap entry 575278, a universal connector for self service omnichannel agents, listed as rolling out, with preview in October and GA in November 2026.
Roadmap entry 575290, Contact Center AI insights and quality, listed as in development, with GA in November 2026.

I did not read these on Microsoft’s own roadmap site. I read them on a third party copy of it. Roadmap entries change often. Dates move, features get split, and the status changes without much notice. So please use these dates for planning only. Do not show them as fixed dates in a steering committee.

3. Why it matters

The simple summary is “Microsoft AI for contact centers that do not run on Dynamics”. That is correct. But for me, it is more useful to look at what CCI is not.

CCI is not a contact center platform. It does not replace your routing, your telephony or your workforce management. It runs next to the platform you already have, and it needs a connector to talk to it. If you expect a migration project, you have the wrong picture. If you expect no integration work at all, you also have the wrong picture.

CCI is also not a separate AI tool on its own. Customer Assist agents use the same builder as Copilot Studio, and the preview includes reuse of Copilot Studio agents and Foundry. To me this says that Microsoft wants CCI to be one more place where you use the agents you already have. If you already built self service agents in Copilot Studio for your website or for Teams, that is a good reason to look at CCI. If you have not, CCI brings Copilot Studio into your contact center project anyway, planned or not.

This is the work I see people underestimate most. The contact center team and the team that runs Copilot Studio are rarely the same people. They have different change processes, different release dates and a very different view of risk. When both use the same builder, they also share the governance questions.

4. Architecture implications

Map the features you need, not the features on the slide

The preview list is long. Quality assurance, dashboards, voice biometrics, agent reuse and the connectors are five different pieces of work, and each has a different owner. With every customer, I start with a simple table. One row per CCI feature. Then a column for the tool that does this job today, one for the owner, and one that says if you want to replace that tool or add to it.

Quality assurance is often the strongest case, because many teams still check only a small number of calls by hand. Dashboards are a different story. You may already pay for similar reports in your contact center platform. That is no reason to skip CCI. But you need to decide which dashboard is the leading one. If two systems show different numbers for handle time or containment, you will argue about it in your first quarterly review.

The connector is your real dependency

The preview names Genesys Cloud and a universal connector. These two options come with very different risks.

If you run Genesys Cloud, you are on the path Microsoft mentions first. In my experience that usually means better documentation, more early customers and quicker fixes. It still means work. You need to know which events and which audio flow through the connector, which permissions it needs in Genesys, and who gets called when it stops working.

If you run another platform, you depend on the universal connector. The roadmap entry for the universal connector for self service omnichannel agents (575278) points to GA in November. Keep in mind what I said above: it is a roadmap entry, I read it on a third party copy, and it can change. The date is not the main question, though. The main question is what “universal” means for you. In most cases, a universal connector means that someone on your side builds and runs the part that is specific to your platform. Find out early who that person is. In my projects it is rarely the contact center team and rarely the Microsoft team. Projects often get stuck right there.

Before any pilot, I would answer these questions:

Which connector do we use, and what is its documented status today (not on the roadmap)?
Which data leaves the contact center platform, in which direction, and how fast does it need to arrive? Real time assist and historical reports need very different things.
What happens to a customer call when the connector is down? The answer should be “the contact center keeps working, just without AI”. Test this.
Who runs the connector day to day, including monitoring and incidents?

Agent reuse is good, until versioning bites

Using the same Copilot Studio agent in several channels sounds good. One agent, one knowledge base, one place to fix wrong answers. The downside is that everything is linked. If the same agent serves your website and your phone line, a change you make for the website can change what callers hear. Voice is also less forgiving. Long answers, links and tables do not work when a voice reads them out.

My advice is to share knowledge and topics where it makes sense. But keep the contact center agent as its own agent with its own release process. Share the parts, not always the whole agent.

5. Governance implications

Voice biometrics needs a governance owner before it needs a pilot

Voice biometric authentication is the feature where I would go slowly. The feature is fine. The hard questions are just not technical ones. A voiceprint is biometric data. Depending on your country and industry, you need consent, a clear purpose, retention rules and a way to delete the data. Your data protection officer will want to see all of this before go live. Here in Germany, and in the EU in general, I expect this discussion to take longer than the technical setup.

Questions to answer first:

How do callers sign up, and how can they say no?
What is the other way to log in, and is it just as secure?
Who can delete a voiceprint, and how do you prove that it is gone?
What happens when the system accepts the wrong person? The business has to decide how much risk is OK. This is not a setting in a portal.

None of this is special to Microsoft. It is the same for every voice biometrics product. But CCI makes the feature easy to switch on, and features that are easy to switch on are the ones where people skip governance.

Quality assurance changes what you measure about people

When software checks every call, that is not the same as a supervisor listening to a few calls each month. Works councils and employee representatives will have an opinion on this, and in Germany they also have legal rights. Talk to them early. Say clearly whether the scores are for coaching or for performance reviews, and write it down. I have seen good AI projects stopped very late because this talk happened after the pilot and not before it.

One builder, two governance models

Customer Assist agents use the same builder as Copilot Studio. So your Copilot Studio governance (environments, data loss prevention policies, who can publish) now also applies to the contact center. Check if your environment strategy has a good place for contact center agents. Otherwise they may end up in a shared environment next to test agents from marketing. I would plan separate environments for them, with their own policies and their own makers.

Credits and cost planning

CCI agents use the Copilot Studio builder, so Copilot Credits are part of the cost. I have not seen a CCI price list that I would plan with. So I will not give any numbers here, and your business case should not include any either until Microsoft publishes them.

What you can do now is build the structure of the cost model. Then you only need to add the prices later:

Volume: number of interactions per month per channel, how many go to self service agents, how many use real time assist, and how many go through quality assurance.
Growth: AI use often grows after go live, because teams find new use cases. Plan for growth over time, not for a flat number.
Ownership: decide which cost center pays for the credits the contact center uses. If the credits come from a pool that other Copilot Studio agents also use, one busy month in the contact center can leave other teams without credits. Track it separately from the first day. That is much easier than sorting it out later.
Alerts: set up usage alerts before go live, not after the first surprise on the bill.

For most companies, the contact center is the channel with the most volume. Small costs per interaction add up faster there than anywhere else.

6. Practical recommendations

If a contact center architect asked me what to do for the rest of November, I would give them this list:

Build the feature map. List the CCI features, the tool that does each job today, the owner, and whether CCI should replace that tool or add to it.
Know your connector. Genesys Cloud or universal connector. If it is the universal one, name the person who builds and runs your side of it.
Use roadmap dates for planning only. Plan for November, but base go live decisions on what is documented on Learn, not on roadmap entries.
Start the voice biometrics governance work now. Data protection, consent, fallback, deletion. This part takes the longest.
Talk to employee representatives about quality assurance before anyone sees a dashboard with agent scores.
Agree on a Copilot Studio environment strategy for contact center agents, including who is allowed to publish.
Build the cost model structure with volumes and ownership, and leave the prices empty until Microsoft publishes them.
Test a failure in the pilot. Switch off the connector and check that the contact center still works.

7. Conclusion

CCI fills a real gap. Many companies will never move their contact center to Dynamics 365. Until now, that meant Microsoft AI did not reach their most important customer channel. One month into the preview, the documented scope is wide, and the roadmap says GA is close.

The useful work now is not reading more announcements. Decide which features you need. Understand the connector you depend on. Get the governance for voice biometrics and quality assurance started. And build a cost model that can handle Copilot Credits without surprises. Teams that do this in November can make a calm decision when GA comes, whenever that is. Teams that wait for the GA announcement will do the same work afterwards, just with more pressure.

Sources:

Claude Inside the EU Data Boundary: What Changes for European Copilot Tenants and What Does Not

Holger Imbery — Tue, 10 Nov 2026 00:00:00 +0000

On November 5, 2026, Microsoft announced that Claude models in Microsoft Copilot will be processed inside the EU Data Boundary for customers in the EU and EFTA by the end of 2026. I wrote this for the people who have to approve that change: architects, CIOs, data protection officers, Microsoft 365 admins, and works councils. Here is my view. This change removes the main reason European tenants had for blocking Anthropic models in Copilot. But it does not make the decision for you. An admin still has to switch it on. And you should handle it like any other model choice, with your own testing, a clear user scope, and proper documentation.

Introduction: why the quick “no” will not work much longer

For most of this year, the Claude question in European tenants was over quickly. Someone in IT saw the Anthropic setting in the Microsoft 365 admin center. They asked the data protection officer. The DPO read that Anthropic models process data outside the EU Data Boundary. The answer was no, and everyone moved on to the next topic.

I understand that answer. It was simple and easy to defend. Many European organizations made the EU Data Boundary part of their Microsoft 365 approval. A feature that sends prompts and grounding data outside that boundary would have meant opening that approval again. In many companies, that approval took months. Nobody wanted to go through it again for a second model family in a product that was already running.

That answer will soon stop working. When Claude runs inside the EU Data Boundary, the location argument is gone. What is left are the harder questions. Does this model help our users? Which users? For which tasks? How do we document it? These questions were there all along. The data boundary just gave us a reason not to ask them.

So I am not going to tell you whether Claude is good or bad. I want to show you how to make the decision properly, now that the easy way out is going away.

What Microsoft announced, and one gap you should know about

The announcement is a post on the Microsoft Copilot Blog by Charles Lamanna, dated November 5, 2026: Bringing Claude models in Microsoft Copilot into the EU Data Boundary. These are the points you need for planning:

Timing. By the end of 2026, Claude models in Microsoft Copilot will be available in the EU Data Boundary for customers in the EU and EFTA.
Scope. This covers Copilot experiences, including Copilot Cowork.
Where Claude is used today. Claude already powers experiences in Copilot Chat, the Microsoft 365 apps, Cowork, and Copilot Code.
Existing users. Customers who already use Claude do not need to do anything. Processing moves on its own once it is available.
Default. The setting is off by default in the EU and EFTA.
Control. Admins can turn it on for all users or for selected groups in the Microsoft 365 admin center.
Residency. The post also says that Microsoft offers in-country data residency for Copilot in 10 EU and EFTA countries.

Now the gap. The Microsoft Learn page Anthropic models in Copilot apps was last updated on November 3, 2026. It still says that Anthropic models process data outside the EU Data Boundary today. The two sources do not contradict each other. The blog describes how things will work “by the end of 2026.” The Learn page describes how things work today. Right now, both are correct.

Until Microsoft confirms that the move is done, turning on Claude in an EU or EFTA tenant still means processing outside the EU Data Boundary. Plan around the date the change goes live, not the date it was announced.

Here is the same information as a before-and-after view:

Aspect	Today (per Learn, Nov 3)	After the move (per blog, Nov 5)
Processing location	Outside the EU Data Boundary	Inside the EU Data Boundary
Default in EU and EFTA	Disabled	Disabled
Who enables it	Admin	Admin
Scope options	All users or selected groups	All users or selected groups
Existing Claude users	Processing outside the boundary	Moved automatically, no action

Most of the rows stay the same. The default is still off. An admin still decides. You can still limit it to groups. The only row that changes is the location.

Why it matters: the discussion shifts from “where” to “is it a good fit”

I expect three effects in practice.

The blocker goes away, but you still have to decide. In many tenants I work with, the EU Data Boundary was the only argument anyone needed. Without it, the organization needs a real reason for a yes or a no. That is a good thing, but it means more work. If your governance board has never talked about model choice as its own topic, it will have to now.

Tenants that already said yes get an improvement without doing anything. Some European organizations accepted processing outside the boundary because certain teams wanted Claude. For them, the move happens on its own. Nothing needs to change in the admin center. That does not mean nothing needs to change at all, though. Their records of processing and internal documents still describe the old location. Update them once the change is live, so your documents match what is really happening.

Users will ask for it more often. Once the main objection is gone, I expect more requests from teams who have heard that Claude is better at certain tasks. Some of these requests will have good reasons behind them. Others will come from something a colleague said over lunch. In both cases, IT needs a way to answer them. That process should be quicker than starting a new project, and more careful than just flipping a switch.

One more point. The EU Data Boundary tells you where data is stored and processed. That matters, and for many European organizations it is a hard requirement. But it only answers that one question. A lot of people have used it as the answer to every question about Anthropic models. It never was.

Architecture implications: the model is now part of your design

What the EU Data Boundary covers, and what it does not

In workshops I use a simple rule. The EU Data Boundary is about geography. It tells you where processing happens. It does not tell you how a model behaves, who does what under which contract, or whether the results are good enough for the job.

This is how I split the questions:

Question	Does the EU Data Boundary answer it?	Where the answer lives
Where are prompts and responses processed?	Yes, once the move is live	Microsoft documentation and your tenant
What role does Anthropic play in processing, and under which terms?	No	Microsoft product terms and data protection documentation, reviewed by your legal team
Does the model produce good results for our tasks?	No	Your own evaluation
Does the model behave the same as the one we tested before?	No	Your own evaluation, repeated over time
Does it stay inside our country?	Not by itself	In-country residency commitments, checked separately

I would spend the most time with legal on the second row. The announcement is about location. I would not draw conclusions about Anthropic’s role in the contract, or about how subprocessors are listed, from a blog post about geography. Your legal team should read the current Microsoft documentation on this and decide if your review of the data processing agreement needs an update.

The last row is important too. The post mentions in-country data residency for Copilot in 10 EU and EFTA countries. The EU Data Boundary and in-country residency are two different promises. If your organization depends on in-country residency, do not read the announcement as a promise that Claude processing stays in your country. Ask your Microsoft account team which promise covers which workload, and ask them to put it in writing.

Two model families in one tenant

Claude already powers experiences in Copilot Chat, the Microsoft 365 apps, Cowork, and Copilot Code. So if you turn Claude on for some users, your tenant will have two groups of people with different model options. This has a few effects that are easy to overlook:

Support. A helpdesk ticket that says “Copilot gave me a strange answer in Excel” now needs one more question: which model was it? If your support team cannot see that, they will lose time.
Training material. Screenshots, prompt guides, and content for your internal champions may look different for the two groups. Think about this before you write one guide for everyone.
Repeatable results. If one team builds a prompt with Claude and shares it with a team that does not have Claude, they will get different results. Nothing is broken. This is simply what happens when you run more than one model.

None of these points mean you should say no. They mean you should plan the rollout instead of just switching it on.

Cowork and agents make the choice more important

In chat, a user reads the answer, decides if it is useful, and moves on. Cowork and agents work differently. They go through several steps, use tools, and work with your content. If you change the model in a task with many steps, the effect is bigger than in a single chat answer, because small differences add up from step to step.

For agent work, I would treat the model like any other dependency in an architecture:

Name it. Write down which model family an agent or Cowork scenario was built and tested with.
Test it. Keep a small set of typical tasks with known good results. Run them again whenever you change the model setting for that group.
Track changes. Write down when the model setting changed for a group. If an agent starts to behave differently, you can then find out why.
Plan the fallback. If the model gets turned off for a group, know what happens to the scenarios that depend on it.

In my experience, this is the part most organizations underestimate. Many still see “the model” as something Microsoft handles inside Copilot. That made sense when there was really only one option. Now that admins can choose the model, it is a design decision, and design decisions belong in your architecture documentation.

You do not need a big evaluation framework to get started. A small set of real tasks from the pilot group, a simple rating scale, and a shared spreadsheet are enough to have a discussion based on facts instead of opinions.

Governance implications: questions DPOs and works councils will ask

I have sat in enough data protection and works council meetings to know which questions come up. Prepare your answers before the first meeting, not during it.

Questions from the data protection officer

Where is the data processed today, and when exactly will that change? Use the Learn page for today’s state and the announcement for the planned state. Be honest that Microsoft says “by the end of 2026” and has not given an exact date. Promise to confirm when the switch has really happened.

Does our record of processing need an update? If Claude is already on, yes. Update it once the change is live, because the processing location changes. If you turn it on later, it is either a new entry or an addition to your existing Copilot entry. That depends on how your records are set up.

Who is involved in processing, and under which terms? The data boundary does not answer this one. Send it to legal and point them to the Microsoft documentation. Do not answer it based on the announcement.

Do we need to look at the data protection impact assessment again? If your current assessment for Copilot assumed one model, or explicitly left out Anthropic models, it probably needs at least an addendum. That is up to your DPO to decide. In my experience, it is better if you bring it up yourself before someone else does.

Can we limit it to specific people? Yes. You can turn the setting on for selected groups. This answer often turns a “no” into a “yes, for a pilot”.

Questions from the works council

In German organizations especially, the works council is often the slowest and the most important stakeholder in a Copilot rollout. They usually ask different questions than the DPO.

Does this change what our existing agreement covers? Many Copilot agreements I have seen describe the tool and what it is used for, not the model behind it. Whether a second model family needs a change to the agreement depends on how yours is written. Read it before you make any assumptions.

Who gets access, and who decides? Group scoping helps a lot here. A pilot with named groups, a fixed time frame, and clear criteria is much easier to agree on than switching it on for the whole tenant.

Will the results be used to compare people? A pilot that compares models must never become a way to compare employees. Build your evaluation around tasks and results, not around who did the work, and put that in writing.

What happens after the pilot? Have an answer ready. The setting is either rolled out further, kept as it is, or turned off. And the decision follows criteria that everyone agreed on at the start.

Bring the DPO and the works council in at the same time, with the same document. If you run two separate tracks, you almost always end up with two different sets of conditions. Then you spend weeks trying to bring them together.

Practical recommendations: how I would run the decision

Why “off by default” is the right setting

Some people will see “disabled by default” as Microsoft being too careful. I think it is the right call. A model change affects results, support, documentation, and in many organizations co-determination with the works council. None of that should change just because a vendor moved processing to a different data center. Off by default forces a clear decision, and a clear decision is exactly what a DPO and a works council will want to see.

It also protects tenants that do nothing. An organization that has never looked at the setting will not suddenly find a second model family turned on for everyone.

Step 1: find out where you stand

Before you start a pilot, answer three questions for your tenant:

Is the Anthropic setting on today, and if so, for whom?
Was that decision documented, including the fact that processing currently happens outside the EU Data Boundary?
Which Copilot experiences do those users actually use: Copilot Chat, the Microsoft 365 apps, Cowork, or Copilot Code?

If the setting is already on, most of your work is documentation. Processing will move on its own. Plan to update your records once Microsoft confirms the change.

If the setting is off, you have some time. Use it to get ready.

Step 2: design a group-based pilot

Being able to turn the setting on for selected groups is the most useful control in this announcement. This is how I would use it:

Phase 0 Preparation
         * Dedicated security group for the pilot, owned by the Copilot service owner
         * Written scope: tasks, duration, success criteria, exit criteria
         * DPO and works council informed with one shared document

Phase 1 Pilot (small, mixed group)
         * Enable Claude for the pilot group only
         * Run the task set, collect ratings and support tickets
         * Review every two weeks with the governance board

Phase 2 Decision
         * Extend to further groups, keep as is, or turn off
         * Update records of processing and internal documentation
         * Publish the decision and the reasons to the organization

Some things I have learned from similar rollouts:

Mix the group. Do not only pick fans. Include people who use Copilot every day for normal work, like finance analysts, HR specialists, and project leads. Their feedback is more useful than feedback from power users, who tend to like everything.
Use tasks, not opinions. Give the group real tasks that you defined, and ask them to rate the results. “I like it” is not a criterion.
Watch support. The number and type of tickets from the pilot group tell you a lot about how much work a wider rollout will be.
Set an end date. Fix it before you start. Pilots without an end date often turn into permanent setups by accident.

Step 3: agree on the criteria before you start

Write down the criteria before the pilot begins. This is the list I would start with:

Criterion	What good looks like
Output quality on the task set	Equal or better than the current setup for the target tasks
Consistency	Similar quality across repeated runs of the same task
Support effort	No noticeable rise in tickets for the pilot group
Documentation	Records of processing and internal guidance updated
Stakeholder sign-off	DPO and works council agree with the scope
Data location	Processing confirmed inside the EU Data Boundary, if that is your requirement

Keep the last row even after the move. It reminds everyone that location was a condition, and that someone checked it instead of just assuming it.

Step 4: treat it as a model choice, not a checkbox

The easiest mistake after the move is to treat the EU Data Boundary as the approval. “It is inside the boundary now, so it is fine” sounds reasonable. But it skips every question from the governance section above.

I would document the decision like any other architecture decision: the context, the options, the decision, the consequences, and a date to review it. One page is enough. A year from now, someone will ask why Claude is on for some groups and not for others. That page will be your answer.

If you turn on Claude before the move is confirmed for your tenant, processing happens outside the EU Data Boundary until then. If your approval depends on the boundary, wait for the confirmation. Or, if you do not want to wait, write down the temporary exception clearly.

Step 5: plan agent and Cowork scenarios separately

If your organization builds agents or uses Cowork for tasks with many steps, do not just add these to the chat pilot. They need their own test tasks and their own owner. A slightly different chat answer is mostly a matter of taste. An agent step that behaves differently can change the result of a whole process.

Conclusion: good news, but you still have to decide

I am glad about this announcement. Many of the European customers I work with want Claude to run inside the EU Data Boundary. Microsoft has said it will deliver this by the end of 2026 across Copilot experiences, including Cowork. For organizations where location was the only blocker, this is real progress.

Still, I would not read it as a decision made for you. Microsoft kept the setting off by default in the EU and EFTA for a reason. The data boundary tells you where processing happens. It does not tell you if the model is right for your users, how it fits your contracts, or whether your works council agreement covers it.

So here is what I recommend. If Claude is already on, update your documentation once the move is confirmed. If it is off, run a pilot with selected groups and clear criteria. Bring in the DPO and the works council together, and write down the result as an architecture decision. From now on, treat model choice as part of your Copilot design, especially for Cowork and agents. It takes more effort than ticking a box. But when someone asks you about it later, you will have a good answer.

Sources

Microsoft Copilot Blog, Bringing Claude models in Microsoft Copilot into the EU Data Boundary, Charles Lamanna, November 5, 2026: timing by the end of 2026, EU and EFTA scope, coverage across Copilot experiences including Cowork, no action for existing Claude users, disabled by default, admin enablement for all users or selected groups, current Claude experiences, in-country residency in 10 EU and EFTA countries
Microsoft Learn, Anthropic models in Copilot apps, last updated November 3, 2026: current state that Anthropic model processing happens outside the EU Data Boundary

One open point as of publication: the Microsoft Learn page still says Anthropic models process data outside the EU Data Boundary, while the announcement says the move will happen by the end of 2026. The two sources describe different points in time. Check the current state for your own tenant before you base an approval on it.

A Third Harness for Customer Conversations: What Changes for Contact Center Agents in Copilot Studio

Holger Imbery — Tue, 03 Nov 2026 00:00:00 +0000

On October 21, 2026, Microsoft added a third runtime to Copilot Studio. This one is built for the customers who call or chat with your company. In this article I explain what the Customer Conversation harness is and how it compares to the Microsoft Copilot and standard harnesses. I also share what I would decide about memory, biometrics, escalation, and cost before a real caller ever talks to it.

Introduction

For most of the past year, lots of Copilot Studio related discussions started with questions around the model. Which one should we use, how fast is it, and what does it cost? That question is still there, but it now comes second. Everything in Copilot Studio runs on a harness. Microsoft’s Learn article describes it as “a runtime that exists between the two”, meaning between your agent design and the model. Since October 21, 2026 there are three of them: the Microsoft Copilot harness, the standard harness, and the new Customer Conversation harness.

My view is that the third harness is a sensible split. A customer on the phone does not need an agent that plans its own way through ten tools. They need a reliable answer, a quick identity check, and an easy way to reach a person. Building that on a runtime made for open-ended reasoning never fit very well. But a separate harness also comes with its own memory model, its own billing, and its own controls. So the first decision is now “which harness”, and in my experience that choice is much harder to undo than a model choice.

There is also a business reason to care. For many companies, the contact center is where cost pressure is felt most. It is also where an agent’s mistakes are seen by customers, not by colleagues. Microsoft puts this harness inside its contact center products, next to what the documentation calls the Microsoft Contact Center Intelligence portal. So this topic matters for customer service leaders and finance, not only for makers.

What Microsoft announced

Omar Aftab’s post on the Copilot Studio blog, “Introducing the customer conversation harness in Microsoft Copilot Studio”, describes a harness that “connects voice, chat, business knowledge, and contact data”. The Learn documentation gives the details. All of it is marked as preview and was updated on October 21, 2026.

An agent on this harness is called a Customer Assist Agent. Microsoft says the harness is best when an agent “needs predictable responses for defined topics while still providing a fluid, natural-language conversation over voice or chat.” It uses a multi-agent design: a primary agent plus specialized sub-agents, each with its own escalation path to a human representative. It can call tools through connectors, knowledge, MCP (Model Context Protocol, the open standard for connecting agents to tools), and connected agents, and it supports skills and memory. Every agent supports Speech and Chat by default. The authoring surface has five tabs: Build, Preview, Evaluate, Deploy, and Monitor.

Two prebuilt tools are specific to contact centers. Escalate passes the conversation to Teams Phone, to Email, or to Customer Engagement. For the live agent route, Microsoft says the agent “sends the entire conversation to the engagement hub”, so the human picks up with full context. Biometric Authentication verifies voice callers. Learn calls it the integration point for the biometric authentication and fraud detection capabilities in the Contact Center Intelligence portal.

Memory on this harness is its own feature, separate from memory on the Microsoft Copilot harness. It stores structured context in a fixed schema. It covers short-term context only, keeps it for 30 days, and is turned on or off with one switch at the agent level. When a shared contact identifier is configured, context from a phone call is available in the customer’s next chat, and the other way around.

Billing is usage-based in Copilot Credits, and building, testing, and evaluating can consume credits too. The Power Platform admin documentation says consumption depends on complexity and modality (digital, GenAI voice, or premium voice). It also states that this usage “isn’t covered by a user’s Microsoft 365 Copilot license.” Voice Biometrics adds 6 credits per enrollment or authentication interaction, and Microsoft’s estimator assumes two such interactions per voice conversation, so 12 extra credits.

All of this is in preview, and the documentation says it “is prerelease documentation and is subject to change.” I would not tie a production contact center roadmap to specific behaviors until Microsoft publishes general availability terms.

Why it matters

For me, voice support is not the main news. The main news is that Microsoft now treats customer service as its own kind of work, with its own runtime. Internal agents can be clever and sometimes wrong, because a colleague will catch the mistake. A customer-facing agent has to be predictable where it counts. It should state the refund policy the same way every time, check identity before it shares an account balance, and hand over to a person without fail.

I would push back on one part of Microsoft’s framing, though. The harness promises both “predictable responses” and “fluid, natural-language conversation”. In my projects those two goals pull in different directions. Most of the real design work is deciding, for each intent, how much is fixed and how much is free. The harness helps, because skills can be deterministic (topics) or generative. But it cannot make that decision for you. If a team reads the promise as “we no longer need to design conversation flows”, the first week of live calls will show them otherwise.

The cost model also changes the business discussion. In a classic contact center, cost follows staff minutes. Here every conversation, short or long, consumes Copilot Credits. The admin documentation adds a detail that I expect many organizations will miss: capacity used by Copilot Studio “reduces the prepaid capacity available to supported Microsoft 365 experiences, such as Cowork and Work IQ.” So a busy voice agent in customer service can use up credits that knowledge workers in other parts of the company rely on. The service director, finance, and IT should talk about this together before launch, not after the first invoice.

One last point is naming. The Copilot Studio articles refer to the Microsoft Contact Center Intelligence portal, while the Power Platform cost article talks about “Microsoft Contact Center AI” and a “Self-Service/Customer Assist Agent”. That is normal for a preview. But it tells me that the lines between Copilot Studio, Dynamics 365 Customer Engagement, and the contact center tools are still moving. Keep that in mind in any licensing discussion.

Architecture implications

Choosing a harness is now the first architecture decision, and it affects much more than how the agent reasons. This is the decision table I use with customers. It is based on Microsoft’s own comparison, and the last row adds my own rule of thumb.

Criterion	Microsoft Copilot harness	Customer Conversation harness	Standard harness
Built for	Complex, multi-step business processes	Customers over voice and chat	Rule-based agents and structured conversations
How it works	Reasons through a goal step by step	Primary agent with sub-agents that escalate	Follows the topics and rules you define
When things go wrong	Retries and finds other paths	Escalates to a human through a defined path	Follows the paths you built
Files	Creates and edits Office and PDF files	Not a focus	Not a focus
Memory	Yes, its own memory model	Structured schema, short-term, 30 days	Not a focus
Publishing	Internal teams or external customers	Website chat or a phone number	Internal teams or external customers
Billing	Copilot Credits, own billing overview	Copilot Credits by complexity and modality	Standard harness licensing
Pick it when	The work is a process, not a dialogue	A customer needs a resolution or a person	The requests are known and stable

The table leads to three practical points.

First , the multi-agent setup fits how contact centers already work. Most service teams route calls by topic, such as billing, orders, or technical issues. One sub-agent per topic, each with its own escalation path, follows the same logic. The documentation makes a useful distinction here. A sub-agent shares configuration, deployment, and ALM with its primary agent. A connected agent, for example one hosted in Azure AI Foundry, keeps its own configuration and ALM. I would choose between them based on who owns what. If one team owns the whole service experience, use sub-agents. If the billing department wants to own and release its own agent, connect it.

Second , voice works differently from chat. Learn states that “Speech channels don’t support end-user sign-in”, so knowledge sources that require the end user’s credentials only work in chat. In practice, any answer that depends on who the caller is must come from a tool that runs after an identity check. It cannot come from knowledge sources that check user permissions. Plan for this from day one.

Third , treat the harness choice as permanent. I have not found anything in Microsoft’s material about moving an agent between harnesses, so I treat a change as a rebuild. One related point I get asked about: the Microsoft Copilot harness is a Copilot Studio framework, not the Microsoft Copilot service, and Microsoft states that customer data is not sent to that service.

Governance implications

Memory and privacy. On paper, 30 days of structured, short-term memory sounds good for privacy, and it is better than free-form recall. The schema is small on purpose. You get built-in fields such as the customer name, past open intents, and a conversation summary, plus up to five custom parameters with a fixed list of allowed values. I see that limit as a good thing, because it forces you to store only what you need. The harder questions are about the customer. Will a customer welcome the agent remembering last week’s complaint, or find it intrusive? How is the customer told that memory exists? How is one customer’s context deleted on request before the 30 days run out? The documentation I read describes the mechanism. It does not describe customer-facing disclosure or deletion requests, so put those questions to Microsoft and to your data protection officer before you switch memory on.

Using memory across channels needs a closer look too. According to Learn, chat channels authenticate the user first, while “Speech relies on the caller’s phone number.” A phone number is an identifier, not proof of identity. Shared family lines exist, and numbers can be spoofed. If memory surfaces anything sensitive, I would only use it over voice after a real authentication step.

Biometrics. Voice biometrics makes sense where fraud risk is real and repeat contact is frequent: payment changes, address changes, high-value accounts. It is hard to justify for opening hours or parcel tracking. The credit cost is documented: 6 credits per interaction, or 12 per voice conversation in Microsoft’s estimate. Whatever you decide, plan an alternative path for customers who decline enrollment.

Escalation and honest containment. Containment rate is the number vendors like to show. I would challenge it as a success measure on its own. A conversation that ends without escalation is not necessarily resolved. The customer may have given up or switched to email. An honest measure counts a contact as contained only when the same customer does not come back on the same issue within a defined window. The memory feature actually helps here, because the list of past open intents is exactly the signal you need. The Monitor tab shows recent and live conversation activity, but I have not seen Microsoft document a resolution metric, so plan to build one.

Cost controls. The admin documentation offers environment allocations, a setting to stop drawing from tenant capacity, and an agent-level monthly limit with Stop usage. It is also clear that Azure budgets and alerts “don’t stop usage”. In a contact center, a hard stop on a customer-facing agent is an outage. If the limit is reached on a Monday morning, callers still need to reach someone.

Never enable Stop usage on a voice agent without a tested fallback route to human agents. Decide in advance what a caller hears when the credit limit is reached.

Practical recommendations

These are the steps I would take to get started with the Customer Conversation harness.

Classify your agent backlog by harness. Use the decision table above for every planned customer-facing agent. Record the choice and the reason in the design document.
Build a credit estimate before the pilot. Classify expected conversations as light, medium, or heavy, split by modality, and add 12 credits per voice conversation if biometrics is on. Review the result together with the Microsoft 365 admin center, since the prepaid pool is shared.
Give the agent its own environment and limits. Allocate credits, turn off drawing from the tenant pool, set a monthly agent limit with a notification threshold, and test what happens at the limit.
Run a data protection review for memory and biometrics. Keep custom parameters to the minimum, decide whether voice memory requires authentication, and document how customers are informed and how deletion works.
Design one escalation path per sub-agent and test it. Build test sets in the Evaluate tab that include explicit requests for a person, implicit frustration, and failed authentication. If you never test an escalation path, you do not know whether it works.
Define containment honestly. Agree on a repeat contact window and report contained, escalated, and abandoned conversations side by side.
Start with one intent in chat, then add voice. Chat supports sign-in and is cheaper to get wrong. Move to voice once identity, escalation, and cost behave as expected.
Keep a preview log. Track documentation changes, product naming, and licensing terms every month, and avoid committing to customer SLAs on preview features.

Conclusion

I think the Customer Conversation harness is the right idea. Customer service has different needs than internal knowledge work, and Microsoft has now given it a runtime of its own, connected to its contact center tools. But I would not assume the harness solves the hard parts for you. You still decide where fixed answers end and free conversation begins. You still decide how to confirm a caller’s identity, what a customer expects the agent to remember, and how you measure success. Make these decisions on purpose, and treat the harness choice as an architecture decision with a budget attached. Run a small pilot while it is in preview, and expect some details to change before general availability.

Sources

Microsoft Copilot Blog, Copilot Studio blog, “Introducing the customer conversation harness in Microsoft Copilot Studio” by Omar Aftab, October 21, 2026: the announcement and its summary of connecting voice, chat, business knowledge, and contact data
Microsoft Learn, Agents powered by the Customer Conversation harness overview (preview), updated October 21, 2026: Customer Assist Agent, multi-agent design, sub-agents and connected agents, tabs, Speech and Chat, sign-in limits on speech channels, usage-based billing
Microsoft Learn, Prebuilt contact center tools (Customer Conversation) (preview), updated October 21, 2026: Escalate to Teams Phone, Email, or Customer Engagement, Biometric Authentication, Microsoft Contact Center Intelligence portal
Microsoft Learn, Memory (Customer Conversation) (preview), updated October 21, 2026: structured schema, custom parameter limits, 30-day retention, agent-level switch, cross-channel continuity, phone number identification on speech
Microsoft Learn, Manage costs for agents powered by the Customer Conversation harness, updated October 21, 2026: modalities, Voice Biometrics credits, estimator assumptions, cost controls, shared prepaid capacity with Microsoft 365 experiences
Microsoft Learn, Harnesses in Copilot Studio, updated October 22, 2026: definition of a harness, the three harnesses and their comparison, Microsoft Copilot harness data handling

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