Open the Power Platform admin center, click Manage, then Copilot Studio, and there's a page now called Agent Inventory. It reached general availability on 31 March 2026, after a public preview that began on 2 June 2025, according to Microsoft's agent inventory documentation. Before that page existed, finding every Copilot Studio agent in a tenant meant asking every maker individually or querying Dataverse by hand.
Where the inventory lives and what feeds it
The data refreshes automatically. Microsoft's agent inventory documentation says changes to an agent typically show up within about 20 minutes, and the broader Power Platform inventory documentation puts the figure at 15 minutes for anything created, updated or deleted across the wider inventory. Either way, updates land inside the hour, not overnight. The page tops out at 500 agents shown at once, and a deleted agent can stay visible for up to 48 hours afterward, per the same documentation, so a fresh delete isn't proof an agent is actually gone yet.
What it covers is every Copilot Studio custom agent and every Microsoft 365 Copilot Agent Builder agent, across every environment in the tenant, including the environments you may have forgotten you own. Columns are customisable, and every one of them, environment, owner, creation date, resource type, region, orchestration mode, is filterable, with filters stacking so you can narrow the view down to whatever slice you actually need. You can also reach the same data through the Power Platform API or Azure Resource Graph, querying the microsoft.copilotstudio/agents resource type, if you would rather script the count than click through it.
If you need more than any of those interfaces expose, the underlying tables are ordinary Dataverse, bot, botcomponent and botcomponentcollection, reachable through the standard Web API with Entra authentication. The bot table alone carries a statuscode field with values including Provisioned, Deprovisioned, Provisioning, ProvisionFailed and MissingLicense, detail that doesn't surface as a clean status column anywhere in the admin center. An agent that looks fine in the inventory but won't run for anyone is usually sitting on one of those last two values.
What the count leaves out
Version 1 classic Power Virtual Agents bots don't show up here at all. Anything your organisation built before Copilot Studio absorbed PVA lives behind a separate path, Manage, then Copilot Studio, then Classic chatbots. Run the new inventory and you get a real number. It just isn't the whole number, because the classic bots are counted somewhere else, on a screen most admins forgot existed.
Microsoft's agent inventory documentation says the inventory reflects the published version of an agent, and unpublished draft changes aren't shown until published. A maker can spend a week reworking an agent's authentication and its connectors, and none of it registers in the inventory until they hit publish. For governance that's defensible, since published is the version end users actually interact with. For budgeting it's a problem, because credit-hungry configuration can sit invisible in draft for as long as a maker chooses.
Capability listings cap at 200 resources per agent type. Push an agent past that limit, in topics, connectors, whatever the type, and the admin center shows a random 200, not the first 200 and not the most recent 200. Microsoft's agent inventory documentation does say the capabilitiesCounts field still reports the true total underneath, so the number exists if you know to look for it. The list on screen, though, is not the whole list.
Agent Builder agents carry no identity properties at all, per the same documentation. No botId equivalent, no entraAgentId, nothing to hang an Entra lookup on. The isManaged field, which flags whether an agent shipped inside a managed solution, returns null for every Agent Builder agent instead of true or false. Filter the inventory to find unmanaged agents as a risk signal and Agent Builder agents won't sort into either bucket. They sit outside the question.
Agents nobody owns anymore
An agent inventory earns its keep the day someone leaves the company. Microsoft's guidance on orphaned agents describes exactly that scenario, an agent whose original owner has left the organisation or moved roles, with nobody accountable for it and, per that same guidance, a real security risk rather than a paperwork problem.
The Power Platform API gives you two ways to handle it. Reassignment moves ownership to a named person using the NewOwnerAadUserId field in the request body. For a Copilot Studio agent that needs an environment administrator or higher. For an Agent Builder agent it needs a global tenant administrator, an AI administrator, or a Power Platform administrator, a stricter bar than the Copilot Studio path. Once reassigned, the new owner gets maker permissions on the agent's environment, the old owner loses access outright, and the new owner can read existing transcripts if their role carries the Read transcript privilege.
Quarantine is the other lever. A quarantined agent is disabled everywhere except the maker's own testing view, so it stops answering real users while the owner, or whoever has inherited the problem, fixes whatever triggered the quarantine. The owner can still edit it during that period, and once it's compliant again they can request an admin review to restore it.
Neither lever reaches classic chatbots. Reassignment and quarantine both return a 405, method not allowed, against a classic bot, per Microsoft's admin API documentation. The same exclusion that keeps a classic bot out of the inventory follows it through every cleanup action built on top of that inventory.
What you can't reach through the API either way is deletion of a Copilot Studio agent. The delete operation only covers Agent Builder agents. An orphaned Copilot Studio agent gets reassigned or quarantined, never deleted outright through that route, so cleanup means finding it a new owner rather than removing it.
Pricing what the inventory finds
None of this matters for spend control until the count underneath it is complete, because the per-agent limits in the Power Platform admin center only reach agents that show up somewhere in the system first. The path is Licensing, then Copilot Studio, then Summary, then Manage Agents. That page lists every Copilot Studio agent in the tenant with its configured monthly credit limit, its month-to-date billed credits, a status of Within limit, Nearing limit or Over limit, and the environment it lives in.
Set a limit on an agent and two guardrails switch on. Notifications alert admins, at both the environment and tenant level, as usage climbs toward the limit. Hard stop turns the agent off automatically the moment it hits the number you set, with no manual step required. That's separate from tenant-wide enforcement, which kicks in at 125 percent of prepaid capacity, a mechanism covered in our breakdown of Copilot Studio pricing.
Set the limit on the wrong agent, or forget to set it on one at all, and the guardrail simply never applies to spend nobody tracked in the first place. Manage Agents lists agents it knows about, and it knows about them because Agent Inventory found them first. A classic PVA bot behind the Classic chatbots screen, an Agent Builder agent still sitting in draft, an orphaned agent nobody has reassigned since its owner left, none of that appears on the list you're using to decide who's over budget.
The honest way to run this is to treat Agent Inventory as a starting count and check it against every one of those exclusions on a schedule, not as a one-time reconciliation done the week the page went GA and never touched again. An agent nobody has counted is an agent nobody can price, and right now the page that does the counting is only as complete as the admin who remembers what it leaves out.