SAP
AMS
Atlassian
Products
Industries & Expertise
BEST-SHORING
Knowledge Base
SALESFORCE
Most organisations have spent the last two years discussing artificial intelligence through the lens of use cases: a service agent, a procurement copilot, a sales assistant, a coding agent, or an internal search tool. This is a sensible place to start. It becomes inadequate once those experiments become operational systems.
An AI agent is not simply a chatbot with a better interface. It can retrieve data, call tools, initiate workflows, make recommendations, and sometimes carry out actions across multiple enterprise systems. As these agents proliferate, a new architectural problem appears: agent sprawl.
Agent sprawl occurs when agents are created, deployed, or connected to enterprise systems faster than the organisation can inventory them, assign accountable owners, manage their permissions, monitor their behaviour, and retire them when they no longer serve a useful purpose. It is the agentic-AI equivalent of the SaaS sprawl that many IT teams learned to manage over the last decade, but with a greater operational consequence. An unmanaged application may create cost and security risk. An unmanaged agent may also take action.
This is why an AI agent inventory is becoming a core enterprise-architecture requirement rather than an optional governance exercise. SAP’s recent research and product direction make the urgency clear: SAP reports that 98% of surveyed organisations have deployed AI agents or plan to do so, while fewer than half have visibility into an inventory of those agents.
The word “sprawl” can suggest that the problem is simply too many agents. It is not. A large number of well-governed, clearly owned, appropriately permissioned agents may create significant value. A small number of untracked agents can create serious risk.
The real problem is the absence of a reliable answer to basic questions. Which agents are operating in the organisation? What business process does each support? Which data sources, APIs, systems, and tools can it access? Who owns the business outcome, who operates it technically, and who is accountable for risk? What human approval is required before it acts? How is quality measured? When should the agent be changed or retired?
If those questions cannot be answered consistently, the organisation does not have an AI operating model. It has a collection of experiments with production access.
Earlier generative-AI use cases often produced text, summaries, or recommendations. Poor output was still a problem, but a person usually reviewed it before anything changed in a business system.
Agents change the risk profile. They can act across systems and processes. A customer-service agent may retrieve account data and amend a case. A finance agent may prepare an exception workflow. A procurement agent may interact with supplier information. A software-development agent may create or modify code. The relevant governance questions are therefore not only about accuracy. They include access rights, data handling, auditability, business authority, operational resilience, and the ability to stop or roll back action when something goes wrong.
The question is no longer only whether an agent gives a good answer. It is whether the organisation can explain what the agent is allowed to do, why it is allowed to do it, and who is accountable for the outcome.
This is particularly important when agents use Model Context Protocol servers, APIs, or workflow tools to reach enterprise systems. An agent’s usefulness often depends on cross-environment permissions. Those permissions should be governed with at least the same rigour as the permissions granted to human users.
Many organisations already maintain a list of proposed AI use cases. That list is useful for investment planning, but it is not an operational inventory.
A meaningful AI agent inventory records the architecture and governance context around each agent. At a minimum, it should capture the agent’s name and purpose, business owner, technical owner, lifecycle status, user population, systems and data sources accessed, permissions, model or provider, connected tools, human approval points, known risks, performance measures, and review date.
It should also show relationships. A customer-service agent may depend on a knowledge base, a CRM platform, an identity provider, a workflow engine, and an integration layer. A change in any of these components can affect the agent’s reliability or compliance. Architecture is what makes those dependencies visible.
The point is not to impose bureaucracy on every small experiment. The point is to apply proportionate governance as agents move from exploration to business-critical use. An internal assistant that drafts meeting notes needs different controls from an agent that can change customer records, initiate a payment exception, or trigger a production deployment.
An effective inventory allows leadership to answer four practical questions.
This sounds obvious, but it is often the hardest question to answer. Agents can be created within business applications, internal development platforms, vendor tools, automation products, and external services. Discovery must cover sanctioned and emerging use, not only centrally funded initiatives.
An agent should be mapped to its data sources, tool connections, permissions, and action boundaries. This includes whether it can only retrieve information, create a draft, submit a request, or complete a transaction. The distinction should be explicit.
Every production agent needs named ownership. The business owner should be accountable for the value and appropriateness of the use case. The technical owner should maintain the configuration, integrations, and reliability. Security, data, risk, and compliance stakeholders must be able to review the controls appropriate to the agent’s scope.
Agents should not become permanent simply because they were once deployed. Their performance, usage, cost, quality, and risk posture need periodic review. Some will justify further investment. Others should be redesigned, restricted, or retired. An inventory gives organisations the evidence to make those decisions deliberately.
SAP LeanIX is relevant because it approaches agent governance as an enterprise-architecture problem. Its AI Agent Hub is designed to help organisations discover, manage, and govern AI agents within the context of their broader technology landscape. SAP positions its broader AI Agent Hub as a vendor-agnostic command centre for discovering and governing agents, large language models, and MCP servers across the enterprise.
This matters because AI agents do not operate in isolation. They sit within business capabilities, applications, integrations, data domains, security controls, and technology standards. A governance tool that only lists agents without connecting them to this architecture context will not reveal the full risk or value of the landscape.
SAP LeanIX has also introduced an Enterprise Architecture Assistant that is grounded in an organisation’s inventory, architecture decisions, and connected sources. It can help architecture teams retrieve information, investigate dependencies, and draft transformation decisions without first assembling evidence manually. SAP LeanIX’s MCP Server extends this approach by allowing external AI tools, including Joule and Copilot, to access enterprise-architecture data through a governed protocol.
These capabilities do not replace architectural judgement. They make the underlying architecture information more usable at the speed AI programmes now require.
The best first step is not a company-wide policy document. It is a focused inventory exercise around the agents that already have meaningful reach.
Begin by identifying agents with access to sensitive data, customer-facing interactions, financial processes, critical operational systems, or production environments. Document their purpose, owner, permissions, and dependencies. Then classify them by impact and autonomy. A useful distinction is between agents that inform, agents that recommend, agents that prepare actions for approval, and agents that execute actions.
Next, define the minimum governance evidence required at each level. Higher autonomy and impact should result in stronger requirements for testing, monitoring, approval, logging, and incident response. This creates a pragmatic path that lets low-risk innovation continue while ensuring that more consequential agents receive proper oversight.
Finally, integrate the inventory with existing architecture, security, identity, data-governance, and change-management practices. AI governance cannot live in a separate spreadsheet owned by one innovation team. It needs to become part of how the organisation manages its technology estate.
Agentic AI can create real business value, but value does not scale safely without visibility. The organisations that succeed will not be those that deploy the most agents first. They will be those that can see their agent landscape, connect it to business and technical context, govern access and accountability, and learn from how agents perform over time.
An AI agent inventory is the foundation for doing that. It gives enterprise architecture a practical role in the AI era: not slowing experimentation, but giving the organisation enough structure to turn promising experiments into durable, trustworthy capabilities.
AI is only as useful as the business context behind it. SAP Business Data Cloud is SAP’
When evaluating an SAP S/4HANA migration, most organizations fixate on the software lic
The champagne has been popped, the project team is celebrating, and the new SAP S/4HANA