Nobody remembers building that agent

Agent sprawl does not arrive. It accumulates, and it accumulates for good reasons.

A team runs a Copilot Studio workshop and everyone builds something, because that is how the workshop works. A department solves its own HR-policy question in an afternoon, which is exactly what the platform was sold to do. A pilot gets built for a board demo, the demo goes well, and the agent stays switched on.

None of that is misuse. It is the product working. The problem is that creation is a five-minute act and ownership is a multi-year commitment, and only one of those gets recorded anywhere.

Four states worth separating

"How many agents do we have?" is the wrong first question, because the number on its own tells you nothing. What you need is the same population split four ways.

Published and used

Working software. Leave it alone, but know it exists — it will need a review when the thing it is grounded in changes.

Published and unused

Live, reachable, answering nobody. Low urgency, but it is clutter that makes the rest of the inventory harder to read, and every one of them is a surface that still inherits whatever permissions its knowledge sources carry.

Orphaned

The owner has left, changed role, or was a contractor whose engagement ended. This is the state that matters most and gets noticed least, because an orphaned agent behaves exactly like a healthy one right up until something needs changing. Then you discover there is no one to ask what it was for, what it is grounded in, or whether it can be turned off.

Touching sensitive content

An agent grounded in HR records, contracts, or anything carrying a restrictive sensitivity label. Not necessarily wrong — often it is the whole point — but it belongs on a shorter review cycle than an agent that answers questions about the canteen menu.

Unowned is worse than unused

An unused agent costs you clutter. An unowned one costs you the ability to make a decision.

Every governance action you might want to take — retire it, re-ground it, restrict who can reach it, answer an auditor's question about it — starts with finding a human who can say what it is for. Without that name, the safe-looking option is always to leave it running, and so it runs.

This is why ownership should be an attribute you can report on, not a convention people are asked to follow. Conventions survive about as long as the person who introduced them.

The knowledge source is the risk, not the agent

It is tempting to think of an agent as a small application. It is closer to a front door onto content.

An agent answers from what it is grounded in, through the permissions of whoever is asking. That means the governance question is rarely "is this agent dangerous?" and almost always "what is it grounded in, and who can reach that?" Microsoft sets the underlying model out in its Copilot data privacy documentation: the permissions are the boundary, and the agent is the thing that makes what they allow immediately legible.

So an inventory that lists agents without their knowledge sources is half an inventory. The row you want reads: this agent, owned by this person, grounded in these sites, published to these channels, last used on this date.

Governance is a lifecycle, not an approval gate

The instinct after discovering a few dozen agents is to put a request form in front of the next one. That tends to produce two outcomes: a queue, and a quiet return to building things outside the queue.

The lighter model that actually holds has four parts, and none of them blocks creation.

• Every agent has a named owner, recorded at creation, and the record is checked rather than trusted.
• Ownership transfers with the person. An agent should appear in the leaver process beside the mailbox and the licences.
• Every agent has a review date proportionate to what it is grounded in — short for sensitive content, long for a public-facing FAQ.
• Retirement is a normal event, not an admission of failure. Most agents built in a workshop should be switched off within a quarter, and saying so up front makes it easy.

All four depend on knowing what exists, which is why the inventory comes first and the policy second. A policy written before the inventory is a policy about an estate you are guessing at.

Finding them

Copilot Insights builds that inventory automatically: every Copilot Studio agent in the tenant with its owner, status and channels, with the unused, orphaned and sensitive-data ones flagged, next to the licence picture rather than in a separate tool. It is read-only — it can see that an agent exists and who owns it, and it cannot alter or delete one.

Related: assigned is not adopted, the renewal meeting needs one page, and why posture drifts when nobody did anything wrong.