Ask a CIO how many applications the enterprise runs and you will get a number. It might be wrong, it might be out of date, but it exists, because three decades of enterprise architecture built the discipline of knowing. Ask the same CIO how many AI agents the enterprise runs and you will get a shrug, or a guess, or a number for the one platform they happen to know about. Everyone else’s agents — the ones spun up in a business unit’s copilot, the ones wired into a SaaS product’s “automation” tab, the ones a developer stood up over a weekend and never turned off — are invisible.
This is the problem the industry started calling agent sprawl somewhere around the middle of this year, and it has arrived faster than any wave of shadow adoption before it. The reflex is to reach for the security team. That reflex is not wrong, but it is incomplete, and it misreads what kind of problem this actually is.
The number that should scare you
The figures are the kind that get put on a board slide. IBM’s enterprise survey has the average large organisation running on the order of 1,600 AI agents by the end of 2026. Gartner projects the average Fortune 500 firm will have more than 150,000 agents in use by 2028. Meanwhile the surveys that ask the follow-up question — can you actually govern them? — keep landing around one in eight. Ninety-something percent of enterprises have agents in production; roughly twelve percent have any centralised way to inventory, permission, monitor, and retire them.
Sit with the shape of that gap. It is not that agents are risky in the abstract. It is that an organisation is acquiring a workforce the size of a mid-cap company’s headcount, made of software that acts on its own initiative, and it has no roster. You would not run a company where anyone could hire a thousand employees, hand them system access, and never write down that they exist. That is the position most enterprises are in right now, and the ones treating it purely as a firewall exercise are solving the wrong half.
A portfolio problem, and EA has solved it before
Here is the part the security framing misses: an inventory of things the enterprise owns, each with a purpose, an owner, a set of dependencies, and a lifecycle from birth to decommission — that is not a new artefact. It is the application portfolio. It is the CMDB. It is capability mapping. The enterprise architecture discipline is, at its core, the discipline of knowing what you have, why you have it, and what has to happen to it as the business changes. We have been building and curating exactly this kind of register for thirty years.
The agent register is the same artefact aimed at a new class of asset. And the operating-model thinking EA already uses transfers almost intact: an agent, like an application, implements some slice of a business capability, and the value of the register comes from tying the messy runtime reality back to that stable business view. This is precisely the framing Maher Dahdour reaches for in Enterprise Architecture in the Age of Agentic AI, which argues that capabilities remain the right primary unit and agents are implementations of them. The book names the need for an agent registry explicitly. What it does not do — what almost nobody has done yet — is get concrete about what goes in it and who holds the pen. So let me.
What actually belongs in an agent registry
A service catalog entry answers “what does this do and how do I call it.” An agent registry entry has to answer more, because an agent does not wait to be called — it acts. At minimum, each entry needs:
- An accountable human owner. Not a team inbox — a named person who answers for this agent’s behaviour, the way a service owner answers for a service. If no one will put their name to it, that is the finding.
- Purpose and the capability it serves. One sentence on what business outcome it exists for, mapped to the capability model so the register rolls up to something an executive recognises.
- What it can touch. The tools, systems, and MCP servers it can reach, and the data classes it can see. This is the single most important field and the one most often missing, because it is where an ordinary automation becomes an uncontrolled integration point between your data and a model.
- Which model and version drives it. Model behaviour drifts with updates; an entry that does not record the model cannot be reasoned about when the behaviour changes underneath you.
- How it is triggered, and its autonomy level. Human-in-the-loop, scheduled, event-driven, or free-running — and whether it can invoke other agents, which is where risk compounds non-linearly.
- A kill switch and a retirement criterion. How you stop it in a hurry, and the condition under which it should be turned off for good. Agents, like applications, do not retire themselves.
None of these fields is exotic. Every one of them is a field a mature EA practice already keeps for applications. The work is not inventing a new schema; it is extending a discipline you have to an asset class that has outrun it.
Why it reports to architecture, not just security
Security should absolutely consume this register — for identity, least-privilege, and audit. But security is built to answer “is this safe,” and it answers it at a point in time. The register’s harder questions are architectural and continuous. Do we have four agents quietly doing the same thing in three business units, the classic portfolio duplication that EA exists to catch? Is this agent still serving a capability we still care about, or is it a zombie nobody dares switch off? When the model provider changes terms, which entries are affected and what depends on them? Those are portfolio-management questions, and portfolio management is architecture’s job.
It is also the natural home for the lifecycle half of the problem, which security tends to under-own. The hardest thing about any portfolio is not adding to it — it is retiring from it. EA has decades of scar tissue around application decommissioning, and that scar tissue is exactly what agent sprawl will demand, sooner and at higher volume. Standing a governance gate in front of agent creation will fail the same way every human review board fails against machine-speed demand — a dynamic I have written about at length. The register is the alternative: not a gate that says no, but an observable system of record that keeps up.
Where to start on Monday
You do not begin with a tool purchase or a policy. You begin by discovering what already exists, and you have more raw material than you think. Your identity provider knows about the service accounts and non-human identities the agents run as. Your emerging MCP tool registry knows which tools are exposed to be called. Your SaaS admin consoles list the “automations” and “copilots” switched on inside products you already pay for. Seed the register from those three sources and you will have a first, uncomfortable, genuinely useful picture within a week — the same way the first application portfolio always gets built, by reconciliation rather than by decree.
From there it is the discipline EA knows: assign owners, map entries to capabilities, flag the duplicates and the zombies, and make registration a condition of production access rather than a form filed afterwards. Pair the portfolio view with the pattern-level vocabulary in Agentic Architectural Patterns so that when the register surfaces a risky shape — an agent calling agents with no human in the loop — you have a named pattern and a known mitigation rather than an argument.
The enterprises that win the next two years will not be the ones that deployed the most agents. Everyone will deploy a lot of agents. They will be the ones who could still answer, at any moment, the oldest question enterprise architecture asks: what do we have, and why. Agent sprawl is frightening because the honest answer today is “we don’t know.” Turning that into an answer is not a new job. It is the job — pointed at the fastest growing, least visible, and most consequential portfolio the enterprise has ever acquired.