Cataloging Agent Sprawl Doesn't Cure It — It Institutionalizes It.

Start honestly, because the discovery story is not vapor. You cannot govern what you cannot see, and for an enterprise that has genuinely lost track of where its agents live, discovery is a real first step. The API-management and integration platforms earned their position: prebuilt connector breadth and API-led connectivity genuinely accelerate integration and make reuse a habit instead of a heroics project. Design-time and runtime API governance — rulesets, one control plane over the entire API estate — is real, valuable, and hard to build. The newer agent control planes go further still: they discover agents and tools, attach delegated identity, apply guardrails and policy to the agent call, and turn an existing API into an agent-ready tool with a few clicks. That is advanced work, and pretending otherwise is how you lose an expert reader in the first paragraph.

So the critique here is not "the scanner doesn't work." It works. The critique is about what a scanner can structurally be — and why the most sophisticated registry in the world is answering the wrong question.

Watch how the sprawl narrative is framed across the category. One vendor sells a registry-and-scanner suite that roams your other clouds to catalog agents — and its own cited advisors already warn that such registries curdle into "stale spreadsheets." A data-activation platform ships a control tower that watches the agents and routes between them but never actually runs them. A mass-market automation platform tells a now-familiar story: a business wakes up to find dozens of agents spun up across teams with no coherent plan. Different logos, one architecture, one confession. Each is describing a runtime it does not own.

That is the tell. Sprawl is not a discipline failure that a better console will fix — it is a structural consequence of having no single place for the business to run. When every cloud, every SaaS tenant, and every team can originate an agent, the agents are born off-platform by default, and the platform's only recourse is to go find them afterward. The registry is not curing the disease; it is the enterprise's official record of the disease, refreshed on a schedule. Cataloging sprawl doesn't cure it. It institutionalizes it — gives it a console, an owner, and a line in the budget.

Take the best argument the category has, not the weakest. The most advanced position on offer is an agent control plane with governance by design across the API lifecycle: delegated identity so an agent acts as a scoped principal, policy and guardrails enforced at the gateway, discovery that turns the existing API estate into governed agent tools, and even "guided determinism" to keep agent orchestration on the rails. Genuinely advanced. Concede it fully.

Then draw the line precisely, because the line is architectural and survives any roadmap. That control plane governs two things extremely well: the API estate and the agent interaction — which API or agent may be called, under what identity, with what policy, logged at the gateway. What it does not do is structural, not a feature gap: it does not hold the business process's durable state, it does not enforce the business action's authorization at the moment of execution, and it cannot produce a per-action business audit — because the process still executes inside the endpoints the fabric connects. Governance lands on the call; the work commits somewhere the call can only reach. The registry knows an agent was invoked. It does not, and by construction cannot, own what the agent then did to the business three systems away.

Here is the mental model that makes the boundary obvious. An air-traffic controller is indispensable: it sees every plane, assigns identity, sequences the traffic, and keeps aircraft from colliding. But the controller does not fly the plane and does not own the flight. The pilots and the aircraft do that, in the sky, out of the tower's hands. A scan-and-register control plane is air-traffic control for agents — it watches, identifies, and routes the calls. The actual flight — the order that posts, the refund that commits, the record that changes — happens inside the endpoints, where the controller's authority ends.

For a CxO the cost of that gap is not abstract; it shows up in three lines you already recognize:

• Blast radius. An agent that is governed at the call but executes in an endpoint can take a business action the gateway logged as "one API call" and the ledger records as an irreversible commit. The policy checked whether it could call; it did not sit inside the transaction that decided whether it should have.
• Audit exposure. When the regulator asks who authorized this specific action, a gateway log of calls and identities is not a per-action business audit. You can prove the agent was allowed to knock; you cannot always prove, in one immutable record, what it changed and under which control.
• Reconciliation cost. A map of a drifting estate is a recurring tax. Every new region, tenant, or team resets the scan, and the console is authoritative only until the next thing spins up. You are funding a permanent effort to catch up to your own architecture.

The alternative is not a smarter scanner. It is an architecture where there is nothing to scan for — because there is no off-fabric place for the business to run. On a Composable Process Fabric, an agent is not a thing you discover after the fact; it is an Atomic Agent, a first-class primitive, composed together with Intelligence Orchestration, Deterministic Workflows, Functions, and Connectors into a governed process on one runtime over a shared Semantic Ontology. It comes into existence on the fabric, authorized and audited at birth, with human-in-the-loop as a first-class control rather than a bolt-on.

That single design choice turns three things the registry can only observe into architectural properties of the system:

• Sprawl is structurally impossible, not policed. An agent cannot originate in some unseen region, because origination happens on the one runtime. There is no "shadow agent" class of object — every agent is a governed primitive in a governed process, or it is not an agent in your estate at all. Governance is by construction, not a console forever reconciling a drift it cannot stop.
• Authorization is enforced at execution, inline. The business action's permission is checked as a step of the same workflow that commits it — not attached to the call and hoped to hold in the endpoint. The agent does not merely pass a gateway; it executes inside a runtime that decides, per action, whether the action is allowed.
• The audit is per business action, in one immutable record. Because the process itself is the governed runtime object, the trail is not a log of calls that left the platform — it is one continuous record of what the business actually did, from decision to commit, with the Connector as the only typed, audited I/O edge to the outside world.

Do not over-read the claim. This is not "you need zero integration." The enterprise estate is real and most of it stays — the systems of record you did not build and will not replace remain, and the fabric runs over them through governed Connectors, with authentication, authorization, and audit at that edge. So the honest statement is not that ES makes external systems disappear. It is narrower and sharper: a new agent inside the fabric is born on the fabric, not discovered on someone else's cloud a scan-cycle later. The Connector is the thin, audited boundary to the estate; it is not the place the business runs.

Which quietly reframes the whole procurement conversation. The question a registry is built to answer is "which platform maps my scattered agents best?" — and the leading control planes answer it impressively. But that is a question you only have to ask if the agents scattered in the first place. The question that actually decides the enterprise is "which fabric are my agents born on?" Answer that one correctly and the map becomes unnecessary, because the territory and the runtime are the same object. You do not need a better inventory of things running loose. You need them not to be loose.