AI Native Operating Model · Part 4 of 7
How to govern delivery when agents do a large share of the work.
Once an organisation has agreed where its delegation boundary sits, it needs to see whether work is progressing within those boundaries and where people need to intervene. Delivery dashboards worked well when people produced most of the work and set its pace. With agents handling a growing share of execution, the volume of activity no longer tells a leader much about whether delivery is on track.
Making every agent action visible does not resolve this. Traces accumulate, task counts rise and people still have to work out which events need their attention. The opposite approach leaves a different gap: agents run, validation passes and the interface stays green, while decisions and risks outside those checks remain invisible. A customer may be the first person to discover that something important was missed. Neither approach provides a reliable view of where human intervention is needed.
The control room is the part of an AI native operating model that provides that view. It shows which decisions require judgment, where work is waiting, what evidence supports completion and which risks have changed. It also records what completed work has contributed back to the system. Agent telemetry supports this, but the control room needs to connect it to missions, decision rights and acceptance conditions before it can guide how people spend their attention.
Why dashboards stop working at machine speed#
A conventional dashboard presents a fixed set of information at a level of detail chosen in advance. That worked well when the work and reporting needs were stable. In hybrid delivery, the same dashboard has to accommodate a growing volume of machine activity without burying the decisions that still require a person. Adding panels and drill-downs can expose more data, but it does not reduce the work of finding those decisions.
The missing information is often operational rather than technical. A trace can show that an agent stopped, but the person responsible still needs to know why it stopped, whether another mission depends on it and what a delay will cost. A dashboard built around execution data leaves them to assemble that context elsewhere. As more work runs in parallel, those investigations take an increasing share of the time available for making decisions.
Process control established explicit limits on how much an operator should be asked to handle. The alarm performance benchmarks in EEMUA 191 and ISA-18.2 say that fewer than one alarm per ten minutes per operating position is very likely to be acceptable. One per five minutes is considered manageable, while one per two minutes is likely to be over-demanding.1 Site reliability engineering reached a similar conclusion through a different calculation. Google's practice sets a ceiling of two incidents per twelve-hour on-call shift, because investigating an incident, finding its root cause, fixing it and writing the postmortem together take around six hours.2
Process control and site reliability set limits on demands for human attention. The agent platforms we reviewed state no equivalent.
Both fields work with an explicit attention budget. None of the agent platforms we have looked at states one, despite the evidence on what happens when automated work competes with other demands. Parasuraman and Manzey's review found that automation complacency appears specifically under multiple-task load, when manual work competes for attention with automated work. Automation bias occurred in both inexperienced and expert participants and could not be prevented by training or instructions.3 A control room therefore needs to account for the demands it places on each person, including the work they are doing between escalations.
Why a control room should show missions rather than agents#
An interface organised around agents requires people to follow individual workers as their number grows. It can show each agent's activity without explaining whether a piece of work is approaching completion or waiting on an unresolved decision. Organising the interface around the mission keeps the outcome, ownership and current state of the work together. Agent activity can then be examined where it explains progress, a failure or a decision.
For each mission, a leader needs to know what is being attempted and why it matters, who is accountable and what authority the participants have. They also need to see where work is waiting and which constraint is limiting flow. When a mission approaches completion, the control room should show the evidence against its acceptance conditions, the decisions still outstanding and the residual risk the organisation is being asked to accept. These questions remain relevant whether the work involves two agents or two hundred.
Traces provide some of the evidence, but the mission record supplies the relationships needed to interpret it. A failed test, for example, belongs alongside the acceptance condition it tests and the work that depends on it. That lets someone examine the issue in the context of the mission without reviewing every agent run. The control room can retain access to execution detail without making it the default view.
How zoom and layers replace a fixed dashboard#
A map provides a practical model for presenting this information. Zoom changes the level of detail, while layers let someone examine different aspects of the same territory. A mapping application can show a transport network at city level and an individual route at street level without displaying every detail at once. The equivalent in a control room would let people move between the organisation's overall work and the evidence behind a particular decision.
On an enterprise map, the highest level would show strategy, portfolio, outcomes, major risks and major constraints. At mission level, the view would show active missions, dependencies, decisions, resource use and bottlenecks. Execution level would contain agents, people, work items, artefacts, tests and evidence. From there, a person could inspect an individual decision, its source evidence, its history and the audit trail. Each level would show the information needed to understand the work at that scale.
Layers would provide different views at each level. A finance layer would show costs and budgets; a risk layer would show exposure and exceptions. Flow, decisions, evidence and compliance would provide other perspectives on the same missions. Switching layers should preserve the mission and its relationships, so people can compare these aspects of the work without reconciling records from separate systems.
This applies progressive disclosure to governance. The initial view contains enough information to understand the current state and act, with further detail available by zooming, switching layers or following a thread. The principle appeared as a named section in Apple's Macintosh Human Interface Guidelines in 1992. Earlier empirical support came from Carroll and Carrithers' 1984 training-wheels study, which found that blocking advanced functions for new users improved learning speed and reduced errors.4 Its history is often misreported: no credible source identifies who coined the phrase, and accounts routinely date it to 2006.
What belongs in the mission level view#
We would start the mission level view with five areas. The initial version should be small enough to use on live work before committing to a larger platform. That gives the team a chance to establish what it needs to review, how often decisions arrive and whether the information provided is sufficient to make them. The view can develop from that experience.
Active missions would show each mission's outcome, accountable human and participants, together with its authority envelope and current state. Budget consumed should be visible against budget allocated. Decisions waiting would show the judgments that need a person, with enough preparation to support a decision; this is covered in more detail below. Constraints and queues would show where work is waiting and what it is waiting for, including wait time by stage, work in progress and an explicit indication of the current constraint.
Evidence and risk would show which acceptance conditions are satisfied and the evidence supporting each one. It would also identify what remains unproven, what residual risk is being carried and any exceptions requiring review. Those exceptions include policy interventions, agents operating near the limits of their authority and escalated permissions. Learning and system change would record what completed missions contributed back, whether a reusable component, policy change, context update, validation pattern, reference architecture or case study. This makes it possible to review both the outcome of a mission and the changes it leaves behind.
How a decision queue differs from an approval inbox#
The decision queue needs particular care because it can easily become another approval inbox. An inbox can collect requests for a click without anyone checking whether approval is necessary or preparing the information the approver needs. A decision queue should contain judgments the system cannot make. Each item should arrive with a clear question, an accountable person and the evidence needed to answer it.
The item needs to identify the mission and explain why it matters, what judgment is required and who holds the decision right. It should state why the decision is being raised now, what triggered it and the risk of getting it wrong. Alongside the assembled evidence, it needs to show how long it has been waiting and what further delay will cost. Without that cost, the owner has little basis for prioritising one decision over another. Recording the reason for escalation also helps distinguish genuine judgment from system debt, such as a recurring approval that better rules or validation could remove.
Air traffic control provides a relevant example of checking readiness before transferring responsibility. Its position relief procedure uses a structured briefing and verbal readback to establish whether the incoming controller is ready to take over. A control room needs to address the same distinction between assigning a decision and preparing someone to make it. Knowing the owner is insufficient if that person has to reconstruct the mission's history before they can respond. Comprehension engineering addresses that preparation. We would treat each queue item as a re-entry brief with a decision attached, so opening it restores the understanding needed to judge the case.
The alarm standards also suggest how to respond when requests exceed one person's attention budget. Persistent overflow calls for changes to the work reaching that person. In order of preference, we would look to automate the check, lower the risk tier, delegate the decision right or split the mission. The control room should show queue length per owner, identify decisions that have remained unowned and flag sustained overflow for review. We have not seen a current tool treat this consistently as a defect in the design of the work, rather than assuming the owner needs more capacity.
What agent observability tools do not measure#
Agent observability provides substantial coverage of execution. LangSmith, Datadog LLM Observability, Arize, Braintrust, Weave and Langfuse offer traces, spans, evaluation scoring and cost information, using broadly similar models of runs, traces and sessions. OpenTelemetry's GenAI semantic conventions include agent and framework spans, although that work has moved to its own repository and carries Development status.5 These are established capabilities in the tools, but agent tracing should not yet be described as standardised.
The measures concentrate on the machine loop: traces, tokens, latency, cost and evaluation quality. They do not cover wait time, queue length, how long a decision remained unowned or human attention per outcome. If human decisions are constraining delivery, execution telemetry cannot explain that constraint on its own. The organisation needs to instrument the requests reaching people and what happens while those requests wait.
Above observability, vendors are defining a control-plane category currently led by ServiceNow. Its AI Control Tower launched in May 2025 as a centralised command centre for governing, managing, securing and realising value from AI agents, models and workflows.6 This category concentrates on which agents exist, what they can reach and what they are permitted to do. Inventory and permission controls cover an important part of governance. They do not, however, show whether the organisation can handle the decisions those agents refer to people.
The framework mechanisms for requesting human input are already available. The four major frameworks follow a similar pattern: pause execution, persist state, notify a person and resume with a typed decision. LangGraph's interrupt waits indefinitely when a checkpointer is configured, and the OpenAI Agents SDK, Temporal and the Claude Agent SDK offer equivalent mechanisms.7 These handle the interruption, but leave the organisation to manage the resulting queue. Reinertsen's work on queues is relevant here: raising agent utilisation can increase the work waiting for approval without increasing delivery. The queue needs to be managed as part of the operating model.
What governed autonomy requires on both sides#
Human attention should be directed to exceptions, consequential decisions and material risk. Other work should proceed under explicit intent, stated boundaries, validation obligations and escalation rules, with a working rollback path. For this arrangement to hold, the organisation needs confidence in both the work proceeding autonomously and the person's ability to intervene when called on.
Intervening by exception is safe only when the ordinary path is governed properly. The authority envelope must be explicit, evidence requirements agreed in advance and rollback tested in practice. Exceptions must also remain few enough for someone to give each one proper attention. An escalation rule that sends every uncertain case to the same person can satisfy a formal oversight requirement while making the work impossible to supervise properly.
Automation research describes a further risk when people are passive between exceptions. Endsley and Kiris found that the shift from active to passive processing was the most likely explanation for reduced situation awareness under automation, and that decision-making slowed after an automation failure.8 Bainbridge described the underlying difficulty in 1983: automation removes the easy parts of a task and leaves operators to handle the difficult parts without recent practice. An agent fleet can put its human supervisors in a similar position.
A control room that shows only exceptions risks leaving people unfamiliar with the work they are expected to take over. The learning view should help them follow how the system is changing, while the evidence view should explain how work was validated, rather than simply reporting a pass. Maintaining enough understanding to intervene is a design requirement. If it is omitted, human oversight may remain formally assigned even though the person responsible cannot exercise it effectively.
Why the control room should read the same context store#
Much of the context needed for this model is shared. Machines need it to act, people need it to understand the work, managers need it to govern and the control room needs it to display the current state. These needs can lead to four systems commissioned separately by different teams. Each stores a slightly different account of the same work, and within a couple of quarters those accounts can disagree. The organisation then has to reconcile them whenever it needs to explain a decision.
These should be four views of a shared context store. Context engineering uses it to prepare machine actors to act; comprehension engineering uses it to prepare people to judge. The control room displays it at the level and through the layer someone needs, while audit uses the same records to establish what was decided and on what basis. Building around those shared records avoids having to reconstruct an explanation by joining four systems after the event, when the work of doing so may prevent it from happening at all.
What to measure in a hybrid operating model#
We would begin with the measures below. They are candidates, not a validated set, and we do not yet have grounds to claim that they are sufficient. They give teams a way to examine the parts of hybrid delivery that execution telemetry leaves out, and a starting point for testing which measures explain changes in performance.
For flow, we would track time from intent to outcome, wait time by stage and work in progress. We would also record where the constraint sits and how that has changed since the previous month. For attention, we would measure decision queue length per accountable owner, time to decision ready, time spent unowned and human attention consumed per outcome. Assurance measures would cover evidence completeness at gates, residual risk carried and the rate of decisions later reversed. For learning, we would examine reuse of components and patterns, and whether recurring classes of failure become less frequent.
Token volume, prompt count, generated lines, pull request count, agent utilisation and human utilisation can help diagnose particular issues. They should not become delivery objectives. Optimising for any of them encourages more of that activity without establishing whether the intended outcome has improved. They can sit alongside the proposed measures, but cannot substitute for understanding where work waits, why it waits and what it takes to complete it.
How to start building a control room#
Choose one mission that already has agents working on it. For a week, record the decisions that required a person, who held each one, how long it waited and what the delay cost. That record is a first version of the decision queue and can be assembled before building an interface. It is usually shorter than expected, with requests distributed unevenly across owners.
Compare the queue for each owner with an explicit attention budget, using the alarm benchmark as a starting reference. An owner who is consistently over budget warrants a review of how work reaches them. Check whether a recurring request can be automated, whether its risk tier can be lowered, whether the decision right can be delegated or whether the mission needs to be split. Each of these changes addresses the demand on that person instead of relying on faster decisions.
The queue should then make clear which decisions are waiting, who holds them and what information is ready. The person receiving a decision still needs enough understanding to make it, particularly if they have been away from the work. The next post examines the handoff and how to prepare that transfer of responsibility.
Sources
- EEMUA 191 and ISA-18.2 alarm performance benchmarks, summarised in Alarm Management and ISA 18.2: A Journey, Not a Destination, exida. ↩
- Betsy Beyer and colleagues (eds), Site Reliability Engineering, O'Reilly, 2016, Chapter 11, "Being On-Call". ↩
- Raja Parasuraman and Dietrich Manzey, "Complacency and Bias in Human Use of Automation: An Attentional Integration", Human Factors, 2010. ↩
- John Carroll and Caroline Carrithers, "Training Wheels in a User Interface", Communications of the ACM, 1984. Progressive disclosure appears as a named section in Apple's Macintosh Human Interface Guidelines, 1992. ↩
- OpenTelemetry, GenAI semantic conventions, Development status. ↩
- ServiceNow, AI Control Tower launch announcement, May 2025. ↩
- LangGraph, interrupts documentation. ↩
- Mica Endsley and Esin Kiris, "The Out-of-the-Loop Performance Problem and Level of Control in Automation", Human Factors, 1995. ↩
Background: Donald Reinertsen, The Principles of Product Development Flow, Celeritas, 2009, on managing queues rather than utilisation. Lisanne Bainbridge, "Ironies of Automation", Automatica, 1983, on the operator left with the hard parts.
Previously in the series: The Delegation Boundary
Next in the series: The New API Boundary: Designing Human-Machine Handoffs
Related articles: Towards an AI Native Operating Model · The Hybrid Team · What AI native means
We run value-stream assessments to identify where hybrid delivery is constrained and help design the operating model around those findings. info@re-cinq.com
