By Silas Vogtmann
During the last few weeks, I had the same conversation several times with different organisations.
Someone had spotted Microsoft’s recent changes to Copilot Studio and suddenly the questions started flying:
“Do we use this?”
“Will it cost us anything?”
“Who’s responsible for it?”
“Can we even see who’s building agents?”
What struck me wasn’t the licensing change itself. Those happen all the time. What struck me was how differently organisations reacted to exactly the same piece of news. Some spent twenty minutes checking their setup and moved on.Others spent the next two weeks trying to figure out whether they had a problem.
Why such big differences?
The change isn’t really the interesting part
On 3 August, Microsoft made the GitHub Copilot harness generally available in Copilot Studio and set it as the default experience for new agents.
It’s a better way of building. Instead of wrestling with topics and branching logic, makers describe what the agent should do in plain language and let the system plan its own steps.
The catch is that it bills differently.
Consumption now starts during the build process itself. Describing, testing, previewing and evaluating agents can all consume credits. A Microsoft 365 Copilot licence doesn’t cover that usage, and from 1 September developer and trial environments are also moving to usage-based billing.
If you work with the Power Platform, you’ve probably already heard all of that. But what did your organisation do, when you found out?
In some organisations, the response was straightforward. They already knew which environments existed, who owned them and what they were used for. They could see where the new harness was enabled. They already had capacity allocations, spending limits and governance processes in place. The announcement resulted in a few decisions and a couple of configuration changes.
In other organisations, the announcement triggered a much deeper investigation. Nobody was entirely sure which environments existed, who was building what, or how consumption was being governed.
The licensing change wasn’t the problem. The lack of visibility was.
Because when a platform update creates operational uncertainty, the update itself is rarely the real issue. More often, it exposes something the organisation didn’t know about its own platform.
You can also look at it like this: when a change is interesting, governance is working. When a change is surprising, governance is being tested.
The difference usually comes down to visibility and ownership. Organisations that understand their platform can assess the impact of a change quickly. Organisations that don’t are forced to start by understanding themselves.
Clear governance means being able to answer simple questions: which environments exist, who owns them, which are production, which are developer or trial, and which agents are running where.
The organisations that answered those questions quickly weren’t more mature because they had more documentation. They were more mature because governance was already part of operating the platform.
That also made it easier to understand the practical implications of the change: who could create agents, which environments would be affected, what happened when limits were reached, and who could approve exceptions.
The specifics changed. The operating model didn’t.
Our recommended steps
If you want to get ahead of the billing changes, I’d start with six practical actions:
- Identify where the GitHub Copilot harness is already being used.
- Review historic credit consumption in developer and trial environments.
- Allocate capacity intentionally across environments.
- Configure limits and hard-stop mechanisms, not just notifications.
- Decide who is allowed to build agents and where they can build them.
- Assign clear ownership and establish a regular governance review cadence.
The first two can usually be completed this week. The last four are where I believe the long-term value sits.
Because long after this particular licensing change has disappeared from everyone’s news feed, you will still need to know what you’ve got, who owns it and where the boundaries are.
And you’ll need to be ready for the next change.
That is what governance is for.
