The question of how to organise an agentic AI programme is not, at its root, a technology question. It is an authority question: who decides what an agent is allowed to do, and who is accountable when it does something it should not? The operating model is the answer. Three models have emerged in enterprise practice — the Center of Excellence, hub-and-spoke, and federated — each embodying a different answer to the authority question, and each making a different set of trade-offs between speed, safety, and scale.
The Center of Excellence
In a Center of Excellence model, a central team owns the agent platform, the policy stack, the evals framework, and the vendor relationships. Business units bring use cases to the CoE; the CoE assesses, builds, deploys, and operates them. The authority structure is clear: the CoE says yes or no, and its no is final. This model produces the most consistent governance outcomes and the fastest accumulation of institutional knowledge. It also produces the most friction, the longest queues, and the most frustrated business units.
The CoE model is appropriate in three situations: the organisation is early in its maturity journey (L1–L2 overall); the risk profile is high (financial services, healthcare, critical infrastructure); or the organisation has a history of decentralised technology decisions producing expensive inconsistencies. The CoE is the right answer when the cost of a governance failure outweighs the cost of a slower deployment cycle.
MIT CISR research on enterprise technology governance consistently finds that organisations with high levels of IT centralisation make more consistent risk decisions and worse innovation decisions. The CoE for agentic AI inherits this trade-off. Its job is not to maximise agent deployments; it is to maximise the quality of agent deployments — a subtly different brief.
Hub-and-spoke
The hub-and-spoke model distributes execution while centralising standards. The hub — typically the CoE or a platform engineering team — owns the architecture, the policy templates, the identity infrastructure, and the evals platform. The spokes — business unit AI teams, often called guilds or chapters — own the use-case selection, the domain data, and the day-to-day operation of agents within their business unit. The hub sets the floor; the spokes build above it.
This is the model most enterprises at L3–L4 maturity gravitate toward, because it balances the competing pressures well. Business units move at the speed their domain demands. The hub maintains the institutional knowledge and prevents the fragmentation that kills federated models. The authority is shared: the spoke cannot override the hub's security controls, but the hub cannot block a deployment that meets the standard. Gartner's TRiSM framework recommends a hub-and-spoke structure as the target state for enterprise AI governance at scale.
"The hub does not tell the spokes what to build. The hub tells the spokes what they must never skip — and then gets out of the way." — observed at multiple enterprise AI governance workshops, 2024–2025.
The federated model
In a federated model, business units own their agent programmes end-to-end: policy, architecture, evals, vendor selection, and operation. A corporate AI policy exists, but it is implemented differently in each business unit, and there is no central authority with the power to halt a deployment. The federated model moves fast and breaks things — not metaphorically, but literally, because the absence of a shared standard means each business unit learns the same lessons independently and pays for the same mistakes independently.
Federated is the model that emerges when no one makes the hub-and-spoke decision: it is the default, not a choice. Most organisations that describe themselves as federated are organisations that did not have a CoE early enough. The federated model can work at high maturity — if every business unit is genuinely at L4 or L5 across all four pillars — but reaching that state through federation takes significantly longer than reaching it through a hub-and-spoke with a strong hub.
Staffing the hub
A hub-and-spoke model is only as good as its hub. A hub of two people managing an estate of thirty agents across eight business units is not a hub; it is a bottleneck. The staffing model for a functional hub scales with the number of agents in production and the number of business units it serves. At a minimum: an AI governance lead (policy, risk, regulatory liaison); a platform engineer (the orchestration layer, the evals platform, the identity infrastructure); and an evals lead (the test library, the red-team schedule, the incident post-mortem process). Below this minimum, the hub cannot perform its functions; above it, additional roles follow the pattern described in Chapter 35.
The most important staffing decision for the hub is not the technical roles — those are relatively straightforward to recruit for — but the governance lead. This person must be fluent in both the technology and the regulatory landscape, comfortable saying no to a business unit under commercial pressure, and trusted enough by the technical team to be heard when they identify a risk. Finding this person is the single most important hiring decision in the first year of the programme.
The operating model over time
Operating models evolve. Most organisations start with a CoE by necessity (small estate, high risk, need for consistency) and migrate toward hub-and-spoke as the estate grows and the business units develop their own AI capability. A few reach a state of informed federation — business units with genuine L4+ maturity operating largely independently within a thin corporate standard — but this takes years and requires sustained investment in capability building at the spoke level.
The operating model decision should be reviewed annually, as part of the annual Scorecard review. An organisation that chose a CoE in year one because it was at L1–L2 may be ready for hub-and-spoke in year two. An organisation that went hub-and-spoke too early and found its spokes drifting may need to tighten the hub's authority for a period before loosening it again. The operating model is not a one-time architectural decision; it is a governance posture that is calibrated continuously against the maturity evidence.