What Is an Agent Inventory?

TL;DR

An agent inventory is the record of every agent that exists, not just the ones someone approved. It answers one question: what's actually out there, who owns it, and what can it touch.

That's a different job from a registry, which decides what's trusted to run. An inventory has to stay broad and a little uncomfortable, because the agent nobody signed off on is exactly the one it exists to catch.

Most enterprises don't have this. What they have is a spreadsheet a platform team keeps, a pile of OAuth grants nobody audits, and institutional memory that leaves with whoever built the thing. None of that adds up to a system of record.

Without an inventory, every governance question turns into an investigation: which agents can reach customer data, who owns the one still running six months after its author left. With one, those are queries, not projects.

Overview

Agents accumulate in places nobody was assigned to watch: a notebook a data-science team wired to a scheduler, an OAuth grant a sales rep clicked through in April, a service account a departed engineer left with standing access to the warehouse. None of those show up on an org chart, and none of them wait for permission to exist.

Discovery is what finds those agents. The inventory is what happens next: one record per agent, stating what it is, who's accountable for it, what it can reach, and whether anyone has checked on it recently. Skip that second step and discovery just produces a longer list nobody reads.

We think the useful test for whether something counts as an inventory is whether you'd trust it to answer a question under pressure. A spreadsheet updated at launch and never touched again fails that test even if it was technically complete on day one. A bare list of names fails it too. A name tells you an agent exists and nothing about whether it's safe.

Why Informal Tracking Breaks Down

Before anyone builds an inventory, tracking is informal, and it's informal for a reasonable cause: nobody was ever assigned to own agent visibility as a job. The information exists. It just never exists in one place.

• A platform team keeps a spreadsheet of the agents it deployed itself.
• Individual teams document agents, sporadically, in tickets and READMEs.
• SaaS-embedded agents live only inside a vendor's own admin console.
• OAuth-connected agents surface as app grants in identity logs, if anyone thinks to look.

Each source captures a slice and treats it as the whole picture. Take a legal team that authorizes a contract-review agent through a vendor's marketplace listing. Legal knows it exists, because they requested it. IT can see the OAuth grant behind it, since the agent now holds a standing read scope into the document management system. Neither team holds both facts about the same agent at once, and nothing forces them to compare notes.

one inventory record per agent --> owner, access, risk, review date OAuth grant -----/ code repo -------/ Five partial views, reconciled into one record. -->

Figure 1 — Five sources that each see a slice of an agent's existence, reconciled into a single record.

An inventory exists to do that reconciliation on purpose: the spreadsheet, the ticket, the console, the grant, folded into one record instead of five partial ones.

What an Inventory Records

A useful inventory captures more than a name. For each agent it holds the operational context that governance, security, and ownership decisions actually depend on: who owns it, what it's for, where it runs, whose identity it acts under, what it can reach, what permissions it holds, and when someone last confirmed it should still be running.

Take a marketing analytics agent. The name alone tells you almost nothing. The inventory record tells you the campaign team owns it, that it runs in production, that it reads from the data warehouse and can publish to the email platform, and that nobody has reviewed it since March. That's the gap between knowing an agent exists and knowing whether it's safe.

The exact schema is a build decision, not a definition one. What matters here is that every agent gets the same shape of record, however thin, instead of five different levels of detail depending on who happened to find it first.

Classifying Agents

Type shapes how an agent should be reviewed, so an inventory needs to distinguish between them rather than treating every entry as an interchangeable line item.

• Internal assistants that answer questions or draft content for employees.
• Workflow automations that move data and trigger actions across systems.
• Coding and engineering agents operating inside development environments.
• Third-party agents brought in by vendors or partners.
• SaaS-embedded agents shipped inside tools the business already licenses.

How an agent gets triggered matters just as much as what kind it is. Some agents only act when a person prompts them directly. Others run on a schedule or fire on events with nobody watching in the moment. An HR onboarding agent that provisions accounts the instant a new hire record appears behaves very differently, from a risk standpoint, than a legal assistant that drafts a clause only when an attorney asks for one.

Why Context Equals Risk

Not every agent carries the same risk, and the inventory is what makes that legible instead of buried in a config file somebody has to go read.

A read-only assistant that summarizes an internal wiki is low risk in practice. An agent that can query customer records, message people outside the company, or touch production infrastructure is not, and the same split shows up inside a single domain. A finance agent that reads ledger balances to build a report is a different animal from one that can initiate a payment.

The inventory records the attributes that drive that judgment: data access, action permissions, blast radius, autonomy. That's what turns "can this agent reach sensitive data" from a week of digging into a five-second query.

What Breaks Without One

Skip the inventory and none of this goes away. Agents still get provisioned, still accumulate access, still outlive the person who built them. What disappears is your ability to answer questions about them on demand.

At small scale that's survivable. A team running two or three agents can hold the whole picture in someone's head, and usually does. That stops working somewhere between a dozen agents and a hundred, and it stops quietly. Nobody declares the moment tribal memory fails. It gets discovered during an incident, when the question is "what can this thing actually reach" and the honest answer is a guess.

We'd put the real cost somewhere other than the incident itself: the response to it. A security team investigating a compromised credential needs to know, in minutes, everything that credential touches. Without an inventory, that's a scramble across five admin consoles and whoever still remembers building the thing, but with one, it's a lookup, and that's the difference between a bad afternoon and a bad week.

Conclusion

An agent inventory won't tell you whether an agent should exist. That's not its job. Its job is making sure that once an agent does exist, somebody can find it, name its owner, and see what it touches, and that this stays true long after the person who built it has moved on to something else.

Get that right and the rest of Agent Operations has something to stand on. Skip it, and every later control is built on a guess about what's actually out there.