Do you need an agent centre of excellence?

When every business unit is exploring agents, a centre of excellence can look inevitable. It promises consistent standards, scarce expertise, shared tools and fewer duplicated mistakes. It can also become a presentation team, a central development factory or an approval queue that owns none of the outcomes it influences.

Do not begin with the box on the organisation chart. Begin with the repeated constraints that prevent workflow teams from making and operating good decisions. Create a centre only if concentrating capability is a better response than strengthening existing product, platform, risk or data functions.

Diagnose the coordination problem first

A central capability may be justified when several teams face the same problem:

• limited access to evaluation, security or agent-architecture specialists;
• inconsistent identity, logging, sandbox or model-access patterns;
• repeated procurement and supplier assessment;
• unclear risk classification and release evidence;
• duplicated test data and evaluation infrastructure;
• fragmented learning from pilots and incidents; or
• uneven ability to redesign work and support adoption.

These are service needs. Write them as outcomes for internal customers: “a workflow team can obtain a scoped evaluation design within five working days” is more useful than “promote AI best practice.”

The OECD describes structured experimentation as a way to build capability and manage risk before deployment (OECD). A central team can make that learning reusable, but only if it captures decisions, methods and observed results rather than collecting showcases.

Choose among three operating shapes

Centralized

One team owns specialist capability, common tooling and much of delivery. This can work when expertise is extremely scarce, the enterprise is early in adoption or infrastructure must be tightly controlled. It risks becoming a bottleneck and separating technical work from domain context.

Federated

Business or product teams hold most capability, connected through common standards and a community of practice. This supports local ownership and speed where teams are mature. It risks uneven controls, duplicated platforms and weak cross-enterprise learning.

Hub and spoke

A small hub owns reusable foundations, specialist challenge and portfolio learning; embedded spokes own workflows and delivery. This is often the useful target, but it requires clear interfaces. Without them, the hub is held accountable for work it cannot control while spokes assume the hub has approved everything.

The UK Nuclear Decommissioning Authority’s 2026 strategy describes a hub-and-spoke model intended to reduce fragmentation while preserving operating-company capability. The example is not a universal template; it illustrates that shared standards and local delivery need deliberate balance.

Give the centre a bounded service catalogue

Useful central services can include:

• workflow discovery and no-agent challenge;
• reference architecture and approved integration patterns;
• identity, tool gateway, telemetry and sandbox platforms;
• evaluation design, test harnesses and independent review;
• threat modelling and red-team support;
• data, privacy and impact assessment support;
• reusable procurement and supplier-assurance questions;
• release-evidence templates and decision facilitation;
• role-based learning and practitioner communities; and
• portfolio evidence, incident learning and watchlist maintenance.

For each service, name entry criteria, deliverable, response expectation, funding and the decision it supports. A centre that accepts any “AI request” will absorb work that belongs with product teams and become impossible to prioritise.

Publish the interfaces as product contracts. A workflow team requesting evaluation support should know what case data and decision criteria it must bring, what the centre will examine, and what remains the team’s responsibility. The centre should report demand, waiting time, completion, adoption and recurring failure demand. That evidence reveals whether to add capacity, improve self-service patterns or remove an unnecessary review. Internal customers should also have an escalation route when a central standard does not fit their context; consistency should not prevent evidence-based exceptions.

Keep workflow accountability outside the centre

The business or service owner should remain accountable for intended purpose, scope, benefits, affected people, operating performance and continuation. The centre may own platform controls or evaluation quality. It should not become the fictional owner of every downstream outcome.

NIST’s AI RMF requires clear roles, executive responsibility and contextual mapping across the lifecycle (AI RMF Core). Apply that separation:

• the centre defines a common risk-tiering method; the workflow owner supplies context and owns the use decision;
• the centre operates an evaluation platform; the workflow team defines real cases and acceptance conditions;
• the centre publishes an authorisation pattern; the business authority decides which actions may be delegated;
• the centre provides independent challenge; the authorised executive makes the release decision.

Write these interfaces down. “The centre reviewed it” should never be mistaken for an approval whose authority lies elsewhere.

Avoid the four centre traps

The innovation theatre trap

Success is counted as workshops, demos and ideas. Replace activity measures with service outcomes: decisions improved, duplicated effort removed, critical gaps found, reusable controls adopted and teams made self-sufficient.

The delivery-factory trap

The centre builds agents for functions that never develop ownership. Require an accountable workflow owner, operational participation and a post-launch team before accepting delivery work.

The policy-gateway trap

Every request waits for a central committee regardless of consequence. Use proportional pathways and pre-approved patterns for low-risk work, reserving deep specialist review for material uncertainty and impact. NIST advises prioritising risk resources according to context and consequence, not applying one undifferentiated burden.

The permanent-expert trap

The centre solves problems without transferring capability. Pair interventions with templates, coaching, communities, documentation and embedded practice. A repeated question should become a reusable service or a reason to improve the underlying platform.

Fund it as a capability, not a campaign

A central team needs a durable funding model. Pure chargeback can discourage early risk consultation and favour wealthy functions. Fully central funding can detach demand from value. A mixed model can fund common platforms, standards and assurance centrally while charging substantial workflow-specific delivery to the sponsoring function.

Capacity allocation should reflect enterprise priorities and consequences. Publish criteria. Keep room for incident response, emerging risk and small high-value experiments; otherwise the largest programmes will consume every specialist.

GAO’s AI accountability framework emphasizes governance, data, performance and monitoring (GAO). The centre’s own performance system should cover the same ground: clear mandate, controlled knowledge assets, outcome measures and monitoring of whether teams improve.

Review the centre like any other operating hypothesis

Set an initial review horizon and evidence questions:

• Are workflow teams reaching decisions faster without weaker challenge?
• Are common controls being adopted and operated successfully?
• Has duplicated infrastructure or assessment decreased?
• Do incidents and evaluations produce cross-portfolio learning?
• Are local teams becoming more capable?
• Where does the centre create waiting, ambiguity or shadow processes?
• Which services should move into platform, risk, procurement or product functions?

The GOV.UK discovery guidance treats stopping after discovery as a valid outcome when the evidence does not justify further investment. Use the same discipline here. The right answer may be a small virtual practice, an embedded specialist network or stronger existing teams—not a new institution.

A centre of excellence is useful when it concentrates learning and enables accountable delivery. It is harmful when centralization becomes a substitute for ownership. Choose the mandate, measures and interfaces first; name the structure last, and keep its authority proportionate to the service it actually provides.