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.
To learn more, see:
- Governing and Architecting Agentic AI at Scale — AWS Prescriptive Guidance
- AWS Agent Registry in AgentCore — Centralized agent discovery and governance
- Agentic AI Lens — AWS Well-Architected
- A governance framework for building trustworthy agentic AI for public sector and regulated organizations — Companion framework covering security controls