Copilot Agent Inventory: Where Microsoft Lists Your Agents, and What It Misses

Why the count matters outside IT

An agent built in Microsoft Copilot (formerly Microsoft 365 Copilot) can read company data and answer on the company's behalf, and in Copilot Studio it can use capacity the company pays for. An agent nobody watches can keep its access and keep using paid capacity. Numbers grow quickly once building is open: Microsoft's own tenant held more than 100,000 agents when its Inside Track team wrote about it in November 2025. Few companies will reach that, but the same two questions arrive with the first dozen: who owns each agent, and when should it be switched off?

Those are policy questions for the decision group. The compliance lead wants to know which agents reach which data, and the CFO wants to know which ones still justify what they cost, while IT needs a list that matches what is actually in the company's Microsoft 365 environment. One register, reviewed each quarter, can answer all of them, and the paper Copilot after rollout sets it within the wider agent guardrails.

Where Microsoft lists your agents

The main list is the Agent Registry in the Microsoft 365 admin center, under Agents, All agents, Registry. Microsoft now files it under Agent 365, but the Agent 365 service description says the inventory, the basic actions (publish, deploy, block, delete, approve, assign to users or groups, reassign an owner), conditions-based lifecycle rules and syncing agents from external platforms are included in every Microsoft 365 plan. Microsoft's agent actions page describes what admins can do from that list to agents built in Agent Builder, Copilot Studio, SharePoint and Microsoft Foundry. Agents published for the organization appear to users in the Agent Store.

Microsoft Agent 365, a separate per-user license generally available since 1 May 2026, adds what the free registry lacks. That means observability of what agents do, control over the tools and MCP servers (the connectors agents use to reach other software) they may call, Conditional Access for agents (rules on when an agent may sign in to company systems), and Purview and Defender protection. It needs a qualifying base license, typically E5 or Business Premium with the Defender and Purview suites, so check with your reseller. Separately, Copilot and Copilot Studio activity is logged in Purview audit as CopilotInteraction records carrying the agent's ID and name, per Microsoft's audit documentation, which is the trail to follow when someone asks what an agent did.

What none of these lists can see

Microsoft's lists stop at Microsoft's edge, apart from agents synced from supported external platforms. They do not show the AI features that now ship inside department software, such as an assistant in the CRM or an AI search feature in engineering software. Those tools need to be governed by the same policies as Copilot, and the Agent Registry cannot do that for you. The lists also miss AI apps people use on their own, though Microsoft can help find those. Purview Data Security Posture Management (DSPM) covers enterprise AI apps such as ChatGPT Enterprise and Claude Enterprise and, through browser activity and Defender for Cloud Apps, consumer tools, per Microsoft's Purview guidance for AI.

Those department features still process company data, and some arrive through a vendor update rather than a purchase decision. They belong in the same register as the Copilot agents, entered by hand from the AI tool register and from the contract with each vendor, with the business owner of that tool as the owner of the entry.

Worked example. An insurer opens its Agent Registry and finds mostly personal agents and a handful of team ones. Its AI tool register adds entries Microsoft cannot see, such as the drafting assistant in its claims system and an AI search feature in its document management software. All of them go into one register, and the entries from outside Microsoft carry the same fields as the rest.

One register, joined to Microsoft's

We keep one register and start it from what the Agent Registry already shows, so IT is not retyping what the tenant knows. The Agent Registry stays the source for Microsoft agents. The register adds what it cannot hold, such as the business owner next to the technical one, the data classes each agent reaches, its reach level under the maker rules, its review date, and the department-software features Microsoft never sees. The fields themselves are covered in our explainer What is an AI agent registry?, so we will not repeat them here.

The decision group only has to agree two rules. No agent is shared beyond its maker without an entry, and an entry without an owner is a reason to block the agent. Both are easy to check, and both give the compliance lead something concrete to sign.

A quarterly review the decision group can sign

A register is only useful if someone reconciles it, and we do that each quarter. IT compares the register with the Agent Registry and flags two kinds of gap: agents with no entry, and entries with no owner or no recent use. Owners confirm their agents are still needed. The compliance lead looks at any agent whose data reach changed. Each agent that uses paid Copilot Studio capacity has a budget owner, and the CFO sees its consumption against that budget and the result it was built for, with a named person who can suspend it if it overruns. Microsoft's own tenant ties team agents to scheduled owner confirmation, which it calls attestation, per the Inside Track report. The full method for finding duplicates and settling ownership is in our guide to controlling agent sprawl.

Retiring an agent in Microsoft terms

Retirement needs a rule, because an agent nobody owns keeps answering until someone stops it. Microsoft gives admins two actions, per its agent actions page. Blocking an Agent Builder or Copilot Studio agent removes it from every place it runs, while blocking a SharePoint or Foundry agent only removes it from Copilot Chat. Deleting is a soft delete with a 30-day window to restore, and the event is audited. Management rules can also block ownerless agents nobody uses, and hand ownerless Agent Builder agents to the former owner's manager.

We write retirement triggers into the policy. An agent is retired when its owner leaves and nobody takes it over, when its purpose has ended, when it has gone unused for a set period, or when its data source has changed. Block the agent while its owner confirms retirement, record the reason in the register, then delete it. Microsoft keeps a deleted agent restorable for 30 days, after which it is gone. The stages before retirement, from build to change, are in our guide to agent lifecycle management.

The case for using Microsoft's registry alone

A fair objection: why keep a second list when Microsoft gives you one free? For a company whose agents are all built in Agent Builder and Copilot Studio, with no AI features in its department software worth tracking, the Agent Registry plus its lifecycle rules may be enough, and a separate register would only drift out of date. We would start there and add a register only when the first agent or AI feature appears that Microsoft cannot see. That point often comes early, since CRM and service desk vendors have been adding AI features to their products, but the decision should follow what is actually in your tenant.

Where QueryNow fits

QueryNow sets up the agent register and the review behind it as part of our Copilot AI Foundation service. We reconcile what your Agent Registry shows with the AI features in your department software and give every agent an owner and a review date. We also configure the lifecycle rules and retirement steps in the admin center. The first quarterly review runs with your decision group before we hand it to IT. Since 2014 we have delivered more than 200 production deployments on AI and the Microsoft platform.