{"slug": "the-agentic-operating-model-and-oversight-that-scales-governance-for-ai-agents", "title": "The Agentic Operating Model and Oversight That Scales: Governance for AI Agents", "summary": "UC Berkeley Haas research in the California Management Review proposes the Agentic Operating Model (AOM), a four-layer framework (Cognitive, Coordination, Control, Governance) to make AI agents governable and accountable at scale, warning that traditional tool-era governance fails because agents act as organizational actors. AWS's public-sector guidance operationalizes the model with six security dimensions, including identity context and agency boundaries, while acknowledging that neither hub-and-spoke nor swarm orchestration is inherently safer without embedded governance.", "body_md": "Agents that plan, call tools and execute tasks are being pitched as the next capability leap, and the familiar governance instinct is to treat them like any other tool: add approvals, guardrails and human checkpoints, then scale.\n\nThat instinct breaks because an agent that plans and executes behaves like an organisational actor rather than a tool you operate. Governance built around humans doing the work no longer fits, and oversight fragments across competing frameworks with no single synthesis.\n\nWithout a coherent model you are left choosing between accountability bottlenecks and ungoverned autonomy, and neither scales past a pilot. This article rebuilds governance for the actor era, one thread in [the wider governance picture](/enterprise-ai-governance-and-the-control-framework-gap).\n\n## What is the Agentic Operating Model (AOM), and what are its four layers?\n\nThe Agentic Operating Model (AOM) is the organisational wrapper that turns raw agent capability into governed, accountable capability. Research in the [California Management Review](https://cmr.berkeley.edu/2026/03/governing-the-agentic-enterprise-a-new-operating-model-for-autonomous-ai-at-scale/) from UC Berkeley Haas frames it as four layers: Cognitive, Coordination, Control and Governance. AWS’s public-sector guidance operationalises the same idea through [Amazon Bedrock guardrails](https://aws.amazon.com/blogs/publicsector/a-governance-framework-for-building-trustworthy-agentic-ai-for-public-sector-and-regulated-organizations/), IAM and Step Functions.\n\nThe paper reframes autonomous AI as an institutional design problem and asks how agents can be made governable.\n\n### The four layers, defined\n\n**Cognitive layer**: how intelligence is instantiated. The AOM favours multiple specialised, domain-specific models over one general model, because specialisation makes accountability tractable and lets you attribute unit costs per function.**Coordination layer**: how agents interact. This is where the Orchestration Gap appears, the point where decentralised software outpaces centralised human management.[MCP](https://modelcontextprotocol.io)connects an agent to tools and data; the[Agent2Agent protocol](https://www.infoq.com/news/2025/07/agent2agent-linux-foundation/)handles agent-to-agent communication.[They are complementary](https://www.truefoundry.com/blog/mcp-vs-a2a).**Control layer**: how behaviour is bounded in real time through confidence thresholds, behavioural baselines and guardrail agents rather than static permissions.**Governance layer**: how accountability is anchored. Every agent has a named business owner, a risk profile and documented decision boundaries, otherwise agents become organisational orphans.\n\nAWS’s public-sector guidance attaches six security dimensions to the model as control surfaces: identity context; data, memory and state protection; audit and logging; agent and foundation model controls; agency boundaries and policies; and orchestration.\n\nHub-and-spoke orchestration is easier to audit at low scale but becomes a bottleneck and a single point of failure. A decentralised swarm (swarm intelligence or the agentic mesh) removes the bottleneck but demands stronger local rules, consensus mechanisms and shared goals. Neither is inherently safer; safety comes from embedding governance in whichever pattern you choose.\n\nOne caveat: the model only matters once it is deployed with enforceable controls. The AOM fills the governance control framework gap left by tool-era controls and closes the gap that [agentic AI widens](/why-agentic-ai-widens-the-ai-governance-control-framework-gap). Skip the operating model and your pilots [rarely reach production](/why-most-enterprise-ai-agent-pilots-fail-to-reach-production).\n\n## What is the difference between Human-in-the-Loop and Human-on-the-Loop oversight, and which scales for AI agents?\n\nThe Control and Governance layers raise the immediate practical question: where does the human sit while the agent acts? Human-in-the-Loop (HITL) requires a human to approve each consequential action before it runs. [Human-on-the-Loop (HOTL)](https://en.wikipedia.org/wiki/Human-in-the-loop) lets agents act within pre-set bounds while humans monitor and intervene by exception. HOTL scales and HITL does not, because per-action approval becomes a bottleneck as volumes climb.\n\nHITL maps to Scope 2 (human approves each action), where it is manageable when actions are few. Approval-per-action makes the human approver a single dependency, with [headcount growing alongside workload](https://nuvento.com/blogs/the-hidden-cost-of-human-in-the-loop-ai-nuvento/). A single agent performing [1,000 or more actions an hour](https://galileo.ai/blog/ai-agent-guardrails-framework) makes comprehensive review untenable, which is why tiered review has become the standard response: automated checks for low-risk actions, human review only for high-impact decisions.\n\nHOTL moves oversight to behavioural baselines, confidence thresholds and escalation design. Humans stay in the lead by defining objectives, constraints and escalation thresholds while agents operate within those boundaries. Oversight becomes supervision by exception.\n\n[Escalation is where the design work happens](https://www.uipath.com/blog/ai/agent-ops-operationalizing-ai-agents-for-enterprise). Instead of approval gates, you predefine routes that surface an agent’s uncertainty with full context: what it attempted, why it is uncertain, and the options it recommends. A human then decides in seconds.\n\nThe decision rule for approval is [consequence, reversibility and novelty](https://www.okta.com/identity-101/how-to-implement-least-privilege-for-ai-agents/). Approval is required when consequence is high, the action is irreversible and the situation is novel. Autonomous execution is appropriate when consequence is low, the action is reversible and the task is routine. Everything in between is governed by escalation thresholds.\n\nConfidence thresholds and behavioural baselines let oversight recognise the rare action that needs a human instead of flagging every action. Thresholds vary by domain, and [multi-agent chains are kept more conservative](https://galileo.ai/blog/human-in-the-loop-agent-oversight) because uncertainty compounds. These routes also map onto the [human-oversight obligations](/what-the-eu-ai-act-requires-of-organisations-deploying-ai-agents) in the EU AI Act and onto the [runtime controls](/runtime-governance-versus-model-safety-for-ai-agents) that execute this model.\n\n## What are the four scope levels for classifying AI agent autonomy?\n\nProportionate oversight requires a way to classify how much autonomy any agent actually has, which is what [Scope 1 to 4](https://aws.amazon.com/blogs/security/agentic-ai-security-scoping-matrix/) provides. The four scopes are No Agency, Prescribed Agency, Supervised Agency and Full Agency.\n\n### The four scopes, defined\n\n**Scope 1, No Agency**: read-only and advisory. The agent recommends, the human decides.** Scope 2, Prescribed Agency**: the agent acts, but a human approves before execution.** Scope 3, Supervised Agency**: the agent acts autonomously within bounds while a human monitors by exception.** Scope 4, Full Agency**: continuous autonomy inside a defined domain, with humans governing goals and boundaries.\n\nClassification turns on an agent’s read/write reach, whether it can commit actions, the consequence and reversibility of those actions, the novelty of the task, and its confidence score against a behavioural baseline. The AWS Security Scoping Matrix is the practitioner-facing source, and the [Cloud Security Alliance extends it](https://cloudsecurityalliance.org/blog/2025/12/16/enhancing-the-agentic-ai-security-scoping-matrix-a-multi-dimensional-approach) into a finer grid.\n\n### Where Scope 2 ends and Scope 3 begins\n\nThe rule is that autonomy is earned per action, not granted per agent. If every state-modifying action requires a human to review and confirm, you are in Scope 2. If an action modifies state without a human explicitly approving that specific action, you are in Scope 3 or higher. That line is drawn by confidence thresholds and behavioural baselines: in-baseline, high-confidence actions execute, while the rest escalate.\n\nThat shift is [runtime governance](https://blogs.oracle.com/ai-and-datascience/runtime-governance-enterprise-agentic-ai/) in action: promotion-time governance decides whether an agent is eligible to run, while runtime governance decides whether the next action is allowed. Autonomy and data capability should be advanced one axis at a time, not both at once, so scope changes stay reversible. That fits with [measuring autonomy as an emergent property](https://www.anthropic.com/research/measuring-agent-autonomy) and feeds into how runtime governance executes the operating model.\n\n## Wrapping it all up\n\nAutonomy that scales is won by changing what humans do: from approving every action to setting objectives, constraints and escalation thresholds. The AOM’s four layers make that tractable.\n\nHOTL swaps per-action approval for supervision by exception, and Scope 1 to 4 makes governance proportionate, with the line between prescribed and supervised agency drawn by confidence thresholds and behavioural baselines. The result is accountability without a bottleneck, an outcome mapped across the complete cluster overview.\n\n## Frequently Asked Questions\n\n### How does the Agentic Operating Model differ from traditional IT governance?\n\nTraditional IT governance manages what humans do with software, so its controls sit around user permissions and change approvals. The AOM governs what autonomous agents decide and execute. It makes intelligence, coordination, control and accountability explicit layers rather than treating them as deployment details. This is the shift from governing a tool to governing an actor, and it is why bolting on approval gates stops working at scale.\n\n### Is the Agentic Operating Model only for large enterprises?\n\nNo. The research origin sits in a major business school journal and much vendor guidance presumes enterprise resourcing, but the model itself is a design pattern, not a headcount requirement. A small team can still name owners, set behavioural baselines and classify scope. What matters is making the four layers explicit before autonomy grows, not the size of the organisation applying them.\n\n### What is the Orchestration Gap, and why does it matter?\n\nThe Orchestration Gap is the point where decentralised software advances faster than centralised human management can direct it. As agents multiply, one person cannot coordinate thousands of interactions. The AOM’s Coordination layer closes this gap by governing how agents interact through protocols like MCP and Agent2Agent. Left open, the gap becomes a bottleneck that stalls autonomy past the pilot.\n\n### What happens when an agent breaches a behavioural baseline?\n\nThe action escalates. Rather than being approved silently or ignored, it is surfaced to a human through a predefined escalation route, with the reasoning trace, tool-call log, proposed action and affected system attached. The human then decides in seconds. If confidence drops or spend or rate limits are exceeded, the agent steps back from Scope 3 supervision to Scope 2 approval.\n\n### Is it true that more autonomy means less human oversight?\n\nNo. Autonomy that scales is won by changing what humans do, not by removing them. Human-on-the-Loop oversight keeps humans in the lead by setting objectives, constraints and escalation thresholds while agents act within those bounds. The difference is that humans supervise by exception against baselines rather than approving every action, so oversight becomes stronger and more targeted as autonomy grows.\n\n### Can an agent move between scope levels?\n\nYes, and it should. Autonomy is earned per action, not granted per agent. A high-confidence, in-baseline action executes under Scope 3 supervision, while a novel or low-confidence action escalates to Scope 2 approval. Scope is therefore a live control decision made against confidence thresholds and behavioural baselines, not a fixed label assigned once at deployment.\n\n### Do I need a separate specialised model for every function?\n\nThe Cognitive layer favours multiple specialised, domain-specific models over one general model, but that does not mean a model per task. It means matching model choice to function so accountability is tractable, generality risk is reduced and unit-cost attribution is possible. Some teams group related functions under one specialised model. The principle is purposeful specialisation, not uncontrolled proliferation.\n\n### How do confidence thresholds actually work in practice?\n\nA confidence threshold is a pre-set point below which an agent no longer acts autonomously. When a model’s confidence in an action falls beneath that threshold, the action escalates to a human with full context rather than executing. Combined with behavioural baselines such as spend and rate limits, thresholds let oversight recognise the rare action that genuinely needs a human instead of flagging every action.\n\n### What is the difference between model safety and runtime governance?\n\nModel safety concerns the model itself, its training, alignment and refusal behaviour. Runtime governance concerns what the agent does in operation: the Control layer’s real-time bounds, escalation paths and behavioural baselines. Both are necessary. A safe model can still be steered into a harmful action sequence, which is why the AOM places runtime control and named accountability alongside model selection.\n\n### How does the EU AI Act fit with the Agentic Operating Model?\n\nThe EU AI Act imposes human-oversight obligations that map to the AOM’s oversight model. Human-on-the-Loop supervision by exception, predefined escalation routes and documented decision boundaries all help demonstrate the required human oversight over high-risk deployments. Scope classification then matches controls to capability and impact, giving an organisation a defensible, proportionate response rather than a checkbox.\n\n### What does “autonomy is earned per action, not granted per agent” mean?\n\nIt means you do not give an agent a fixed autonomy level and walk away. Each action is evaluated on its own merits, its confidence score against a behavioural baseline, and its consequence, reversibility and novelty. Actions that stay in-baseline and high-confidence execute autonomously; everything else escalates. This keeps autonomy proportionate and reversible at the level where risk actually lives.\n\n### Should I choose centralised orchestration or a decentralised swarm?\n\nNeither is inherently safer. Centralised hub-and-spoke orchestration is easier to audit at low scale but becomes a single point of failure and a bottleneck. A decentralised swarm removes that bottleneck but demands stronger local rules, consensus mechanisms and shared goals. Safety comes from embedding governance in whichever pattern you choose, not from the topology itself.", "url": "https://wpnews.pro/news/the-agentic-operating-model-and-oversight-that-scales-governance-for-ai-agents", "canonical_source": "https://www.softwareseni.com/the-agentic-operating-model-and-oversight-that-scales/", "published_at": "2026-08-18 16:00:00+00:00", "updated_at": "2026-08-19 03:42:23.334978+00:00", "lang": "en", "topics": ["ai-agents", "ai-policy", "ai-safety"], "entities": ["UC Berkeley Haas", "California Management Review", "AWS", "Amazon Bedrock", "MCP", "Agent2Agent protocol", "Linux Foundation"], "alternates": {"html": "https://wpnews.pro/news/the-agentic-operating-model-and-oversight-that-scales-governance-for-ai-agents", "markdown": "https://wpnews.pro/news/the-agentic-operating-model-and-oversight-that-scales-governance-for-ai-agents.md", "text": "https://wpnews.pro/news/the-agentic-operating-model-and-oversight-that-scales-governance-for-ai-agents.txt", "jsonld": "https://wpnews.pro/news/the-agentic-operating-model-and-oversight-that-scales-governance-for-ai-agents.jsonld"}}