Agent sprawl is an architecture problem, not a security gap

Agent inventory becomes harder when several teams introduce AI through different systems and purchasing routes. The enterprise surveys discussed below describe that concern. A registry can reveal what exists, what it can touch, and who owns it. Buyers also need to decide how the next responsibility should reuse existing context, controls, and capabilities. Visibility and coordinated work are related design tasks.

What the surveys found

Two reports published this year describe the same enterprise from two different vendors. IBM's Institute for Business Value, working with Oxford Economics, surveyed senior technology executives across dozens of countries and industries and found that most CIOs and CTOs are held accountable for AI systems they do not fully control, and that only a small minority keep a current, complete inventory of the agents already running inside their walls. OutSystems surveyed a comparable population of global IT leaders and found the same pattern from the buying side: agentic AI adoption has gone mainstream, and nearly all of those leaders now worry that the resulting sprawl is adding complexity, technical debt, and security exposure faster than governance can absorb it.

Fragmented ownership is a deployment condition rather than an inherent limit of native agents. Workday's Agent System of Record describes governance for its own and third-party agents. Buyers should examine whether the chosen configuration shares the required context and authority. Inventory and coordination can be parts of the same platform.

Why a registry fixes the symptom

A registry can support useful lifecycle controls, including ownership, review, and retirement. Its existence alone does not establish that several agents share evidence or coordinate overlapping actions. Equally, a product called a registry may offer capabilities beyond inventory. Inspect the specific system before treating its label as its limit. Ask how it handles two agents assigned adjacent parts of the same responsibility and whether conflicting actions are detected before an effect is committed.

A shared foundation changes the design of the next workflow. Nodes is building a permission-aware company context graph that specialized teams can use for their own responsibilities. Reusing relevant context should reduce repeat assembly; that benefit must be measured in the delivered scope. Shared context still needs an agent inventory, ownership records, and permission review. Actions requiring approval remain gated by the customer's policy.

The practical issue is whether the enterprise has an operating plan for the combined activity. Several independently purchased agents can be well governed. One shared runtime can still contain duplicated work, conflicting authority, or abandoned obligations. Agent count is a poor substitute for examining which responsibilities are active, how they overlap, and who can change them.

Where this argument runs out

The registry case still deserves its due. An enterprise that already has three dozen agents scattered across a dozen systems cannot wait for an architecture migration before it gets visibility into what those agents can already touch. A control plane that discovers and tags existing agents is the honest, immediate answer to the accountability gap the surveys describe, and it should exist regardless of what an enterprise decides to build next. The mistake is treating that control plane as the destination instead of the bridge.

When the next objective arrives, inspect the capability already available before buying or creating another agent. Reuse may be sensible where the existing foundation provides appropriate context, tools, and authority. A specialist product may still meet the need with less work. New integrations require acceptance tests even when they join an existing graph. The comparison should show what is reused, what changes, and who retains operating responsibility.

There is a review cost even when an agent is bundled with an existing vendor. Turning on a new capability needs a scope decision: which data can it read, which effects can it cause, and who authorizes those effects? An independently purchased agent adds supplier and contract diligence. Neither review should be duplicated without reason, but prior approval of a data connection does not authorize a different use of its records. Record the reusable controls and the changed risks.

A shared foundation may let reviewers reuse evidence about a known boundary and data flow. The next workflow still needs scrutiny of its purpose, effects, recipients, and operating limits. Measure the review work saved instead of assuming it disappears. A new action against an old system can create a materially different responsibility.

As the number of responsibilities grows, inspect whether shared components reduce effort or merely concentrate complexity. A common graph can make lineage easier to trace while requiring more careful permission checks. A common runtime can coordinate work while requiring dependable cancellation and recovery. Those tradeoffs belong in the evaluation alongside the number of vendors and agents.

Test overlap before adding another worker

Consider an illustrative responsibility for upcoming vendor renewals. One agent reads contract dates, another checks usage, and a third prepares an owner briefing. Three workers may be appropriate if each has a bounded job and their results join one accountable workflow. Three independently triggered recommendations to different owners may create duplicate work. Counting the workers does not tell the buyer which design is operating.

Start by following one renewal through the proposed system. Which record establishes the date? Which source describes usage, and how fresh is it? Who is responsible if the sources disagree? Ask whether the workflow can reuse an existing contract reader or needs a new capability. A system that creates a new specialist for every request may increase maintenance without adding useful coverage. The desired response can be an existing procedure, a single tool, or a request for missing evidence.

Now introduce an overlap. Another team has already begun negotiating the same renewal. Does the new workflow discover the active responsibility and coordinate with its owner? Can it preserve a different recommendation without sending contradictory instructions? Shared storage alone does not solve that problem. The runtime needs explicit ownership, dependencies, and permitted handoffs. Inspect the behavior in the configuration being proposed rather than accepting a diagram of agents connected by arrows.

Test a stopped job too. If the owner cancels the renewal investigation, which child tasks stop and which effects have already happened? A sent email cannot be treated as unsent merely because the parent task was canceled. An uncertain API response needs reconciliation. The operating record should show completed effects, unresolved obligations, and the person accountable for the next step.

Finally, ask what the company retains after the responsibility ends. Useful artifacts might include reviewed contract mappings, evidence supporting the decision, the owner's correction, and the later measured cost. Temporary calculations need not become durable company truth. Reuse should preserve the scope in which a lesson applies and the source that supports it. A future renewal with different constraints should not inherit an old recommendation blindly.

Use that case to compare total effort. Record setup work, customer interventions, exception handling, and the time needed to add the next relevant variation. Count successful reuse as well as new agents created. This makes the commercial question concrete: which option carries the agreed responsibility with acceptable effort and controls? The answer may be an incumbent platform, an internal build, or Nodes for a scope it can demonstrate. Agent count is an input to that review, not the outcome being purchased.

Keep the evidence boundary visible

Nodes supports Nodes Cloud, a single-tenant customer VPC, and customer-managed on-premises deployment. Private configurations can enforce zero customer production-data egress inside the approved boundary; Nodes Cloud is a Nodes-managed environment. The shared-team runtime and full outcome-learning loop described here are product direction. Candidate evaluation at one Fortune 500 insurance carrier is the production evidence anchor.

None of this replaces the registry an enterprise already needs for the agents it has today. It changes what the enterprise buys next. The question worth putting to a vendor selling agent number forty-one is not only what the agent can see. It is whether the workflow needs to exist as a separate purchase at all, whether anyone checked which agent actually took the action, or whether it belongs inside a system the enterprise can already govern.

The two reports landed the same season, and they will not be the last. Every quarter, another system of record ships another agent, and another vendor sells a better way to see the pile. Seeing the pile is worth doing. It is not the same project as declining to build the pile in the first place, and the next contract on a CIO's desk is the one that decides which project this quarter was.

Sources

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.