Checklist
Duplication and collision risk:
ten checks before you count.
Most agent inventories are wrong about duplication by roughly an order of magnitude - in both directions. These are the checks that make a count defensible, and the mistakes that make it useless.
Two questions get called duplication and only one is a problem. "Is this the same agent in more than one place?" is a deployment fact and usually healthy ALM. "Did somebody build this twice because they could not find the first one?" is a governance problem. Reporting them as one number produces a red dashboard nobody can act on.
The ten
One agent definition promoted through dev, QA, staging and production is four records and one governance decision. A genuine copy is a second definition somebody created because they could not find the first.
298 replicas versus 33 genuine copies in one 625-agent estate.Two agents called "Sales Assistant" may be the same agent in two environments, or two teams solving the same problem twice. Name matching cannot tell them apart, and it is the reason duplicate counts are usually wrong by an order of magnitude.
Name-only comparison would have reported 331 duplicates where 33 existed.Two agents both "using Dataverse" may read and write respectively. Comparing at connector level makes different agents look identical and identical agents look different.
Platforms return connector operations in whatever order they like. A hash of the raw configuration will report eight identical agents as eight different ones.
A naive hash produced eight distinct fingerprints for eight copies of the same agent.Replicas drift. If one environment's copy gains a tool the others do not have, it is no longer safe to treat the cluster as one thing - and that divergence is itself a finding worth investigating.
Worth checking per cluster before any bulk action.If a tool collapses a cluster to one row, find out which one. Approving a tool on the Staging copy silently approves it on production if the row represents the whole cluster.
One manifest row covered eight agents; the surviving row was Staging, not production.A bulk action across a cluster is one human decision applied to N agents. If the interface does not say N, the person clicking cannot know what they signed for.
15 of 43 tool rows each covered around eight agents.One judgement, N records. That keeps the audit trail per agent - so if one member later drifts, it can be re-examined without unpicking the whole cluster.
Never named, never owned, often still connected. They inflate the count and occasionally hold live credentials.
35 untitled drafts in one estate.Two agents doing the same job under different names, built by different teams, will not match on any structural comparison. Detecting that needs instruction text the platform APIs do not return - and a tool that implies otherwise is overstating what it can see.
Stated as a limit rather than papered over.Why it matters beyond a tidy inventory
Duplicates drift apart
Two copies of an agent diverge from the day the second is made. A policy applied to one is not applied to the other, and the copy nobody remembers is the one that keeps its old permissions.
Bulk actions hide their reach
Approving a tool, declaring a purpose or applying a policy across a cluster is one decision affecting many agents. If the interface collapses the cluster without saying so, someone is signing for eight things having seen one.
An inflated count wastes the review
Present a board with 331 duplicates and the platform team spends a week discovering their release pipeline works correctly. Present them with 33 and the work is real.
Figures are from connected tenants, used with permission and anonymised. Your estate will differ.
Get a defensible count by tomorrow.
Book a free 30-minute sessionOne read-only administrator consent. Nothing installed, no traffic proxied. First findings inside 24 hours.