The instruction "build an AI agent inventory" usually dies one of two deaths. Either it becomes a quarter-long asset-management program that never ships, or it becomes a spreadsheet one person filled in once and nobody trusts twice.
There is a third path: treat it as a 30-day build with a deliverable at the end of every week. This is the working plan behind our guide to the AI agent registry — what to do, in what order, and what "done" looks like on day 30.
One ground rule before day one: decide, and say out loud, that registration is not punishment. If reporting an agent triggers an interrogation, teams will stop reporting agents. The inventory's job in month one is visibility, not enforcement.
Week 1 — declare the record and collect what you know
Start by declaring what a record is, because "list our agents" means nothing until the columns are fixed. The working set: a named owner, business purpose, risk tier, the model or models the agent calls, the tools and APIs it can reach, its data reach, containment status, kill-switch path, and where its audit log lives. Resist adding a tenth column. Every field you add is a reason someone abandons the form.
Then collect. Announce a self-report window to team leads and platform admins: tell us what you run, no judgment attached. Pull in what IT already knows — the agents engineering deployed, the pilots that got budget, the bots the last hackathon left behind.
Two disciplines matter this week. Accept partial rows: an agent with an owner and a purpose but no risk tier is a fine week-one record. And do not classify yet — collection and judgment are different modes, and mixing them slows both.
Deliverable: a sheet with rows in it, visibly incomplete, shared where people can see and correct it.
Week 2 — connect the platform registries
Self-reporting finds what people remember. The platforms remember everything they run.
Azure AI Foundry, AWS Bedrock, Google Vertex AI, Salesforce and ServiceNow each keep a registry of the agents built on them. Week two is about reading those registries rather than working around them. With a master-registry product, connectors pull each platform's own agent list into one place — each record landing with its provider, model, owner and type, and staying in sync within what the platform exposes. That is exactly what the Kosmoy Agents Master Registry does across those five platforms, alongside the agents built and run in Kosmoy itself.
Doing it by hand is legitimate at small scale: ask each platform's admin to export the agent list, and merge. Just price in the cost — a manual harvest is stale the day after you run it, so put a re-export date in the calendar before you close the laptop.
Platforms that expose no usable API get their agents entered manually and tagged as manual. The tag matters: a gap you can see is a task, a gap you cannot see is a blind spot.
Deliverable: one merged list. Expect it to be longer than week one's — that difference is the first measure of your shadow AI.
Week 3 — classify and assign owners
Every agent gets exactly one named owner. Not "the sales ops team" — a person who answers when the agent misbehaves. Agents nobody claims escalate to the platform's admin as interim owner, which reliably motivates the real owner to appear.
Then tier the risk. Keep it coarse and consequential: a tier is only worth recording if it changes what happens next — the depth of review, testing and oversight the agent gets. Where the EU AI Act is in scope, anchor the tier to the agent's risk classification so the tier carries its obligations with it.
Time-box this week aggressively. Classification meetings expand to fill any container. Decide on the information you have, mark low-confidence calls for revisit, and move. A wrong-but-recorded tier gets corrected; an unrecorded one gets forgotten.
Deliverable: every row has an owner and a tier, with the shaky ones flagged.
Week 4 — reconcile shadow AI and wire to runtime
Now run the comparison the whole exercise exists for: the harvested list against your approved AI use cases. Agents that match are recorded and monitored. Agents that do not match are your shadow AI — flagged and routed to review, not to a takedown. For each one: assign an owner, classify the risk, register the use case it actually serves, or retire it if nobody will stand behind it.
Expect the shadow queue to be mostly mundane. In our experience the typical unmatched agent is legitimate work that skipped a step, not sabotage. Treat it that way and the next discovery cycle gets easier, because teams stop hiding.
The second half of the week is the part that makes day 30 different from a one-off audit: wire the inventory to runtime. Re-harvest the platform registries on a schedule instead of by heroics. Make changes to an agent's scope or ownership land as recorded events, not silent cell edits. This is the point where a spreadsheet stops being the right tool and a live registry starts earning its keep — the sheet records what people remembered, the registry reconciles with what is running.
Deliverable: a matched inventory, a shadow-AI triage queue with owners, and a standing re-harvest cadence.
What you have on day 30 — and what you don't
You have one list across every platform, a named owner and a risk tier per agent, a triage queue for the unmatched, and — most valuable — the reconciliation habit. You do not have completeness, and you never permanently will: new agents ship weekly, and discovery is a loop rather than a milestone. The signals that keep the loop fed — platform registries, gateway traffic, SSO logs — are covered in Agent Discovery: Finding the Agents Nobody Registered.
Day 31, the inventory stops being a project and becomes the front door of your governance program: every newly found agent enters, gets classified, and joins the same operating loop as everything you built on purpose.
Frequently asked questions
How long does it take to build an AI agent inventory? A working first version takes about four weeks: one to declare the record and collect known agents, one to connect the registries of the platforms where agents live, one to classify agents and assign owners, and one to reconcile the list against approved use cases and wire it to runtime. Completeness comes later; the operating habit starts now.
What should an AI agent inventory include? One row per agent, wherever it runs, with a named owner, business purpose, risk tier, the models it calls, the tools and APIs it can reach, its data reach, containment status, kill-switch path and audit-log location. The last two fields are the ones incident responders need first, and the ones most inventories skip.
Do you need to buy tooling to build an agent inventory? Not to start. A spreadsheet handles the first pass at small scale, and publishing an imperfect sheet beats waiting for a platform. Tooling earns its place when agents span multiple platforms and the inventory must reconcile with runtime continuously — pulling each platform's registry into one list and flagging what was never approved.