- Home
- AI agents
- Governance and regulation
- Operating model and maturity
Govern and secure · Governance and regulation
What is an agentic AI operating model, and how do you measure maturity?
An agentic AI operating model sets who may build, approve, run and retire AI agents, and which shared platform they build on. A maturity model describes the stages a company moves through, from scattered pilots to a governed fleet, so leaders can see which control is missing before they add more agents.
In this guide: 83 pages
Key takeaways
- Write down decision rights before you draw an org chart: who approves an agent for production, who can switch it off without asking, who answers for its output and who pays for its tokens.
- We recommend hub and spoke for most enterprises. A central platform team owns identity, the tool gateway, the registry, telemetry and the evaluation harness; business teams own the agents and their results.
- Reuse the three lines of defence your risk function already runs: builders and business owners first, risk and compliance second, internal audit third. SR 26-2 describes the same split for models, with internal audit judging whether the practice works instead of repeating it.
- The five maturity levels on this page are our working model and no published standard. Each level adds one kind of control and comes with a test you can run without new tooling.
- Regulators already ask for parts of it. MAS expects board oversight of AI risk, with identification, inventory and risk materiality assessment due within 12 months of 7 Oct 2026 and full implementation within 24; EU AI Act Article 26(2) asks for oversight by people with the competence, training and authority to act, and Singapore’s IMDA asks firms to check that human oversight stays effective over time.
Who owns what in an agent operating model?
Six roles carry an agent programme: the business owner, the agent owner who builds and runs it, the platform team, risk and compliance, security and internal audit. The table gives each recurring decision one accountable role, which is the step most programmes skip.
Decision rights for an agent programme. One accountable role per row; adjust the names to your organisation.
| Decision or task | Accountable | Does the work | Consulted |
|---|---|---|---|
| Approve the use case and its risk tier | Business owner | Agent owner | Risk and compliance, security |
| Build, test and document the agent | Agent owner | Agent owner’s team | Platform team |
| Run the evaluation that gates release | Validation lead, named before release | Evaluators outside the build team | Agent owner, risk and compliance |
| Publish to production | Platform team | Platform team, through the approval queue | Business owner |
| Watch runs, cost and quality | Agent owner | Agent owner, on platform dashboards | Platform team |
| Switch the agent off in an incident | Incident commander, named in the runbook | Platform team | Security, agent owner, business owner |
| Approve a model or major prompt change | Agent owner | Agent owner, with the regression suite | Risk and compliance for high tiers |
| Retire the agent | Business owner | Platform team | Agent owner |
| Check that the whole practice works | Internal audit | Internal audit | Everyone above |
Two rules make the table work. The person who can switch an agent off must never need the builder’s permission, and every agent needs a sponsor who outlasts its builder. Microsoft’s own practice deletes individually owned agents when the employee leaves, and Entra can transfer an agent’s sponsorship when the sponsor changes role or leaves.
Central team, federated or hub and spoke: which structure fits?
Hub and spoke fits most enterprises once more than a few teams build agents. A central team builds the foundation once and every business team builds on it; a fully central team turns into a queue, and fully federated teams rebuild identity, logging and evaluation in every department.
The hub owns what must be the same for every agent: one identity per agent, the tool gateway and its policies, the registry and approval queue, telemetry with content controls, the evaluation harness and the catalogue of approved models with pinned versions. The spokes own the use case, the instructions, the golden dataset and the result the business signed up for.
Fully central suits a few agents with high stakes, such as a regulated function where each agent touches customer money. Fully federated suits only low-risk personal agents, and even then the registry must reach them. On Microsoft, Power Platform environments and pipelines give hub and spoke a concrete shape: makers build in their own environments, and delegated deployments add an approval step and run the deployment as a service principal, so a customisation cannot bypass the QA environment or the approval process.
Watch the approval queue. A queue with no service level teaches makers to share agents directly instead, and Microsoft added a rule that auto-rejects requests older than a set number of days, which only helps if makers know about it. Publish the expected turnaround for each risk tier.
What are the maturity levels, and how do you test each one?
We use five levels, each defined by a control you can test instead of a sense of progress. Move up one level at a time, because measurement without identity and an off switch gives you dashboards about agents you cannot stop.
QueryNow’s five maturity levels for running AI agents, with the test for each level and the next control to add.
| Level | What exists | The test | Next control to add |
|---|---|---|---|
| 1 Ad hoc | Pilots and personal agents; nobody holds a full list | Ask three departments how many agents they run and compare the answers | Discovery and a registry |
| 2 Inventoried | A registry record and a named owner for every agent | Export the registry: no agent without an owner, every record with a risk tier | One identity per agent and an approval gate |
| 3 Controlled | Own identity, approval before publishing, a tested off switch per platform | Pick a production agent at random and switch it off; time it and note what kept running | An evaluation gate and online scoring |
| 4 Measured | Golden datasets, release gates, online evaluation, cost per use case | Show the evaluation result that approved the current version of three agents | Regression runs on every change and evidence from records |
| 5 Managed fleet | Every model, prompt and tool change runs the regression suite; audits work from records | Reconstruct one run from last quarter using only stored records | A quarterly review of retired agents and stale owners |
The Microsoft 365 admin center shows "Agents without owners" as a headline counter in its agent registry, so the level 2 test is a quick check for Microsoft 365 tenants. AWS and Google registries hold an owner or publisher field that you can export and count the same way.
Which numbers show that the operating model works?
Track a short list of ratios that only move when the operating model works, and report them per business unit so each spoke sees its own numbers.
- Ownership: the share of agents with a named owner, a sponsor and a current risk tier.
- Identity: the share of agents that run under their own identity instead of a shared account or a person’s token.
- Evaluation: the share of production versions that passed a recorded evaluation gate.
- Containment: the time to contain in the last off-switch drill, per platform.
- Change control: the share of model changes in the quarter that ran the regression suite before reaching production.
- Approval speed: the median time from approval request to decision, per risk tier.
- Retirement: the number of agents retired in the quarter, as a check that the list does more than grow.
Report ownership from level 2, identity and containment from level 3, and the rest, evaluation included, from level 4. Pull every number from the registry, the approval queue and the evaluation store, because a figure assembled by hand for the quarterly review tells you about the review and little about the agents.
How do Microsoft, AWS and Google implement it?
The platform pieces an operating model plugs into, as the vendor pages showed them on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Approval before an agent reaches users | Agent 365 Requests queue: Pending review, Pending update, Pending activate | AWS Agent Registry states DRAFT, PENDING_APPROVAL and APPROVED; only approved records are discoverable | Admin review of sharing requests in Gemini Enterprise |
| Environments and promotion | Power Platform pipelines with delegated deployments; immutable Foundry agent versions | AgentCore Runtime immutable versions and named endpoints | Agent Runtime revisions with traffic splitting, preview since 19 May 2026 |
| Fleet actions | Microsoft 365 agent management rules: bulk block, reassign the owner, apply a template | Registry deprecation; AgentCore Policy rules at the Gateway | Agent Gateway policy for registered agents and tools |
The approval states and fleet actions have different names on each cloud. Map each one to the decision rights in the first table before you write the runbook.
Frequently asked questions
Do we need an AI centre of excellence?
You need its functions more than its name: a platform team that owns the shared foundation, one standard for evaluation and approval, and someone who keeps the registry honest. Keep it small and run it as a service the business teams use; a review board that teams queue for pushes them to build around it.
Should IT or the business own AI agents?
Both, for different things. The business owns the use case, the outcome and the decision to keep or retire the agent. IT, through the platform team, owns identity, the gateway, telemetry and the off switch. An agent with only a business owner tends to run on borrowed credentials, and one with only an IT owner tends to have no measured outcome.
Where does a Chief AI Officer fit?
Above the hub, as the executive accountable for the AI policy and the risk appetite. US federal agencies must have one under OMB M-25-21. Elsewhere the title is optional, but ISO/IEC 42001 clause 5.1 asks top management to lead, and MAS expects board oversight of AI risk.
What should the platform team build first?
The registry with owners, one identity per agent, an approval gate before publishing and a tested off switch, in that order. Those four take every new agent to level 3, and each later control, from evaluation gates to audit evidence, reads from the registry record.
More in Governance and regulation
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Agent Registry in the Microsoft 365 admin center
- Agent requests
- Agent settings in the Microsoft 365 admin center
- Overview of pipelines in Power Platform
- Deploying Microsoft Agent 365 at Microsoft
- What’s new in Microsoft Entra Agent ID
- AWS Agent Registry record lifecycle
- Gemini Enterprise Agent Platform release notes
- Supervisory guidance on model risk management (SR 26-2 attachment)
- Guidelines on Artificial Intelligence Risk Management, response to feedback
- Model AI Governance Framework for Agentic AI, version 1.5
- EU AI Act, Article 26: Obligations of deployers of high-risk AI systems
- M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner