Agents on the GitHub Copilot harness consume Copilot credits while you build them, not only when they run. Copilot Studio has per-agent credit limits for that reason, and alerts you when one is crossed. Those alerts go to tenant and environment administrators. They do not go to the person who built the agent.
That is the whole post. The rest is what I did about it.
The gap
Microsoft’s own Customer Advisory Team says it plainly in Cost control and governance in Copilot Studio: “Built-in limit notifications are sent to tenant and environment administrators, not necessarily to the agent owner.” The fix is left to your own process.
You can configure how close to the limit the notification fires. You cannot configure who receives it.
So an administrator gets an alert naming an agent they did not build. Our demo tenant has 148 agents, three on the harness. At that size it is a lookup and a queue, and the maker who could act in a minute never hears about it.
What I built
One flow, five connections, no app registration
Nothing is stored that the admin centre already keeps. The only new data is the alert log. You can have it spiik/copilot-credit-alerts.

One scheduled flow, no dashboard.
GET /licensing/environments/<envId>/entitlements returns allocated capacity, consumed capacity and enforcementRules in one call per environment. When one trips the trigger, a single POST to the resource query API returns every agent in the tenant with environmentId, ownerId and isCLIAgent. That last field is the harness flag under the name the API uses, and it holds true, false or empty. Filter on == "false" and the empties vanish silently.
The flow emails the owners of those agents, and the same owner is not told about the same agent twice in seven days.
Zero allocated does not mean zero consumed
The percentage rule alone would have missed the worst case in our own tenant.
One environment had 32.5 credits consumed and nothing allocated. There is no ceiling to be eighty percent of, so a threshold rule never fires, and the consumption comes straight out of shared tenant capacity. That is the dangerous case, not the safe one.
The trigger is two conditions: past eighty percent of the allocation, or nothing allocated and something consumed.
What happens on one nightly run
Two API calls decide everything. The rest is a loop and a suppression check

It tells everyone, and that is deliberate
Every harness agent owner in the environment gets the mail, not only the one responsible. There is no way to know which one that is.
Agents can have their own limits and Copilot Studio enforces them. Reading that back is another matter. I went through the whole agent inventory schema: it carries name, owner, environment, model, channels and connectors, and no consumption, no limit, no status. Update Resource Threshold is a PUT with no GET beside it. Per-agent attribution cannot be done with what these tools expose today.
So the mail does not pretend otherwise. It names the environment, says how many harness agents live in it, and states that per-agent consumption is not available. The subject line is the environment, not your agent.
Designing around a missing field is better than implying you have it.
The table is for the administrator
A row is written when a mail goes out, and only then: agent, owner, environment, timestamp, percentage, tenant pool, how many harness agents that environment holds, and whether the owner was told.
That is the other half of the fix, and it points the opposite way from the email. Microsoft’s alert names an agent and stops there. This table names the owner and confirms the owner has been told.
An administrator can read it as it is, or put a page on top of it. Either way the question “does the person responsible already know” has an answer, before anyone decides whether to raise a limit.
Ownership is not hidden. The Agent 365 registry lists it, and that view is on standard Microsoft 365 plans. It is a different console from the credit alert though, so joining the two by hand is a step per alert, and automating that join through the registry’s Graph API needs Enterprise 7. There is a second source. The Power Platform inventory API returns ownerId directly, with no extra licence, on a connection this flow already had. That is where the owner in these emails comes from.
Closing
Most of the work was deciding what not to build. Version one was a dashboard PPAC already had. Version two watched per-agent limits the API will not expose.
What is left knows less than the admin centre does. It just tells someone who can act, and it is honest about how little it knows.
As of August 2026 I could not find a published implementation of this routing, so the source is on GitHub under MIT: spiik/copilot-credit-alerts. The gap is documented, now the fix is too.
Sources
Cost control and governance in Copilot Studio, Microsoft Customer Advisory Team
Manage costs for agents powered by the GitHub Copilot harness
Manage Copilot Studio credits and capacity
spiik/copilot-credit-alerts, MIT