Nobody Knows How Many AI Agents They’re Running

Ask an infrastructure team how many virtual machines they run and they’ll give you a number. Ask how many Kubernetes clusters they operate and they’ll point to a dashboard. Ask for an AI agent inventory and the answer usually becomes a discussion about what counts as an agent.

That discussion is itself the problem.

The Classification Problem Nobody Solved

Before any organization can inventory its agents, it has to decide what counts as one. Most haven’t.

The point isn’t that the examples are edge cases. Most of them are production deployments at mid-size enterprises right now. The point is that organizations are making AI agent inventory decisions — including the decision not to maintain one — without agreeing on what they’re inventorying.

Classification failures aren’t new on this site. Dependency classification failure drove the VMware dependency audit problem. Infrastructure classification failure is how shadow control planes form. Authority classification failure is what MCP tool chains expose. Supplier classification failure is why a vendor review process never sees the SDKs and libraries embedded inside what it approved — the same category-definition failure, one layer down in the supply chain. The AI agent inventory problem is the same failure recurring in a new layer of AI infrastructure architecture: the organization hasn’t defined the category, so it can’t close the gap.

The Deployment Pattern That Made This Inevitable

Agents entered the enterprise through workflow tooling, not infrastructure procurement. That single fact explains why no AI agent inventory exists.

Virtual machines entered through infrastructure teams. There was a request process, an allocation review, a tracking system, and usually a chargeback model. Containers entered through platform teams — Kubernetes clusters, namespaces, resource quotas, admission controllers. In both cases the inventory system existed before the workload arrived.

Agents entered through:

• Business users building Copilot Studio workflows
• Automation teams deploying n8n and Zapier integrations
• Developers wiring LangChain services into internal tooling
• Prompt engineers connecting Claude or GPT to production data sources via MCP
• Low-code builders embedding model calls into approval workflows
• SaaS vendors activating agent capabilities inside tools the enterprise already licensed

None of those paths required infrastructure involvement. None of them triggered a procurement workflow with an inventory requirement. The agents exist in environments the infrastructure team owns — but they arrived through governance gaps those environments don’t cover.

The Agent Already Exists. Nobody Calls It One.

Many organizations aren’t failing to inventory agents because they don’t have them. They’re failing because they still classify them as workflows.

The scheduled summarization job that runs every morning, pulls from three internal systems, and posts a digest to a Slack channel — that’s an agent. The ticket triage workflow that reads incoming support requests, classifies severity, assigns queues, and escalates edge cases — that’s an agent. The procurement assistant that checks vendor contracts against policy and flags renewal risks — that’s an agent.

Each of those was built by a team that would describe it as automation. The distinction matters architecturally: a workflow executes a fixed sequence. An agent makes decisions based on model output, invokes tools, and produces actions with real side effects. The execution authority profile is different. The risk profile is different. The governance requirement is different.

The classification problem and the deployment problem compound here. When agents arrive through non-infrastructure paths and get classified as workflows by the teams that built them, they never reach any AI agent inventory layer — not the CMDB, not the service catalog, not the infrastructure team’s awareness. They exist at production scale in invisible categories.

What “Running” Means — and Why the Inventory Gap Becomes an Authorization Gap

Even once an organization decides what counts as an agent, “how many are running” is not a straightforward question.

Agents are often stateless between invocations. The execution ends, the context clears, the compute cost drops to zero. By a naive definition, it isn’t running. But the tool grants remain active. The webhook registration persists. The scheduled trigger fires again tomorrow. The downstream system it’s authorized to write to hasn’t revoked that access. The agent is dormant, not decommissioned — and the distinction is rarely tracked.

This is where the inventory gap becomes an authorization gap. The progression is predictable:

Unknown Count → Unknown Ownership → Unknown Authority → Unknown Risk

An organization that can’t answer how many agents exist also can’t answer who owns each one, what each is authorized to do, or what actions it can trigger. That’s not an inventory problem anymore. That’s an architectural exposure — the same class of gap that the Governance & Runtime Control layer is designed to close, and the same structural failure that emerges when console access bypasses IaC, or when SaaS control planes accumulate authority nobody audited. The mechanism is different. The failure mode is structurally identical. The Environment Was Isolated. The Authority Wasn’t. is the infrastructure-level version of the same gap: an evaluation environment accumulated production-equivalent authority because nobody had been assigned to classify it, the same way an agent accumulates unaudited authority because nobody had been assigned to count it.

Even a complete inventory doesn’t close the gap on its own. Knowing an agent exists and is authorized to act is not the same as being able to prove, after the fact, that a specific action was permitted. That precondition problem — an authorization trail is meaningless without a complete inventory of what’s authorized to act in the first place — is the starting point for Who Approved the Model’s Output? Building an AI Authorization Trail.

The same “nobody counted it, so nobody can govern it” failure isn’t unique to AI agents, or even to enterprise IT. The Domain Was the Containment Unit. ICANN Is Reconsidering That. traces the identical structure in domain portfolio governance: most organizations can’t produce an account-level map of every domain they hold — brand-defense registrations, dormant properties, agency-managed subdomains — for the same reason most can’t produce a complete AI agent inventory: nothing in how those assets accumulated ever required counting them. ICANN’s own Associated Domain Checks policy work is on a trajectory to make that unknown inventory the thing that gets tested, the same way an incident eventually makes an unknown agent inventory the thing that gets tested.

What a Real AI Agent Inventory Looks Like

A minimum viable AI agent inventory isn’t a CMDB project. It’s a set of questions every deployed agent should be able to answer:

The authority level attribute is the one most inventory attempts omit. Tool grants describe technical access. Authority level describes execution scope — whether the agent can approve, publish, modify, escalate, or commit. Two agents with identical tool grants can have radically different risk profiles depending on what those tools allow at the action layer. An agent that can read a contract is different from one that can execute a renewal. This exposure compounds when AI vendors activate agent capabilities inside tools the enterprise already licensed — the authority level was never defined because the agent was never classified as one.

Two of the six attributes in the table above already are delegation fields under a different name: Owner is the Principal, and Decommission Criteria is Duration — the condition under which a delegation’s validity ends. Enterprise Architecture Has Identity Governance. It Doesn’t Have Delegation Governance. makes that structure explicit for delegation generally; this inventory table is a domain-specific instance of the same object, built for agents specifically before the general model had a name.

Most organizations that have begun tracking agents have a version of the first four attributes. Almost none have a consistent definition of authority level at the agent layer.

Some vendors are now trying to solve the identity half of this at the platform level rather than leaving it to internal inventory discipline. Every AI Platform Is Becoming An Authority Platform examines VMware’s AgentMinder, Microsoft’s Entra Agent ID, and Salesforce’s Agentforce governance stack — each assigns every agent an enterprise-grade identity distinct from the humans and services around it, a direct answer to the classification problem this post opens with. It’s a partial answer, not a complete one: a platform-issued identity only covers agents built or deployed inside that platform. The Copilot Studio workflow, the n8n automation, and the LangChain service in the table above are exactly the agents a single platform’s identity model doesn’t reach.

A narrower version of the same partial-answer pattern ships at the tool-connection layer instead of the identity-platform layer. Nutanix Put MCP Behind a Gateway. The Real Problem Is Authority. covers NAI 2.8’s MCP Gateway — real governance over which tools an agent can reach once it’s already inventoried and connected, and no answer at all to whether that agent was ever counted in the first place. Tool-grant governance and agent-count governance are solving adjacent problems, not the same one; a well-governed connection to an agent nobody inventoried is still an unknown.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →