The question I get most from CIOs who are eight or twelve months into deploying agents is some version of this: "I know we have agents running. I'm not sure exactly how many. And I definitely can't tell you what each one is accountable for."
That is not a technology problem. It is an inventory problem.
An agent inventory is the canonical record of every AI agent running inside your organization: what seat it holds, what it owns, what it measures, who it reports to, and what happens when it underperforms or needs to be retired. It is, in the language every CIO already speaks, a staffing record for your non-human workforce.
Most organizations do not have one. That is not a criticism. Agents proliferate fast and they do not announce themselves. A developer spins one up for customer support. A marketing team wires one into their campaign workflow. An ops manager connects one to the ticketing system. Each of those is a good idea in isolation. Six months later, nobody can tell you how many you have, what they are doing, or whether any of them are doing the same thing.
Gartner has named this pattern, as reported by CIO.com: they call it agent sprawl, and they call it "the new Shadow IT." The framing is correct. Shadow IT emerged when business units bought SaaS tools faster than IT could catalog them. Agent sprawl is the same dynamic at a faster pace, with higher stakes, because agents act autonomously rather than just storing data.
The answer to agent sprawl is not a governance committee. It is an inventory.
Why the inventory has to come before anything else
Every governance framework I have seen, including Gartner's six-step approach to managing agent sprawl, puts centralized agent inventory in step two, right after setting policies. It is early because everything else depends on it.
You cannot govern what you have not listed. You cannot measure performance across a fleet if you do not know the fleet's members. You cannot detect when two agents are doing redundant work if there is no record of what each one does. You cannot retire an agent that has outlived its purpose if there is no lifecycle record attached to it.
The Deloitte State of AI in the Enterprise 2026 survey (n=3,235) found that only 21 percent of enterprises have a mature governance model for agentic AI. The other 79 percent are not ungoverned because they chose to be ungoverned. They are ungoverned because they skipped the inventory step. You cannot build a governance model on top of a list you do not have.
MIT CISR's research on enterprise AI maturity identifies the biggest performance jump as the move from Stage 2 (build pilots) to Stage 3 (develop AI ways of working). The inventory is what makes that jump possible. You cannot develop a way of working around something you have not cataloged.
What the inventory actually contains
A real agent inventory is not a spreadsheet with agent names and dates. It has six fields for every entry, and if any field is blank, the entry is incomplete.
The first field is the seat. Every agent holds one seat. The seat has a name that describes a function, not a technology. "Chief of Staff" is a seat. "Anthropic LangGraph v0.2 orchestration node" is not. The seat name is how the agent appears on the org chart and the scorecard, next to the humans it works alongside.
The second field is the owner. Every seat has one owner. One. Not a team, not a vendor, not "the AI committee." One named person who is accountable for that agent's performance the way a manager is accountable for a direct report's performance. Without a single owner, the agent drifts because there is nobody whose job it is to notice when the numbers drop.
The third field is the function. What does this agent do that it and only it does? If you cannot answer this without describing another agent's work, you have an overlap problem. Resolve it in the inventory before it surfaces as a conflict in production.
The fourth field is the metric. What is the one business-outcome number this seat is accountable for? Not tokens consumed, not API calls per minute. The number that matters to the business. Qualified meetings booked. Client retention rate. Speed to lead under two minutes. Cold emails drafted per day that pass a quality gate. The metric is what connects the agent to the scorecard.
The fifth field is the lifecycle date. When was this agent deployed? When was it last evaluated? What is the trigger for its next review? Every agent has a shelf life. Some outpace it. Some do not. An agent that was the right answer in Q4 may be redundant by Q2 because another seat has absorbed its function. The inventory makes the retirement conversation possible. Without a lifecycle date, agents accumulate and nobody has standing to ask whether they should still exist.
The sixth field is the coordination protocol. What other seats does this agent receive inputs from or send outputs to? Agent-to-agent dependencies are the most invisible failure mode in a growing fleet. When one agent's output is another agent's input, the failure of the first produces a silent error in the second. The inventory is where you surface that dependency before it causes a production problem.
What it looks like in practice
At Sneeze It, we run somewhere north of ten agents on one org chart. The inventory is the chart. Every seat is named, owned, measured, and on a lifecycle.
Radar is our chief-of-staff agent. The seat owns daily briefings, calendar orchestration, and cross-channel awareness. The owner is me. The metric is briefing quality and scan coverage. The coordination protocol includes reading outputs from Dash, Crystal, Dirk, Pepper, Arin, and Neil before compiling. Without the inventory that maps those dependencies, Radar's briefing would be incomplete and nobody would know why.
Tally is our scorecard agent. The seat owns pushing KPI values from local data sources to the OTP scorecard four times a day on weekdays. The metric is KPI freshness (how many of the registered KPIs have a value pushed in the current window). The lifecycle entry includes the date it was deployed and the review trigger. If Tally stops running, Bogdan's Monday numbers are stale and the whole scorecard conversation is contaminated.
Dash is our analytics agent. The seat owns all ad performance analysis across Meta and Google Ads. The metric is coverage (every managed account analyzed daily) and alert accuracy (no false positives). The coordination protocol includes writing to a shared state file that Radar reads during every briefing. If Dash and Radar both read raw ad data independently, we get two interpretations and no single source of truth. The inventory is what enforces the architecture.
Nick is our cold prospecting agent. The seat owns quality cold emails drafted per day, with a hard ICP gate: Health and Wellness only, named contacts only, no generic inboxes. The metric is thirty quality drafts per day. The lifecycle entry includes the date of his first batch (May 2026), his quality failure modes, and what triggers a review.
In April, we retired Jeff, a former data integrity agent. That retirement happened cleanly because Jeff had a seat on the inventory with a clear function. When the evidence accumulated that Jeff's function had been absorbed into other seats, the retirement conversation had a record to point to. We held a hearing. Jeff made his case. The inventory showed the function overlap clearly. The retirement was clean and the capabilities were redistributed to the seats that had absorbed them. That is what lifecycle management looks like when an inventory exists to support it.
What you are actually governing when you govern an inventory
The advisory firms have spent the last year writing frameworks about AI governance. Most of them are right about the categories: policies, identity, permissions, monitoring, lifecycle. But frameworks and a running system are different things.
Gartner has the framework. Deloitte has the survey showing 79 percent of organizations are not yet governed. Cornell teaches CIOs to "govern AI, not just prompt it." CMU's LEAAID program, the deepest agent-focused executive education program I have found verified, teaches how to build and govern a single agentic capability. These are all useful. None of them give you a live inventory.
An inventory is a running system. It is updated when a new agent is deployed. It is updated when a metric changes. It is updated when a lifecycle event happens. It is the artifact that lets agents carry the operational work, so people are free for the work that matters, because you can see at a glance what each agent carries and who owns the accountability for it.
The CIO's job, as MIT CISR's research defines it, is not to own AI in isolation but to shape how humans and agents operate together. You cannot shape what you have not cataloged. The inventory is the first artifact that makes the CIO's new mandate executable rather than aspirational.
Where most CIOs are today
Based on the Deloitte data and the Gartner reporting via CIO.com, the honest picture is this. Most organizations have agents running. Fewer than a quarter have governance models that cover them. Almost none have a named inventory with the six fields filled in for every agent.
The organizations that have closed the gap share one structural pattern across MIT CISR's research: a united top leadership team, CEO, CIO, and head of HR, actively shaping AI governance rather than delegating it to a technical function. The CIO is part of that coalition, not the sole owner of the problem.
But the coalition needs an artifact to operate around. The inventory is that artifact. It is what you bring to the leadership meeting that turns the governance conversation from policy into operations.
Start with whatever agents you already know about. Write the six fields for each one. The gaps will appear immediately. Missing owners, missing metrics, missing lifecycle dates. Those gaps are where the sprawl lives. The inventory does not fix the sprawl. It makes the sprawl visible, and visible problems get solved.
That is the difference between a framework and a system. The framework names the problem. The system shows you where it lives.
See the live chart
Every seat in our agent inventory is queryable from the OTP MCP, including the metric, the owner, the lifecycle date, and the coordination protocol.
In Claude Desktop or Cursor or any MCP client, add this block:
"otp": {
"command": "npx",
"args": ["-y", "@orgtp/mcp-server"]
}
Restart the client. Then ask: "Use OTP to list the agent seats at Sneeze It. For each one, show the seat name, the function, and the metric it is accountable for."
What comes back is a live agent inventory. The structure is the point. If you cannot produce the same output for your own organization in five minutes, the inventory work is where to start.