With this harness, billing can start while the maker is still building. Natural-language authoring, preview, testing, and evaluation can consume Copilot Credits before the agent is published. The cost starts at the workbench, not at the front door.

The meter can move during construction, before anyone reaches the publication gateway.

This matters in tenants where Microsoft 365 Copilot licensing made AI feel like a user-license discussion. The GitHub Copilot harness has its own usage-based billing model. I would not assume that an existing Microsoft 365 Copilot license makes this consumption disappear.

What the harness changes

Microsoft describes a harness as the runtime between the model and what you build. It decides when to call the model, what context and components to send, how to interpret the response, and which tools to call.

The standard harness is built around explicit topics, branches, and predictable paths. The GitHub Copilot harness is a redesigned authoring and runtime experience. A maker describes the agent in natural language, and Copilot Studio generates the underlying configuration. Its Build, Preview, Evaluate, and Monitor tabs put the lifecycle on one surface.

That is not just a different editor. It changes the unit of work and the billing boundary.

A maker can arrive there without a tenant-wide migration project. Microsoft documents that the harness is chosen when a new agent is created, and both harnesses remain available side by side. A maker selecting the new reasoning-heavy experience has made a consequential licensing choice even if the organization never held a formal licensing workshop. Agents cannot later be transferred between the GitHub Copilot and standard harnesses.

For me, that is the first governance lesson: inventory the harness, not only the agent name and owner.

Three things consume credits

The billing overview is unusually direct. Copilot Credits cover three parts of the experience:

1. Large language model tokens. Reasoning and generation consume model tokens.
2. Tools. This includes knowledge sources and MCP servers.
3. The harness. The orchestration runtime itself is part of consumption.

Total consumption combines model work, tool use, and the harness that orchestrates the task.

This is why counting conversations is not enough. Agent design, task complexity, tool calls, and frequency all affect consumption. A maker can trigger that work by asking Copilot Studio to create an automated solution in natural language, previewing the agent, testing it, or generating and running evaluations.

I would treat development and test environments as cost-bearing environments from day one. “Not published” is not a cost control.

Enforcement reaches the maker

The enforcement policy is equally clear. If an environment has no allocated Copilot Credits, or consumes all its allocated credits, experiences that require credits stop working.

End users lose agent responses. Makers also lose natural-language authoring, preview and test, and the ability to generate and create agent evaluations. This is not only a production availability event. It can stop delivery work in the middle of a sprint.

Microsoft says some overage consumption is allowed as a grace period to avoid blocking business processes. I would not turn that sentence into a capacity plan. The public page does not give a guaranteed overage amount or duration. Plan against allocated capacity or an explicit pay-as-you-go route.

Use Manage Agents, not spreadsheets

The current admin path is Power Platform admin center > Licensing > Copilot Studio > Summary > Manage Agents.

That page gives a tenant-wide list of Copilot Studio agents that incur billing charges. For each agent, an administrator can see its environment, month-to-date billed credits, configured limit, and status: Within limit, Nearing limit, or Over limit. Administrators can search, set a monthly limit, and turn an agent off.

A generic representation of the Manage Agents view. All names and values are fictitious.

This view closes an important gap. Environment totals tell me where capacity went. The agent list tells me what is driving it. I review both because an environment can be within capacity while one experimental agent is consuming far more than expected.

Make the overage policy explicit

Set a monthly limit on every billing agent, including development agents. The limit can be generous. An unset limit is not a policy.

The behavior differs by funding model:

• In a prepaid environment, the agent must remain within the capacity pool allocated to that environment.
• In a pay-as-you-go environment, an administrator can set any agent limit, and consumption is billed as used.

Then choose the two guardrails. Notifications alert environment and tenant administrators as usage approaches the limit. A hard stop automatically turns off the agent when it reaches the limit.

There is also an environment-level overage decision. When preallocated capacity is exceeded, the environment can draw from available tenant capacity or bill overage to a linked pay-as-you-go plan. Write down which behavior is approved. Otherwise, one team expects continuity while another expects cost containment, and the platform cannot satisfy both assumptions.

I normally enable notifications first, observe a full billing cycle, and then decide where a hard stop is acceptable. A test agent and a business-critical production agent should not inherit the same response blindly.

Automate the control loop

The portal is useful, but a CoE should not depend on someone opening it every morning. The Power Platform API groups these operations under the Licensing namespace.

Three operations are useful building blocks:

• Get Tenant Capacity Details returns tenant capacity and consumption details.
• List Currency Reports returns tenant currency reports and can include allocations and consumption.
• Currency Allocation gets, allocates, and deallocates currency capacity for an environment.

The same capabilities are exposed in Power Automate through the Power Platform for Admins V2 connector. Its documented action Allocate and deallocate the currencies for the environment accepts an environment ID, currency type, and allocation count. The connector also exposes the tenant capacity and currency report operations.

A scheduled governance flow can read capacity, notify administrators, and reallocate under an approved rule.

That supports a simple control loop: read consumption on a schedule, compare it with policy, notify before enforcement, and reallocate only when an approved rule allows it. Keep an audit trail. Use a service principal where the connector action supports it. The connector documentation notes that service-principal authentication is supported for most actions, not all, so validate the exact connection you deploy.

I would not claim that these APIs replace every setting on Manage Agents. They automate the capacity data and allocation path documented today. Keep per-agent limit configuration in your runbook unless you have validated the corresponding resource-threshold operations for your tenant.

Three checks to do now

1. Inventory what bills. Open Manage Agents and record every billing agent, its harness, owner, environment, and month-to-date credits. Include work in progress.
2. Set limits, even generous ones. Separate prepaid pool policy from pay-as-you-go policy, and decide explicitly what happens in overage.
3. Notify before you block. Route nearing-limit alerts to tenant and environment administrators, then apply hard stops according to business criticality.

The important change is simple: publication is no longer the beginning of the cost conversation. For GitHub Copilot harness agents, governance must begin when building begins.

Microsoft Learn sources

• Manage Copilot Studio credits and capacity
• Overview of usage-based billing
• Enforcement policy for Copilot Credits
• Microsoft Power Platform API reference
• Choose a harness
• GitHub Copilot harness overview
• Power Platform for Admins V2 connector

Two layers, two different jobs. Neither of them is a lock.

Every tenant reaches this moment. The default environment grew on its own, nobody planned it, and now there are hundreds of apps and flows inside it — some abandoned, some quietly business-critical. You want to stop the growth without stopping the organization, and the two tools everyone points you at are environment routing and data loss prevention policies.

They are the right two tools. But both of them are routinely credited with powers they do not have, and that gap is where a false sense of control comes from. This article is the concrete mechanics of each layer, and — more importantly — the honest boundary of each one. If you have not settled the bigger picture yet, start with your environment strategy matters more than any toolkit you install; this one is what you do once that decision is made.

Layer one: environment routing

Environment routing changes where a maker lands when they open a maker portal. Instead of dropping into the shared default environment, they get their own personal developer environment, created automatically on first sign-in and named after them.

Here is the configuration, step by step:

1. In the Power Platform admin center, go to Manage > Tenant settings > Environment routing. The panel is called Create and manage environment routing rules.
2. Turn routing on for the maker portals you actually use. Routing currently covers Microsoft Copilot Studio, Power Apps, and Power Automate cloud and desktop flows. It does not cover Power Pages, so a Power Pages maker still lands wherever they landed before.
3. Create a routing rule. You can target Everyone, or a specific security group. For a first rollout, target a security group — a dozen willing makers will tell you more in a week than a tenant-wide switch will tell you in a month.
4. Select an environment group for the developer environments the rule creates. This is the step people skip, and it is the one that matters: the new environment arrives already configured as a managed environment with every published rule of that group applied from the start — and those rules now include a connector policy, which we get to below.
5. Save and check rule order. When a maker opens a portal, the rules are evaluated in order and the first matching rule wins, so a broad “Everyone” rule sitting above a narrower one will swallow it.

The environment group is what turns a new personal environment into a governed one on day one.

The developer environment type is fixed and cannot be changed later, and these environments do not consume your Dataverse capacity — which is usually the objection that comes up first in the room.

What routing does not do

This is the part worth being precise about, because the assumption is so common. Routing decides where a maker starts. It does not decide where a maker can go.

Microsoft Learn answers it directly in the routing FAQ. Asked whether new makers can switch to the default environment or other environments after their own developer environment is created, the documentation says: “Yes, makers can always switch to other environments.”

So routing reduces new development in the default environment, and it does that well. What it does not do is prevent it. A maker who knows the environment picker exists — and they all learn — can go straight back to the default environment and build there tomorrow. If creation in the default environment genuinely has to be controlled, routing is one input, not the answer: you pair it with the governance controls on that environment and you move the critical solutions out to environments that were designed for them.

Layer two: a DLP baseline

The second layer is a data policy, and the most durable shape for it is a restrictive tenant-level baseline with deliberate exceptions, rather than a pile of per-environment policies that nobody can reason about.

• Scope one tenant-level policy to everything, using Exclude certain environments to carve out only the production or project environments that are explicitly governed on their own terms.
• Put approved Microsoft 365 and line-of-business connectors in the Business group. Connectors in a group cannot share data with connectors in another group, which is the whole mechanism.
• Put personal and unapproved connectors in Non-business, or in Blocked if they have no place in your tenant at all.
• In the default environment, set the default group for new connectors to Blocked. The setting is called Set default group, on the Pre-built connectors step of the policy. New connectors then arrive blocked and have to be reviewed rather than silently becoming available. Worth knowing: connectors that cannot be blocked land in Non-business regardless, because by design they cannot be blocked.
• Add environment-specific policies only for justified exceptions. When several policies apply to the same environment, Learn is explicit: “the most restrictive policy applies to the combination of connectors.” And an environment-level policy can never loosen a tenant-wide one — “Environment data policies can’t override tenant-wide data policies.”
• Validate against a representative sample of existing apps and flows before you enforce. This is not optional politeness. When a policy starts applying, an app that violates it goes into a suspended state and its connections are disabled — enforcement usually lands within an hour, and can take up to 24. A policy you did not test is an outage you scheduled without knowing it.

The newer option: advanced connector policies

Before you invest heavily in the classic model, know that there is a second generation of this layer. Advanced connector policies, currently in preview, drop the Business / Non-business / Blocked classification entirely in favour of “a strict allowlist that blocks all connectors by default.”

Three things matter when you decide how much to lean on them:

• Where they live. For one environment: Security > Data and privacy > Advanced connector policies. For a whole group: Manage > Environment groups > the group > Rules > Advanced connector policies. That second path is the one that pairs with layer one — a routed developer environment inherits the group’s rules, connector policy included, from the moment it is created.
• They coexist with what you already have. By default they run in mixed mode alongside classic data policies, with “a combined policy that merges the most restrictive settings from both.” There is also an ACP-only mode where classic policies are ignored — not deleted, just no longer evaluated for that scope.
• Coverage is not complete yet. They support certified connectors only: “Custom connectors and HTTP connectors aren’t yet supported”, and virtual connectors are not on the roadmap at all. For those, classic data policies are still the tool. The upside is on the other end — on a managed environment, single or through a group, you can block any connector or any action, including the ones that are non-blockable in a classic policy.

That last point is the practical argument for combining the two layers rather than picking one. Routed developer environments are managed environments, so a connector policy applied through the group is enforced there without the non-blockable escape hatch.

What connector policies do not do

A connector policy — classic or advanced — governs which connectors can be used and combined. That is the entire scope. It does not stop anyone from creating an app.

It is also narrower than people assume even within its own lane. From the Learn overview: “Data policies are connector aware, but they don’t control connections made using the connector. In other words, data policies can’t determine whether the connector is used to connect to a development, test, or production environment.”

So this layer is a data control, not a creation control, and the advanced version does not change that. Someone can still build in the default environment all day; they just cannot reach the connectors you did not allow while doing it. That is genuinely valuable — and it is not the same thing as closing the environment.

Two real controls with two real gaps. The gaps do not overlap, which is exactly why you need both.

And the hundreds of things already in there

Neither layer touches what already exists. That is a separate job, and the failure mode is trying to do it in one weekend.

Start by inventorying, not moving. For each app and flow in the default environment you want to know the owner, the connectors it uses, its dependencies, how widely it is shared, and whether the business would notice if it stopped. The admin center Actions page surfaces unused and ownerless resources, and the CoE Starter Kit gives you the connector and usage reporting to go with it.

Then sort by what the asset actually is. Microsoft Learn suggests a decision along these lines: a small app with a handful of users and no confidential data can reasonably stay; something used by a wider group or touching confidential data belongs in a shared environment; a widely used or highly sensitive app belongs in a dedicated one. Anything that needs proper application lifecycle management has to leave regardless, because the default environment was never meant to carry it.

The pilot wave exists to find the surprises while they are still cheap.

Then pilot with a representative subset — not the easiest apps, a representative one, including at least one that will be awkward. The move itself is a solution export and import, plus security roles, plus configuration and data, plus testing, plus telling the users. Only after that do you move the rest, in waves. One caution from the documentation that catches people out: restoring the default environment later can bring back the orphaned apps and flows you cleaned up, so treat cleanup as a step you do not want to undo.

Two layers, one baseline

Routing shapes where new work begins. Connector policies shape what data new work can touch. Together they give you a governed starting point for everything created from now on, which is a genuinely different tenant than the one you had.

Neither of them closes the default environment. It stays open, every user in the tenant is still a maker in it, and the only thing that actually reduces your exposure there is moving the important things out. Assuming otherwise is the most expensive mistake in this whole area — because it feels like the work is done, right up until the day you find out it is not.

Learn more

• Default environment routing
• Advanced connector policies
• Environment group rules
• Secure the default environment
• Data loss prevention strategy
• Data policies overview
• Manage the default environment

There is a right order to climb. Most teams skip straight to the expensive steps.

It is one of the most common reactions when the throttling banners start appearing: create another account, move some flows to it, buy yourself some headroom. It feels like load balancing. It is not. The limits you are hitting are mostly not tracked where you think they are, and the ones that hurt most don’t care who owns the flow at all.

First, understand what you are actually looking at

Before you spend anything, be clear about which numbers you are reading.

Every organization is currently in a transition period. Enforcement is less strict and the limits actually applied are more generous than the official ones. During the transition, those limits are applied at the cloud flow level rather than the user level: a Power Automate Premium user has an official limit of 40,000 requests per day, but 200,000 per cloud flow during the transition. A Process license is 250,000 officially and 500,000 during the transition. There is also a separate transition cap of 1,000,000 cloud flow actions per user per day.

The clock only starts when reporting reaches general availability, and nobody has published that date yet.

Two consequences matter:

• Build against the official limits, not the transition ones. The transition ends after the Power Platform admin center reports become generally available, and organizations then get six months to analyze usage and buy appropriate licenses before strict enforcement begins.
• The reports do not yet show everything. Power Platform request reporting is still in preview and currently covers Power Automate API requests only. Requests from Dataverse, Power Apps, and Microsoft Copilot Studio are not included. Whatever number you are looking at, your real platform consumption is higher.

There are known reporting quirks too. In the licensed user report, entitlements appear per user per day per environment even though the limit applies per user per day, and users licensed through Power Apps per app show an entitlement of 0 when it should be 6,000. Read the consumption column with confidence; read the entitlement column with care.

The ladder, in the right order

Treat this as an escalation plan. Only move to the next step if the previous one genuinely isn’t enough.

1. Optimize the flows. This is the cheapest step and usually the one with the largest return, because request consumption is driven by design, not by volume alone. Every trigger and every action counts as one request, and that includes built-in ones like Compose or Initialize Variable. Actions inside a loop run once per iteration, so a loop with 2 actions and 10 iterations costs 21 requests, not 3. Both succeeded and failed actions count. Retries and the extra calls generated by pagination count as well. Skipped actions don’t.

So the levers are concrete:

• Reduce trigger frequency, especially on polling triggers. Many flows running every minute or every hour can run far less often.
• Add trigger conditions so the flow doesn’t start at all for events you will discard in the first branch.
• Use Filter query and Top count on connector actions to retrieve fewer items instead of looping through everything.
• Cut unnecessary retries and pagination. Both are silent multipliers on your daily count.
• Store a reused property with Initialize Variable instead of referencing a large action output repeatedly, because referencing one property passes the entire output of that action into the next one.

2. Process license. If the flow is already lean and still heavy by nature, this is the highest action entitlement available: 250,000 requests per day, applied to the flow rather than to a user. It is also stackable — up to 10 Process licenses on a single cloud flow, each adding another 250,000 requests per day. The flow must be in a solution before a Process license can be assigned. This is the step people most often get wrong, so it is worth stating plainly: if one flow exceeds its entitlement, stack more licenses on that same flow rather than splitting the workload across flows or owners.

3. Pay-as-you-go. Link the environment to an Azure subscription and users and flows in that environment stop being throttled above their daily allocation — you pay only for the actions consumed above the limit, billed to the subscription. Flows still need a base license underneath. This is the right answer when consumption is genuinely spiky or hard to forecast, because you stop managing ceilings altogether.

4. Capacity add-on. Each Power Platform request capacity add-on raises a limit by another 50,000 requests per 24 hours, and multiple add-ons can be assigned. Check the current conditions in the documentation before you plan around it: during the transition period these add-ons cannot be assigned to users or flows, and Microsoft’s guidance is to buy them to stay within license terms and be ready for when the transition ends, raising a support ticket if you need relief for a flow being throttled today.

Why more service accounts is not the answer

This is the part that contradicts the instinct, so here are the concrete reasons.

The capacity you would be splitting is already shared. When a flow’s owner is a service principal, the flow consumes the non-licensed user limits, and those are pooled at the tenant level. The documentation is explicit that application users, non-interactive users, administrative users, and the SYSTEM user do not each get their own limit — they share the tenant pool. For Power Automate that pool is 25,000 base requests per day with no per-license accrual. Creating a second, third, or tenth identity divides the same pool into more slices. It does not create a new one.

More identities change who is drawing from the bucket, never how much is in it.

Licensed limits aren’t poolable either, in the other direction. Capacity is tracked per individual user and per licensed flow, and it explicitly cannot be pooled at environment or tenant level. Eight users with 6,000 requests each are eight separate 6,000 allowances, never one shared 48,000. Moving ownership around just moves which allowance gets consumed.

It does nothing to the limits that aren’t license based. There is an independent limit of 100,000 requests per five minutes, applied at the flow level and independent of the license — a flow with a Process license may have 250,000 requests for the day but still cannot spend more than 100,000 of them in any five-minute window. Connector limits behave the same way: a single SharePoint connection is capped at 600 operations per minute no matter how many flows use it, and service protection limits apply per service regardless of who owns anything.

It fragments reporting and ownership. The admin center reports already list callers individually, with caller types of System and Non-Interactive/Application. Splitting a solution across several identities scatters its consumption across several rows and several owners, which makes attribution harder, complicates ALM, and leaves you with accounts nobody wants to be responsible for.

Some of it isn’t even supported. Non-interactive users are capped at seven per tenant and are not supported by Power Automate, so that is not a lever. And sharing one service account’s credentials across a group of users so they can run premium flows under a single license is multiplexing, which is a license violation — not a capacity strategy. Microsoft’s guidance is that service accounts are not a best practice at all, and that running flows under a service principal as owner is preferable.

None of this means one service identity is the correct number. Multiple service identities are perfectly reasonable when there is a real architectural reason: separating distinct business capabilities, or enforcing a security boundary between workloads with different data access. That is design. Creating identities to inflate a daily ceiling is accounting, and the platform does not honor it.

How to find the real consumers

You can only optimize what you can attribute. In the Power Platform admin center, go to Licensing > Capacity add-ons, then on the Summary tab scroll to the Add-ons section and select Download reports. Choose Microsoft Power Platform requests and pick the scope you need.

Only two of the three reports tell you which flow spent the requests.

Each scope answers a different question, and each has a blind spot:

• Licensed user — consumption per user per day against their entitled quantity. Note what is missing: there is no flow or resource ID, so you can see that a user burned their allowance but not which of their flows did it. Caller ID can also be null or empty.
• Non-licensed user — consumption for System and Non-Interactive/Application callers, plus the tenant’s total non-licensed entitlement. This one does include a resource ID, which for Power Automate is the flow ID, although it can also come back empty.
• Per flow licensed flows — consumption and entitlement for flows carrying a Process or per-flow license, with the caller ID being the flow itself. Environment region is not available during preview.

Because identifiers can be empty and the licensed user report has no flow ID at all, mapping consumption back to a solution usually means cross-referencing these exports with your own flow inventory — flow IDs, owners, and the solution each flow belongs to. If you don’t have that inventory, build it before you buy anything.

On the maker side, open a flow’s details page and select Analytics, then the Actions tab, to see how many actions it actually runs. And treat the warnings seriously: a flow that stays above transition period limits for 14 consecutive days is suspended, with a notification to the owner.

Capacity is an architecture problem

Passing your request limits is useful information. It tells you that a flow triggers more often than the business needs, that a loop is iterating over rows you could have filtered out server side, or that a genuinely high-volume process has outgrown a user license and needs to be licensed as a process.

What it never tells you is that you need more accounts. Redistributing work across identities changes the labels on the consumption, not the consumption itself — and it leaves you with a more fragmented estate, harder attribution, and the same throttling a month later. Optimize first, license the flow that actually does the work, and let the ceiling be a design signal rather than something to route around.

Learn more

• Requests limits and allocations
• Power Automate licensing FAQ — action limits and capacity
• Types of Power Automate licenses — capacity licenses
• Power Automate limits and configuration

Two halves, one solution. Most organizations only ever switch on the left one.

A while ago I wrote about how the kit fills the governance gap your admin center can’t. That article was about the admin half — inventory, compliance, conversation quality, the things a Center of Excellence needs to sleep at night. This one is about the other half, the one almost nobody switches on: the components built for the people actually creating agents.

One naming note before anything else, because it will save you a search. The kit has been renamed from Copilot Studio Kit to Copilot Agent Kit. Microsoft Learn now describes it as a toolkit maintained by the Power Customer Advisory Team, and the case study spells the change out as “Copilot Agent Kit (formerly known as Copilot Studio Kit)”. The rebrand comes with an expanded scope, reaching into Microsoft 365 Copilot, Microsoft Agent 365, and Microsoft Foundry.

In practice, both names are live at the same time, and you need to search for both. The GitHub repository is still Power-CAT-Copilot-Studio-Kit, the managed solution file is still CopilotStudioKit_managed.zip, the app you open in Power Apps is still called Power CAT Copilot Studio Kit, and parts of the Learn table of contents still carry the old name. Nothing is broken — the documentation is just mid-migration.

What your makers actually get

The productivity side of the kit is not a token gesture. It is seven components, and each one solves a problem you have probably already tried to solve with a wiki page.

Every one of these exists because a maker was otherwise going to improvise it.

• Agent Library — reusable building blocks and templates, so a new agent starts from something sanctioned instead of an empty canvas.
• Prompt Advisor — makers submit a prompt and get back a confidence score, a detailed analysis, and suggested optimized prompts. This is your answer to uneven quality when several teams build in parallel.
• Adaptive Cards Gallery — pre-approved card templates, which keeps makers inside the visual and behavioral standard you already signed off on.
• Webchat Playground — customize the appearance and behavior of the agent web chat, including colors, fonts, and thumbnails, without hand-editing the embed code.
• Test automation — run agents against test sets at scale instead of one manual conversation at a time.
• Rubric Refinement — improve the rubrics those tests score against, so your evaluation gets sharper rather than just louder.
• SharePoint synchronization — keep SharePoint content flowing into agent knowledge automatically.

Two of these consume AI credits, so budget for it: a Generative Answers test costs roughly 50 credits, and Prompt Advisor costs roughly 120 credits per iteration. That is not a reason to skip them, but it is a reason to know before a maker discovers it for you.

The real objection: “I am not opening the inventory to makers”

This is the objection I hear every single time, and it is a reasonable one. A tenant-wide list of every agent, every owner, and every compliance flag is not something you hand out because someone wants nicer cards.

You do not have to. The maker components work completely independently of Agent Inventory.

The kit ships two security roles, and the separation between them is deliberate and sharp:

The maker role is not a watered-down admin role. It is a different job description.

• CAK - Administrator has organization-level access to most tables — the full administrative view across the environment.
• CAK - Maker is described as limited access for users who create and test agents, typically working with their own records while holding read access to shared configuration data.

Concretely, the maker role has no access at all to Agent Inventory, Conversation KPI, Agent Compliance, Conversation Analyzer, or Agent Value Summary. At the same time it gets full create, read, update, and delete on the tables behind the Webchat Playground and the Adaptive Cards Gallery, plus the test automation capability. Records like agent configurations, agent reviews, and test results are scoped to the owner, so a maker sees their own work and not their colleague’s.

There is one detail worth correcting, because it is widely assumed and it is wrong. The Agent Library is not scoped to “agents I created or that were shared with me.” Its visibility is based on publish status: an administrator sees all custom templates including drafts, while a maker sees published templates only, read-only. Creating, editing, and deleting custom templates stays with the admin role. That is arguably better for your purposes — makers consume a curated catalog and cannot quietly publish their own — but it is a different mechanism than row-level sharing, and it changes how you plan your rollout.

Two more things to check before you assign anything:

• The role names are inconsistent across sources. The GitHub documentation uses CAK - Administrator and CAK - Maker, while the Learn page on configuring users and teams still uses CSK - Administrator and CSK - Maker. Same roles, mid-rename. Search for both.
• There are deprecated roles still sitting in the solution — an old Administrator, Configurator, and Tester/KPI Viewer, all suffixed with Deprecated. If anyone in your tenant still holds one, migrate them rather than layering a new role on top.

Assign through Entra ID security group teams rather than per user. It is the documented recommendation, and it means the maker population is managed where the rest of your access already lives. If you have secured columns in play, such as the Direct Line channel secret, the kit also ships a column security profile for exactly that.

The practical conclusion: give makers the library, the prompt advisor, and the cards. Keep the inventory with the admin group. Widen later if it earns it.

Three organizations already doing this

The published case studies are useful precisely because they land in different places on the admin-to-maker spectrum.

Nationwide sits closest to governance. As their use of Copilot Studio expanded, Agent Inventory in the kit is what let them maintain visibility and control while the number of agents grew. This is the classic reason people install the kit in the first place.

Business France is the opposite end, and the most interesting one for this argument. Their documented win is the Webchat Playground, which took them from concept to production while reducing the effort needed to embed the agent. That is a purely maker-facing component delivering a purely maker-facing outcome.

The City of Montréal shows the two halves feeding each other. They serve 1.7 million residents, with a website agent sitting on top of more than 40,000 pages of content. They use Conversation KPIs to identify where conversations go off track or fall back to generative answers, and to detect missing or poorly structured content. That is analytics from the admin half directly changing how makers design topics and where they invest their next hour.

Where to start

Do not stage a big bang. The kit is large, and trying to switch everything on at once is how it ends up half-configured and abandoned.

Each step should survive a month of real use before you take the next one.

Get the prerequisites straight first: a Dataverse environment, system administrator rights, and the Creator Kit deployed before the Agent Kit. You also need Power Apps component framework enabled for canvas apps and Code Apps enabled, licensing that covers model-driven apps and premium-connector flows, and a DLP policy that permits the connectors the solution ships with.

Then install from the marketplace or from the GitHub release, and let the Setup Wizard handle the connection references, environment variables, and flows. If you enable flows by hand instead, the documented order matters: grandchild flows first, then child, then the rest.

For the first real step, resist the urge to configure everything. Pick one maker component — the Adaptive Cards Gallery is the lowest-risk choice, because the blast radius of a bad card is a bad card. Create one Entra security group team, assign it the maker role only, and leave every inventory and analytics sync switched off. Publish two or three templates so there is something sanctioned to start from, and see what your makers do with it.

If you want help along the way, Power CAT runs public office hours every other week, in a US and an APAC slot, and the sessions are recorded.

Governance and productivity are the same kit

The reason this half goes unused is a framing problem. The kit arrives through a governance conversation, gets installed by an admin team, and inherits that team’s mental model — a monitoring tool, something you look at rather than something you build with.

But the components your makers need were shipped in the same solution, they run on the same Dataverse environment you already provisioned, and they are gated by a role that deliberately cannot see your inventory. You already paid the setup cost. The only thing standing between your makers and the other half of the kit is a security role assignment.

Learn more

• Copilot Agent Kit overview
• Configure users and teams
• Copilot Agent Kit real-world examples
• Power CAT Copilot Studio Kit on GitHub

The right architecture separates interpretation from execution.

This is not an argument against agents. It is an argument for using them where they add something a rules-based automation cannot: interpreting ambiguity, understanding natural language, and choosing a path that isn’t known in advance.

The question nobody asks

Before you choose the newest tool, ask a simpler question:

Is this process deterministic?

If you provide the same input and expect the same output through the same defined rules, the process is deterministic. Checking whether an invoice has all required fields, copying an approved record from system A to system B, transforming a payload, or sending a reminder every Monday does not require reasoning. It requires reliable execution.

A cloud flow gives you explicit conditions, actions, retries, run history, and predictable paths. You can inspect exactly what happened and test each branch.

An agent becomes valuable when the input or path is uncertain. A user might describe a request in their own words, omit required information, combine several intentions, or need help deciding what to do next. Copilot Studio’s generative orchestration can select tools, topics, knowledge, and other agents at runtime, ask for missing information, and use conversation context to continue the task.

That flexibility is the point. If you do not need it, do not pay for it or make your architecture harder to test.

What the cost really reflects

The cost models are structurally different.

With Copilot Studio, consumption is measured in Copilot Credits. Microsoft documents that consumption reflects the work the agent performs to retrieve information, generate responses, and use actions or custom skills. The complexity of the task matters: planning, grounding, orchestration, and tool use are part of the work being consumed.

With Power Automate, capacity and service limits are tied to the flow’s license and the actions and Power Platform requests it executes. Connector actions, built-in actions, failed actions, retries, and pagination can all count. The path is explicit, so you can inspect it and estimate the work before the flow runs.

This does not mean every flow is cheap or every agent is expensive. Connectors, licensing model, volume, retries, AI Builder, and the surrounding services all matter. It means a fixed process usually has a more predictable consumption profile when you implement it as a flow instead of asking an agent to reason through the same route every time.

Do not design from a price remembered from a slide. Check the current Copilot Studio licensing guidance, Power Platform licensing guidance, and the license assigned to your environment and flow.

A practical decision grid

A useful shortcut is: agents handle uncertainty; flows handle certainty.

The hybrid pattern

Put the agent at the front for intent and flows behind it for execution.

Interpretation happens once, at the front. Execution stays deterministic behind it.

Imagine a user writes:

Create a supplier request for Contoso, starting next month, with a 25,000 EUR annual value. Finance should review it first.

The agent can:

1. Interpret the request and identify that the user wants to create a supplier record.
2. Extract structured fields such as supplier name, start date, annual value, and review route.
3. Ask a follow-up question if a required field is missing or ambiguous.
4. Call a cloud flow with the completed, structured input.

The flow can then:

1. Validate the fields against fixed business rules.
2. Check whether the supplier already exists.
3. Create the Dataverse record.
4. Start the defined approval path.
5. Return a structured status to the agent.

The agent does the part that benefits from language and judgment. The flow does the part that must be repeatable, auditable, and testable. You keep the agent’s job small, the flow’s contract clear, and the overall cost easier to forecast.

Signs you chose the wrong tool

Reconsider the architecture when:

• The agent always does exactly the same thing. There is no meaningful choice for it to make.
• Your instructions are full of rigid rules. You are rebuilding conditions and switch branches in prose.
• Every test must produce an identical route and result. That is a strong signal that you want deterministic execution.
• Consumption per interaction surprises you. The agent may be doing orchestration work that the process does not need.
• You cannot test the business logic without a conversation. Move that logic behind a typed flow contract.

The opposite mistake also exists. If your flow has dozens of brittle branches trying to recognize every way a person might express the same request, you are forcing deterministic automation to solve an interpretation problem. Let an agent normalize the request first.

The tool is not the architecture

The right tool is not the newest one. It is the one that solves the problem with the right cost, control, and degree of flexibility.

Use an agent when the work genuinely requires interpretation. Use a flow when the rules and path are already known. Use both when a human request is ambiguous but the business operation behind it must be exact.

Knowing when not to use an agent is part of knowing how to build good agents.

Learn more

• Copilot Studio licensing
• Power Platform licensing FAQs
• Limits of automated, scheduled, and instant flows
• Orchestrate agent behavior with generative AI

This is one of the most important shifts in Power Automate since it stopped being called Microsoft Flow. Instead of an agent needing a hand-built connector for every automation, your flow becomes a standards-based tool that Copilot Studio, Azure AI, and any Model Context Protocol client can invoke directly.

What MCP actually gives you

The Model Context Protocol (MCP) is an open standard for how AI models talk to external tools and data. Think of it as a universal contract: an MCP server exposes a list of typed tools — each with a name, a description, and a JSON Schema for its inputs and outputs — and any MCP-compatible client can call those tools without bespoke integration work.

When you publish a Power Automate flow as an MCP server, the platform does the hard part for you:

• The flow’s inputs become the tool’s input schema.
• The flow’s response becomes the tool’s output schema.
• The name and description you write tell the agent when to use it.

You supply the plain-language description and the parameter names. Power Automate handles the schema serialization and hosts the MCP endpoint.

Why this matters more than another connector

Your automation logic becomes reusable by any agent

An approval flow, a “create a ticket” flow, a “look up an order” flow — each becomes a named capability in an agent’s toolbox. The same MCP server can be consumed by a Copilot Studio agent today and an Azure AI agent tomorrow, because they all speak the same protocol.

No custom integration code

Before MCP, wiring an agent to your automation meant custom connectors, HTTP actions, and glue code. Now the agent reads the tool manifest, sees the typed inputs, and calls the flow with structured arguments — getting structured results back.

The agent decides when to act

Because the tool has a clear name and description, the orchestrator can pick it at runtime based on the user’s intent. “Submit this purchase order for approval” maps to your approval flow; “check the status of order 4192” maps to your lookup flow — no hardcoded routing required.

A practical pattern

Say you already have a classic approval flow. To make it agent-callable:

1. Define clean inputs — for example poNumber, amount, vendor, requestorUPN. Clear names become clear tool parameters.
2. Return a structured response — such as decision, approver, and comments — so the agent gets something it can reason over.
3. Write a precise description — “Submit a purchase order for manager approval and return the decision.” This is what the orchestrator matches against.
4. Publish as an MCP server and copy the endpoint URL.
5. Register the endpoint in Copilot Studio (or your Azure AI agent) as an MCP tool.

Now the agent can run real automation — send the approval, wait for the decision, update the record — all through your existing, governed Power Automate logic.

What to watch for

• Descriptions are the routing logic. A tool called “Flow 1” with the description “does stuff” will get misrouted constantly. Treat the name and description as prompt engineering — they are how the agent decides to call your flow.
• Governance still applies. Flows published through MCP run on real connections inside your environment. Data loss prevention (DLP) policies, connection restrictions, and environment boundaries all still apply — plan for them before you publish.
• Keep a human in the loop for high-impact actions. If a flow does something irreversible — sending money, deleting records, emailing customers — build an approval gate into the flow. An agent should never be able to autonomously approve its own request; the approver must be a different identity from the requestor.
• Mind authentication. Make sure the agent invokes the flow under a governed identity with least privilege, not a broad or shared account.

The MCP server support is the moment your Power Automate library stops being a collection of isolated automations and becomes a shared toolbox that every AI agent in your organization can draw on. Start by exposing one well-understood flow, prove the round-trip, then expand — and let your existing automation investment do double duty as agent capabilities.

The new editor: rich-formatted instructions on the left, everything else stacked on the right

For a while now, building an agent in Copilot Studio meant bouncing between tabs — one for Tools, another for Knowledge, another for the rest. The new editor collapses all of that into a single page. And the best part: it doesn’t replace the classic experience, it sits right next to it.

Flip one toggle to try it

The new editor is gated behind a New experience toggle in the top-right of Copilot Studio. Turn it on and you land in the redesigned builder; turn it off and you’re back in the classic agent editor you already know. The two modes coexist, so you can experiment without committing your whole team to it.

The New experience toggle lives in the top-right — flip it on or off any time

Everything on one page

The biggest change is layout. Instead of separate tabs, the new editor keeps your instructions front and center, with a single right-hand pane that stacks everything else:

• Model — pick the model that powers the agent (Claude Sonnet 4.6 was front and center in the preview).
• Microsoft IQ — the grounding layer that brings in your organizational context.
• Skills — attach SKILL.md files as reusable playbooks.
• Tools — add and configure actions inline.
• Knowledge — point the agent at your sources.
• Connected agents — call other agents.

You stop hunting through tabs and start seeing your whole agent at a glance.

Instructions you can actually format

The instructions field now supports rich formatting — bold, numbered lists, code blocks, and links. This isn’t just cosmetic. Well-structured instructions are easier for you to maintain, and they help the model parse the rules and guidelines more reliably. Bold the hard constraints, number the steps it should follow in order, and drop a code block in when you need an exact format. Both the human and the AI benefit.

Skills: a new primitive that runs Python

The headline addition is Skills — a new primitive that replaces the old topics-and-child-agents model with something far more composable. You attach SKILL.md files straight into the agent, including skills you authored elsewhere — in Codex, Claude Code, or another AI tool — and you can add more than one. There’s also a search so you can find skills to wire in.

The kicker: Skills can execute real Python, right inside your agent. Each agent runs in its own container, so file generation and analysis just work — produce a report, run a data transformation, hand the user back a polished artifact — without bolting on a flow to do it. It’s a clean way to give your agent focused, reusable playbooks instead of cramming everything into the instructions block.

It’s a rebuilt runtime, not a reskin

This is the part that’s easy to miss: the new editor isn’t a coat of paint over the old engine. The orchestration and authoring layers were rebuilt on a proper agentic harness — a loop that calls the model, dispatches tool calls (including MCP servers), feeds the results back, and keeps going until the task is done. If you used Enhanced Task Completion in the classic UI, this is the same backend, now with a home that matches its capabilities.

Knowledge, memory, and guardrails are first-class in this runtime — native to how it executes, not workarounds layered on top. Combined with Python Skills and containerized execution, it’s a meaningfully different product than what existed six months ago.

Configure tools inline

Tools are now set up on the same page, not in a separate detour. When you add a tool, you see all of its inputs laid out — including which ones are required — and configure inputs and outputs right there. Fewer clicks, less context switching.

Preview exactly what the end user sees

The new editor adds an End user preview toggle that mirrors precisely what the person chatting with your agent will experience. It’s a small thing that saves a lot of “wait, why does it look different for them?” moments before you publish. The agent list, meanwhile, now shows Status (Draft / Published) and Channel columns so you can see at a glance where each agent stands. Evaluate and Monitor work the same as before.

A balanced take

It’s a genuinely nicer way to build — but it’s worth knowing the trade-offs people are flagging:

• Preview only, Early Release required. You can’t just flip a switch in any tenant — you need an Early Release environment to access the new editor. Keep it off production.
• Classic agents aren’t going away. Topics, broader channel deployment, and full analytics still live on the mainline orchestrator. Pick the right tool: classic for those scenarios, the new editor for new builds that want true agentic behavior.
• The activity map isn’t in the test panel. If you relied on watching the orchestration path while testing, that view isn’t surfaced in the new editor’s test experience yet.
• Single-page vs. tabs is a preference. Some builders liked the old tabbed layout for keeping a complex agent organized. Everything-on-one-page is faster for small and medium agents, but a very large agent can feel dense.

Why it matters

This is arguably the moment Copilot Studio stops being “low-code with an LLM bolted on” and starts being a proper agentic platform. Skills + Python + MCP + a containerized runtime add up to something genuinely new. The toggle means there’s low risk in trying it in an Early Release environment — build something, and flip back to classic if you need topics or broader channels. Given how quickly it’s moving through preview, getting familiar now means you won’t be caught off guard when it becomes the default.

#CopilotStudio #AgentBuilder #PowerPlatform #MCP #AIAgents

On one side, an open ecosystem is forming around Agent Skills — small SKILL.md files published on GitHub that teach an agent how to do something specific. Anyone can write one. Anyone can fork one. It’s the README, but for behavior.

On the other side, enterprises are standing up governed skill layers inside platforms like Microsoft Dataverse — “business skills” that live behind identity, policy, and admin approval, and that any connected agent can pick up at runtime.

Both sides are growing fast. Neither side talks to the other. The open community ships skills daily that never make it past the firewall. The enterprise side hand-authors skills from scratch that someone, somewhere, has already written better.

That gap is what I wanted to close. So I built SkillWright — a Copilot Studio agent whose entire job is to source, vet, and install skills for other agents.

Repo (open source, swagger + agent assets included): 👉 https://github.com/dvsRCalejo/SkillWright

What it is

SkillWright is not a chatbot. Think of it as a procurement function — but for behavior, not software.

Give it a topic. It goes out to public GitHub, finds candidate skills, reads them, judges whether each one is actually useful, and — for the ones I approve — installs them as business skills in Dataverse. From that moment on, every agent connected to the Dataverse MCP server can discover and use them. No rebuild. No redeploy. Update the skill once, and every agent that picks it up next gets the new version.

It’s authored entirely in Copilot Studio, source-controlled with the skills-for-copilot-studio VS Code tooling, and shipped as a normal solution. No custom hosting, no glue code.

What it needs to run

I want to be honest about the platform floor here, because SkillWright leans on it:

• A Managed Environment in Power Platform (for governance and policy).
• Dataverse Intelligence enabled — this is what unlocks business skills as a first-class concept.
• Dataverse MCP Server (preview) available in the environment.
• A GitHub custom connector (the one in the repo, defined by a Swagger file), authenticated with a fine-grained PAT scoped to read public repo contents.

If any of those are missing, the agent will still load, but creation calls will fail — and rightly so. The governance layer is the point.

How it works

There are three moving parts, and I deliberately kept each one boring.

Discovery is a custom GitHub connector with a small, surgical set of operations: search code, search repos, get a repo, get a tree, get a blob. The agent’s go-to query is filename:SKILL.md — every result whose path ends in /SKILL.md is, by convention, one skill. For folder-based skills it walks the tree recursively and pulls each file as a base64 blob.

Vetting is where the agent earns its keep. It fetches the candidate SKILL.md, decodes it, parses the name and description (which can live in YAML frontmatter or a markdown table — both are out there in the wild), and judges it against the bar I care about for business skills: clear trigger phrases, numbered step-by-step instructions, concrete examples, troubleshooting notes. Skills that turn out to be developer tasks in disguise — a scripts/ folder, a tool wrapper, something that only makes sense if you also have a shell and three CLIs installed — get flagged with a reason before I commit.

Install is one call to the Dataverse MCP server, which creates the approved skill as a business skill — name, description, instructions, and any references/ files attached as Resources. No custom storage layer, no bespoke schema, no form to fill in. Honestly, it’s easier for the agent to create a well-formed business skill than it is for me to do it by hand in the maker portal — it already has the parsed content in front of it, knows the shape Dataverse expects, and just submits it. And critically: nothing is installed without an explicit confirmation from me.

The bit I find genuinely interesting

Here’s the insight that made the whole thing click: Agent Skills and Dataverse business skills use the same format. Same shape. Same semantics. Same SKILL.md.

That sounds like a small technical detail. It isn’t. It means the open skill ecosystem on GitHub and the governed enterprise skill layer in Dataverse aren’t two different worlds that need translation between them — they’re the same world with a border crossing in the middle. SkillWright is the border crossing.

There’s a second, weirder consequence — and this is the one I keep coming back to. The Dataverse MCP server doesn’t just write business skills; it also reads them. So the moment SkillWright finishes installing one, any other Copilot Studio agent connected to that same MCP server can see it, pick it up, and act on it on its next turn. No re-publish. No “add a skill to this agent” step. No coordination between maker and consumer. One agent installs, every other agent benefits — automatically.

That includes SkillWright itself. The very same agent that just installed a skill can immediately turn around and use it. The first time I watched it install a skill and then, in the next turn, behave according to that skill, I felt like I’d quietly crossed a line.

Why I think this matters

Reuse. Most of the skills any given business needs have already been written by someone on the internet. Hand-authoring them again is wasteful. Sourcing them — with judgment — is not.

Governance without lock-in. The enterprise gets approval, audit, identity, and a single place to manage what agents are allowed to know. The community gets the open SKILL.md format, no proprietary fork. Nobody has to give anything up.

Runtime discovery beats redeployment. Once a skill lives in Dataverse, every connected agent finds it on its own — no code change, no release, no per-agent wiring. That’s a very different operating model from “ship a new agent.”

Where this goes next

I’m now thinking less about SkillWright itself and more about what changes when skill curation becomes a job an agent can do. If sourcing skills is cheap and governed, the constraint on agent capability stops being “what did we build” and starts being “what did we choose to admit.” That’s a much more interesting constraint.

If you want to poke at it, fork it, or break it — the repo is here: https://github.com/dvsRCalejo/SkillWright

Which makes me wonder — and this is the real question I’d love your take on:

If your agents could quietly pick up new skills from the public internet, vetted but not authored by you, would you let them? And where exactly would you draw the line?

#CopilotStudio #PowerPlatform #Dataverse #MCP #AgentSkills

Most institutional knowledge lives in three places: a Word doc nobody opens, a flow somebody built two years ago, and the heads of the two senior employees who actually know how things work. The moment you point an AI agent at it, you start re-implementing that knowledge inside the agent — and again in the next agent — and again the next time the process changes.

Business skills, now in public preview in Dataverse, fix that.

What a business skill actually is

A business skill is a record stored centrally in Dataverse that captures one of your organization’s processes, policies, or pieces of domain expertise as natural-language instructions — the steps, the information required, and the business rules that apply.

Think of it as a runbook the agent reads and follows:

• “How do we qualify an inbound lead?”
• “How do we approve a discount over 15%?”
• “How do we run an onsite HVAC inspection — what questions to ask, by equipment class?”
• “How do we onboard a new vendor — accounts, documents, approvals, due-diligence checks?”

You write the steps once, in plain language. Agents do the rest.

How agents pick them up: the Dataverse MCP server

Business skills are surfaced through the Dataverse MCP server. Any agent connected to that server discovers relevant skills automatically at runtime and uses them to complete tasks against your Dataverse data — according to your organization’s standards.

Because they live in Dataverse and ride on MCP, the same skill works across every MCP-compatible client:

• Microsoft Copilot Studio
• GitHub Copilot
• Visual Studio Code
• Azure AI Foundry
• Any other MCP client your team uses

Define a skill once, and every agent that should follow it does — without you porting logic between platforms.

Why “central in Dataverse” is the magic word

This is the bit makers usually miss. Storing a skill once in Dataverse instead of once per agent changes the operating model:

No republishing. No tracking down individual agent configurations. Update the source of truth and the change applies everywhere.

Create, share, and govern from Power Apps

Business skills live in Dataverse, but you author and manage them in Power Apps. From make.powerapps.com you can:

• Create a skill by writing the process in natural language, or upload existing documentation (an SOP, a runbook, a process Word doc) and let it become the skill.
• Share with specific people, teams, or security roles using the standard Dataverse sharing model.
• Govern with built-in visibility controls — who can see it, who can edit it.
• Deploy across environments by adding the skill to a Power Platform solution and shipping it through your existing ALM pipelines.

Prefer to work conversationally? You can create and update skills by asking an agent, through the Dataverse MCP server itself.

A real customer example

Velrada built Inspection Agent to help worksite supervisors and field workers track equipment maintenance. The agent uses business skills to drive the inspection itself: for an onsite HVAC check, it invokes a skill that determines the right questions for that equipment class, looks up the last inspection outcomes, and pulls in historic issues — producing a consolidated, conversational report and follow-up guidance.

Update the inspection process for HVAC units, and every Inspection Agent in the field follows the new steps the next time it runs. No app updates. No re-deployments.

Who this is for

Business skills are aimed at three audiences:

• Makers who want to codify how their team actually operates instead of re-explaining it to every agent.
• Agent builders who need agents to follow real, organization-specific processes — not generic LLM instructions.
• Admins who need governance over how business knowledge is shared, versioned, and deployed across environments.

Get started

To switch this on today (public preview):

1. Enable Dataverse intelligence in the Power Platform admin center for the target environment.
2. Open Power Apps and go to the Business skills page from the left navigation.
3. Create your first skill — write it in natural language or upload an existing process document.
4. Connect an agent to the Dataverse MCP server and watch it discover and follow the skill.

Want a head start? Microsoft ships a sample business skills repository on GitHub with production-ready examples you can install directly into your environment.

If you’re already building agents, business skills are the missing layer between what the agent knows and what your organization actually does. Start small: pick one process that’s currently re-implemented in two or more agents, write it as a business skill, and rip the duplicates out. The first time the process changes and you only edit it in one place, you’ll feel the difference.

Learn more

• What is Dataverse intelligence?
• Business skills overview
• Create and use business skills
• Sample business skills on GitHub
• Announcement: Introducing business skills — Teach agents how your organization works

Most teams stop at Solution Checker. Solution Checker is great for platform-level safety (deprecated APIs, security smells, supportability), but it doesn’t grade craftsmanship: control naming, formula complexity, delegation issues, topic design in agents, trigger phrase quality, and the dozens of other things that separate a healthy solution from one that will haunt you in production.

The good news: you can wire Solution checker enforcement (at the environment) + Power CAT Tools Code Review (for craftsmanship) + Copilot Studio Kit (for agent governance) + Power Platform Pipelines gated extensions (the glue) into a single multi-dimensional quality gate. None of these are new tools — they’re just rarely combined.

Layer 1 — Solution Checker, enforced at the Managed Environment

This is the foundation. Solution Checker enforcement is configured per Managed Environment, not per pipeline. When set to Block, any solution with critical issues is rejected at import time — before anything changes in the environment — regardless of whether it arrived through a pipeline, a manual import, or DevOps.

Set this once on each target environment (or, even better, on an environment group so every member environment inherits it — pair this with the Default Deployment Pipeline rule and you get governance-by-default for every new environment).

But Solution Checker won’t tell you that a canvas app has 800 controls on one screen, or that a Copilot Studio topic has only one trigger phrase. That’s where layer 2 comes in.

Layer 2 — Power CAT Tools: real code review for makers

The Power CAT Tools suite ships a Power Platform Code Review tool that analyzes solutions against a customizable checklist of patterns. Some patterns are evaluated automatically (control counts, media size, network traces, formulas), others are marked pass/fail by a reviewer with comments and links back to specific code locations.

What it covers today:

• Canvas apps — control limits, embedded media, slow network requests, formula breakdowns, App Checker integration.
• Power Automate — flow patterns from POWERAUTOMATE_PATTERNS.md.
• Copilot Studio agents — the Copilot Studio Agent patterns: trigger phrase count, single-word phrases, long phrases, condition count, flow count, SharePoint auth mode, unused topics, synonyms quality, duplicate regex entities, end-of-conversation usage.

A review produces a summary dashboard (passed / failed / pending patterns) plus detailed insights — all stored in Dataverse tables in the governance environment. That’s the key: the results are queryable.

Layer 3 — Copilot Studio Kit for agent governance

For Copilot Studio agent solutions, the Copilot Studio Kit adds the behavioral dimension that even Power CAT can’t see: conversation analytics, escalation rates, topic coverage, session quality. If your pipeline is shipping an agent, the agent’s runtime data is part of the review, not just its design.

Layer 4 — Power Platform Pipelines gated extensions

This is what turns the above from “tools we have” into “gate every deployment must pass.” Power Platform Pipelines exposes three gated extensions — custom steps you can insert into a deployment and signal complete or reject:

• Pre-export Step Required — fires OnDeploymentRequested. Runs before the solution is exported from the dev environment. Only enabled on the first stage (e.g., Dev → UAT). This is where you put the code-review gate.
• Is Delegated Deployment — for service-principal-based approvals.
• Pre-deployment Step Required — fires OnPreDeploymentStarted after approval, before the deployment runs in the next environment.

Each gated step stays pending until your custom logic calls back with the right action:

• UpdatePreExportStepStatus (or UpdatePreDeploymentStepStatus) with status 20 = complete, deployment continues.
• Same action with status 30 = reject, deployment fails. You can include both maker-facing comments (“Your canvas app has 412 controls on screen BrowseGallery1 — please refactor before resubmitting”) and admin-facing comments.

Putting it together: the gate flow

In your pipelines host environment, build a cloud flow that:

1. Triggers on OnDeploymentRequested (Dataverse → When an action is performed → category Power Platform Pipelines) — optionally filtered by pipeline name with a trigger condition like @equals(triggerOutputs()?['body/OutputParameters/DeploymentPipelineName'], 'Contoso Pipeline').
2. Identifies the solution being deployed from the trigger output parameters.
3. Queries the governance environment (Power CAT Tools Dataverse tables) for the most recent Code Review record for that solution. Decision logic, for example:
   • Reject if no review exists in the last N days.
   • Reject if any critical pattern is marked Failed.
   • Reject if the pass rate is below your threshold.
4. For Copilot Studio agent solutions, additionally query Copilot Studio Kit data for the agent’s quality scores.
5. Calls UpdatePreExportStepStatus (Dataverse → Perform an unbound action) with status 20 and a confirmation comment, or status 30 with a reject comment listing exactly what failed.

The maker sees the result inline in the pipeline run history — including your comments — and either fixes the issues and resubmits, or proceeds. The solution isn’t even exported until the gate clears.

Microsoft ships a PipelinesExtensibilitySamples managed solution with starter flows for all three gated extensions — start there and replace the placeholder logic with your Power CAT / Copilot Studio Kit lookups.

Why this combo is the magic, not just one of them

Each layer covers what the others don’t:

Run all four and your pipeline stops being a deployment mechanism — it becomes a maker enablement loop. Every deployment teaches the maker something concrete and gives them a self-service path to fix it. No manual code reviews, no admin tickets, no “we’ll check it later in production.”

A note on staging the rollout

Don’t enable rejection on day one — you’ll create a riot. The recommended ramp:

1. Sprint 1–2: Build the gate in observe-only mode — always call UpdatePreExportStepStatus with status 20 (complete) but log what would have been rejected.
2. Sprint 3–4: Switch to warn mode — complete the step but post the would-have-been-rejected comments to the maker so they see what’s coming.
3. Sprint 5+: Flip to block — start rejecting on the patterns the team has agreed are non-negotiable. Keep the rest as warnings.

Same staging works for the Solution Checker enforcement on Managed Environments (Off → Warn → Block).

This is one of those quiet-but-powerful combinations that the platform fully supports today — almost nobody connects all the pieces. If you already have pipelines and Managed Environments, you’re three configuration steps and one cloud flow away from automated, multi-dimensional code review on every deployment.