An enterprise AI operating model is the decision about who owns AI agents and automation — a central team, the individual business functions, or a split — and specifically who holds decision rights over what gets built, what guardrails apply, and who supports it afterwards.
Every company answering “should AI be centralized?” is really answering four separate questions at once, which is why the debate goes in circles. Who decides what gets built. Who sets the rules. Who pays. Who fixes it at 4pm on a Friday.
Those four do not have to land in the same place, and the good operating models are the ones that split them deliberately rather than by accident.
What centralizing actually gets you, and costs you
Centralized means a single team builds and owns AI agents on behalf of the business. It buys consistency and it costs throughput.
The genuine wins are real: one set of standards, no duplicated work, a small group who get good at this fast, and a clear place for security to talk to. For a company with a handful of high-stakes workflows, that is often exactly right.
The cost is a queue. Every request from every function lands on one team’s backlog, and the business learns that AI is something you file a ticket for. The predictable result is that the teams with the most urgent problems route around it — which is how shadow AI starts, and it starts fastest in the companies with the strictest central control.
What federating gets you, and costs you
Federated means each business function builds what it needs. It buys throughput and it costs coherence.
When a finance analyst can build the agent they need on Tuesday, the work that actually gets automated is the work that actually hurts — which is knowledge no central team has. Adoption in a federated model is faster by a wide margin, because the person with the problem is the person building.
The cost shows up around month four. Four teams have built near-identical agents. Nobody can say how many exist. An agent someone built in March is still running in September and its author has changed jobs. None of that is a modelling problem; it is an inventory problem, and it is what lifecycle management exists to prevent.
Split the four questions
The workable answer is not a midpoint. It is assigning each question to whoever is genuinely best placed.
What gets built — federated. The business function knows which work is painful. Centralizing this decision is what creates the queue, and it is the one most worth pushing out.
What the guardrails are — central. Access scope, when a human must approve, how sources are grounded and cited, who is named owner. These should be few, and they should be defaults in the platform rather than policies in a document. In Insulin, scope is the boundary — an agent reaches only the integrations it is granted — and consequential actions run through approval, which means the guardrail holds whoever built the agent.
Who pays — federated, visibly. When the function that benefits sees the cost, the prioritization is self-correcting. Central budgets hide the trade-off and produce agents nobody would have funded. See spend governance.
Who supports it — central for the platform, federated for the agent. The platform team owns availability, integrations and access. The building team owns whether their agent still does the right thing. Confusing these two is why so many agents end up unowned.
The thing that makes federation safe
Reuse is what stops federation becoming sprawl. Without it, forty teams building independently produce forty solutions to eight problems.
The mechanism is a curated internal catalog: when a team builds something genuinely good, it gets published so the next four teams install it rather than rebuild it. That is what the agent marketplace is for, and it is the difference between federation and chaos. The curation itself is a central job — which is the most valuable thing a central team can be doing, and a far better use of it than being a build queue. That is the shape a functioning center of excellence takes.
Choosing for where you are
Small AI footprint, high stakes, few workflows: start centralized. You do not have a throughput problem yet, and consistency is cheap to get early.
Many functions with their own pressing problems: federate the building immediately, and put the guardrails in the platform before you do, not after. Retrofitting scope and approval onto agents that already exist is materially harder than starting with them.
Most companies past the pilot stage want the split above. The failure to avoid is picking one pole and defending it — a central team defending its queue while the business routes around it, or a federated free-for-all with no inventory.
Frequently asked questions
What is an enterprise AI operating model? The decision about who owns AI agents and automation — who decides what gets built, who sets the guardrails, who funds it, and who supports it. Those four questions can be answered differently.
Should AI agents be centralized or federated? Usually split. Federate what gets built and who pays; centralize the guardrails and platform support. Picking one pole produces either a queue the business routes around, or sprawl nobody can inventory.
What is the risk of centralizing everything? A queue. Every function’s request lands on one backlog, and the teams with the most urgent problems go around it — which is how shadow AI starts, fastest in the strictest organizations.
What is the risk of federating everything? Duplication and orphaned agents. By month four several teams have built near-identical agents, nobody knows how many exist, and some are still running after their author changed roles.
What makes federation safe? Guardrails as platform defaults rather than policy documents, plus a curated catalog so good work gets installed rather than rebuilt. Curation is the highest-value job a central team can do.
Takeaways
- “Centralize or federate” is four questions: what gets built, what the guardrails are, who pays, and who supports it.
- Federate what gets built and who pays — the function with the problem knows the work and self-corrects on cost.
- Centralize the guardrails, and make them platform defaults (scope, approval, grounding, named owner) rather than a policy document.
- Split support: the platform team owns availability and access; the building team owns whether its agent still does the right thing.
- Curated reuse is what keeps federation from becoming sprawl — and curating is a better central job than being a build queue.
Put the guardrails in the platform: see how agents are scoped and approved, and what the agent marketplace makes reusable — or book a demo.
Sources
Primary sources for the platform rules cited above. Last verified August 27, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger docs: Insulin agents — Agent scoping and approval behaviour — the platform-level guardrails referenced in the hybrid model.
Keep reading
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.