Agent Sprawl Is Coming. Who Owns the Estate?

Finance has an agent. HR has three. A project team has built another one to search its documents. Someone in customer service has connected an assistant to a case-management system.

Each team can explain its own idea. Ask who owns the combined estate, and the answer becomes less clear.

We have seen this pattern with applications, spreadsheets and automation scripts. Local usefulness accumulates into an enterprise responsibility. Agents add a particular complication: some can interpret a request, select tools and act through connected services.

Their authority deserves as much attention as their functionality.

An agent needs a place in the portfolio

I would treat an operational agent as an enterprise asset with a purpose, an owner and a lifecycle.

The first portfolio view can be modest. For each agent, record the business outcome, accountable business owner, technical support owner, identity, approved data sources, connected tools, authority limits and review date. Include how it can be paused and what happens to its access when it is retired.

Those details answer questions an inventory of names cannot. Which agents can update customer records? Which depend on the same policy source? Who responds if the business owner leaves?

Connect business ownership, technical dependencies and lifecycle management in one portfolio view.

A register is only useful if somebody maintains it. The most practical approach is to connect registration and review to existing delivery, identity and service-management processes. Asking teams to update a separate spreadsheet indefinitely is unlikely to produce a reliable enterprise view.

Look for shared failure paths

Imagine three agents using the same policy library. One supports expenses, another answers employee questions and the third helps a service team interpret eligibility.

Each agent may pass its own test. If the shared library contains an obsolete rule, the organisation can receive three consistent but incorrect answers.

The dependency matters more than the number of agents.

Architecture should make those common dependencies visible: shared knowledge, identity services, integration gateways, models and operational support. Each shared component needs an owner and a way to identify affected consumers when it changes.

A shared source can spread an error across otherwise separate workflows. Map the consumers and the response path.

Access also needs an effective expiry path. An agent that has stopped receiving attention may still have permission to retrieve information or invoke a tool. Retirement should remove that authority, deal with retained information and preserve the evidence the organisation needs.

Keep business ownership close to the work

An enterprise view does not require one central team to design every agent.

Business teams understand their workflows and should help define useful applications. Shared enterprise controls should establish the boundaries for identity, sensitive information, permitted actions, evidence and incident response. Architecture connects those responsibilities and identifies duplication or dependencies that individual teams may miss.

The Microsoft discussions about enterprise-ready agents brought this issue into focus for me: a development environment can manage its own agents, while the organisation still needs to account for agents built elsewhere or purchased within other products.

No single dashboard should be assumed to provide that completeness without checking what it actually covers.

At the next portfolio meeting, ask for the agents that can act on business systems, their owners and their authority limits. Start there. It is a manageable first view, and it will reveal where the larger operating model needs attention.