Managing AI agent sprawl across business units

As organizations scale their deployment of AI agents, there is siloed development of agents across independent business units. Each business unit (BU) builds its own agents for procurement, scheduling, reporting, and data pipelines, unaware that another team has already solved the same problem. Similarly, many software platforms now include their own agents for customer relationship management, service desk, and contact center operations, many enabled by default. The result is agent sprawl: duplicated capabilities, conflicting actions on shared systems, credential proliferation, and costs hidden within individual BU budgets. Without coordinated governance, the consequences are already visible: silent data corruption across organizational boundaries, hidden cost aggregation that makes each BU look fine while the enterprise overspends, and compliance violations when agent’s cross regulatory boundaries undetected.

This blog introduces a governance framework designed for organizations with multiple business units that need to enable fast agent development while maintaining enterprise-wide visibility, cost control, and safety.

In this blog, we cover how organizations with multiple business units amplify agent sprawl and present a federated governance framework to counter it. The framework combines a hub-and-spoke operating model, eight governance functions with clear ownership, risk-based agent classification, structured lifecycle management, a maturity progression model, and a 90-day plan for establishing the foundation.

How organizations with multiple business units amplify agent sprawl

In a single-team organization, agent sprawl is manageable, duplication is caught informally, and cost attribution is straightforward. In multi-business-unit organizations, these natural checks disappear. Each BU operates with its own budget, technology team, and priorities. When multiple business units adopt AI agents simultaneously, they typically encounter five sprawl patterns:

Sprawl Pattern	What Happens	Mitigation
Duplication across BUs	Each BU builds its own version of common agents (procurement, scheduling, reporting) without visibility into what others have built	Centralized agent registry with semantic search: discover before you build
Cross BU data conflicts	An agent in BU-A writes to a shared system; agent in BU-B reads stale data and acts on it. Neither team knows the other exists	Agent aware transaction boundaries with cross-boundary conflict detection
Hidden cost aggregation	Per BU costs look manageable; aggregated across 5+ BUs, the enterprise can overspend.	Enterprise cost dashboards with BU-tagged attribution and budget alerts
Shadow agent proliferation	Slow central approval → BU teams build unsanctioned agents independently; multiplies geometrically across BUs	Self-service deployment on approved infrastructure, making the governed path faster
Compliance fragmentation	Different BUs operate under different regulatory regimes (defense vs. commercial, International Traffic in Arms Regulations (ITAR) vs. public); agents crossing boundaries create violations	Centrally defined data boundary policies with infrastructure level enforcement

Self-service agents still require registry entry, documented ownership, and measurable usage, the difference is they don’t require cross BU review or council approval before deployment.

Self-service first: A federated governance model for agents

Organizations are finding success with a self-service-first governance model using a hub-and-spoke structure.

The hub – A central AI Governance Council sets enterprise-wide standards, maintains the shared agent registry, and defines minimum security and compliance baselines. The council is accountable for enterprise-wide visibility and cross-business-unit coordination.

The spoke – Each business unit designates an Agent Governance Lead who participates in the council and is accountable for compliance within their BU. Distributed teams build, deploy, and operate agents at their own pace within governed guardrails.

The primary objective of the central team is to make the governed path faster than the ungoverned workaround. If the governed path is slower, teams will build around it, and shadow agents will proliferate.

Where organizational readiness requires it, a more centralized implementation serves as the starting point. For most multi-BU organizations with diverse agent portfolios, centralization serves as a transitional state. Organizations operating under strict regulatory requirements (ITAR, HIPAA, financial compliance) may retain centralized governance as a permanent operating model where risk profiles demand it.

When to choose self-service vs. centrally governed

The boundary between self-service agents and centrally governed agents is where most organizations need clarity. The following decision criteria help classify which path an agent follows:

Attribute	Self-service	Centrally governed
Data access	Reads and writes within a single business unit’s boundary	Accesses data across business units or shared systems
Blast radius	Failure affects only the owning team	Failure affects other business units or external stakeholders
Regulatory exposure	Internal operations only	Subject to ITAR, export control, safety certification, or customer-facing compliance
Approval path	Auto registered on approved platform	Requires governance council review
Human oversight	Monitoring and intervention available	Human-in-the-loop for consequential actions

Decision criteria: If the agent can modify data outside its own business unit’s boundary, or if failure could affect another BU or an external stakeholder, it requires central governance. If the agent operates entirely within one team’s scope with no cross-boundary effects, it can be self-service.

Accountability: who owns what

The framework assigns ownership across eight functions. The following table describes the responsibilities of the central governance council and each business unit’s Agent Governance Lead:

Function	Central Governance Council	BU Agent Governance Lead
Agent registry	Owns enterprise registry. Enforces mandatory registration. Periodic cross-BU redundancy audits.	Ensures BU agents are registered and properly scoped. Searches before building. Conducts lifecycle reviews.
Identity and access	Identity and Access Management (IAM) policy standards. Identity provisioning. Enterprise kill switch.	Requests identities. Scopes permission per agent. Tags with BU identifiers for cost attribution.
Guardrails and safety	Non-negotiable security and compliance baselines. Infrastructure-layer enforcement.	Agent-specific rules within approved boundaries. Use case level risk assessment
Observability	Shared observability infrastructure. Enterprise dashboards. Anomaly detection.	BU specific views and alerts. Monitors own agents. Investigates BU level incidents
Cost governance	Enterprise-wide cost dashboards. BU-tagged attribution. Identifies sprawl patterns across BUs.	Manages agent portfolio as a cost center. Per-agent ROI justification
Compliance and audit	Cross BU data boundary policies. Enterprise audits. Regulatory mappings.	BU level compliance. Maintains audit trails within a regulatory context
Incident response	Kill switch for enterprise-risk events. Cross BU coordination.	First responder for BU specific incidents. Escalates cross-boundary events to council
AgentOps standards	Shared Continuous Integration / Continuous Delivery (CI/CD) pipeline templates. Agent quality standards. Evaluation frameworks.	Operates own deployment pipelines within central standards

Figure 1: Governance Platform Architecture

Classifying agents: governance scales with risk

Not all agents require the same governance overhead. Applying uniform controls across all agents leads to either unnecessary friction for low risk use cases or inadequate governance for high-risk ones. The framework uses a four-tier classification that maps to your organization’s existing risk and compliance taxonomy:

Tier 1 — Safety-critical or customer-facing: Full central governance, human-in-the-loop, formal certification, continuous monitoring. Examples: production systems that affect physical operations, regulatory submissions, customer-facing interactions.

Tier 2 — Cross-business-unit or shared data: Central standards required, cross BU data access review, no implicit trust between BU agents. Examples: supply chain orchestration, shared analytics, cross BU reporting.

Tier 3 — Business-unit-internal: BU governs within central guardrails, standard registry and observability, periodic central review. Examples: BU specific workflow automation, team scheduling, internal process agents.

Tier 4 — Personal productivity: Self-serve on approved platform, auto-registered, no write access to shared systems. Examples: individual assistants, document summarization, drafting, code assistance.

Classification criteria depend on your organization’s specific regulatory requirements. Map these tiers to your existing risk taxonomy while recognizing that classification can shift as agents evolve; for example, an agent that gains cross-boundary data access moves up a tier.

Note: Classification should account for both scope (the framework above) and autonomy level. An agent’s governance requirement is a function of blast radius x degree of autonomy, a high-autonomy agent within a single BU may require more governance than a low-autonomy agent crossing BU boundaries.

Agent lifecycle management

Every agent follows a defined lifecycle with clear ownership at each stage

Figure 2: Agent Lifecycle Management

Selecting the right implementation pattern

At development time, teams must select the appropriate implementation pattern for their use case. This decision has significant cost and governance implications:

MCP (Model Context Protocol) server — Expose structured, deterministic tool responses via the MCP protocol. The agent reasons about when to call the tool, but the tool itself returns predictable, auditable results. Use when the operation is a known, bounded function (retrieve data, execute a transaction, return structured output).
Tool and function integrations — For domain specific logic with bounded variability. The agent invokes specific tools within defined parameters.
Full agentic orchestration — For complex reasoning requiring multi-step judgment. Most expensive, hardest to govern, but necessary for genuinely complex tasks.

The interoperability landscape is maturing around established protocols (MCP for tool connectivity, Agent-to-Agent (A2A) for agent coordination). Pattern choices should align with the protocols your platform supports.

Choosing the simplest pattern that meets the use case prevents cost sprawl and improves reliability. If every team defaults to full agent orchestration when an MCP server would suffice, the organization burns tokens and creates unnecessary governance overhead.

Planned retirement

Agents must have a planned retirement path. The governance council triggers periodic lifecycle reviews; the agent’s named owner executes retirement decisions for agents with low utilization, outdated logic, or redundant capabilities. Without active lifecycle management, agent populations grow and sprawl compounds over time.

Preventing duplication: discover before you build

The biggest cost driver in multi-business-unit agent sprawl is multiple teams independently building the same agent. The framework enforces a discovery before you build pattern.

Before starting any new agent development, teams search the central agent marketplace for existing capabilities. The governance council conducts periodic cross-business unit audits to identify cases where multiple business units have independently built agents serving similar functions and facilitate the consolidation or shared-service arrangements. Where regulatory or data boundaries prevent sharing, teams build separately but on common patterns, shared CI/CD pipeline templates, and shared evaluation frameworks. This prevents fragmentation while respecting legitimate boundary constraints.

Platform maturity: pace with readiness

A managed agent harness eliminates infrastructure plumbing, so teams don’t have to build each agent’s runtime from scratch. Teams declare what the agent does: the model, tools, and instructions. The platform handles compute, sandboxing, identity, observability, and tool connectivity. This makes the governed path faster by default: building on the platform is easier than building around it.

Governance investment should pace with organizational readiness

The following table covers how the governance framework maps to a managed agent platform where the central governance council sets standards, the platform layer enforces them through infrastructure, and each business unit operates autonomously within those guardrails.

Phase	Platform capabilities	Governance model
Initial	Model routing layer, basic guardrails, single agent patterns, sandbox environments	Centralized: registry, identity, guardrails
Repeatable	CI/CD pipelines, observability, agent marketplace, cost tracking	Responsibility assignment matrix is established, cost attribution, shadow discovery
Reliable	Full AgentOps, evaluations, self-service platform	Hybrid: BUs self-serve Tier 3 & 4. Decentralization criteria applied
Scalable	Multi-agent orchestration, enterprise marketplace, autonomous digital employees	Full self-service. Central audit only. Automated governance

Designing for evolving ownership

Treat any centralized control as a transitional state. The governance model should intentionally shift as business units build capability: centrally gated, then centrally monitored with BU execution, then BU owned with central audit.

Considerations for evaluating readiness may include two or more quarters without critical incidents, a greater than 90 percent agent registration rate, a dedicated governance lead, consistent per agent cost tracking, and successful completion of an enterprise governance review.

Figure 3: Getting Started – First 90 days

Conclusion

Organizations with multiple business units are already experiencing agent sprawl. The framework in this post gives them a way to move fast with AI agents while maintaining visibility, preventing duplication, and controlling costs across the enterprise. Governance should make teams faster, not slower.

Start with an inventory. Stand up a registry. Make the platform the fastest way to build. Then progressively hand ownership to business units as they prove readiness.

In a future post, we’ll cover the implementation layer in detail, operational controls, distributed tracing across multi-agent orchestration, BU cost attribution patterns, and identity management for non-human agents operating across regulatory boundaries.

AWS for Industries