AI Native Operating Model · Part 5 of 7
A person clicking approve is not oversight. What has to reach them before it is, and what has to reach an agent before it can work.
Imagine an agent finishing a task and sending a message: "Done, approve?" There is a button underneath. The person receiving it has not been following the work, may know very little about what changed, and is now expected to take responsibility for the result.
This is a familiar pattern in agent tooling. Even when a control room is in place and the right decisions are reaching the right people, the reviewer is often given little more than a summary and an approval request.
The problem starts earlier, though, when the person gives the agent its instructions.
"Refactor authentication to support enterprise SSO" sounds like a reasonable request. But which identity provider should the agent use? What should happen to existing sessions? Can the trust boundary change? Which parts of the system must remain untouched? And if the work requires a schema change, who gets to make that decision?
None of this is in the instruction. The agent has to ask or make assumptions, and it will often proceed on those assumptions.
These look like two different problems, but they have the same cause. In both cases, one party is expected to act or make a decision without being given enough context. The agent lacks the constraints needed to carry out the task correctly, while the person lacks the understanding needed to review what the agent has done.
What human in the loop actually means#
Human in the loop means that a person participates in an automated process and has the authority to approve, correct or reject an action before it takes effect. In a human on the loop arrangement, the system operates without waiting for approval, while a person monitors it and can intervene. Human out of the loop goes further: once the system is running, no human involvement is required.
In AI governance, these distinctions offer a simple way to describe the degree of human involvement and how much authority has been delegated to a system. They tell us much less about how that involvement should actually work.
Why the phrase describes a position, not a design#
Consider two systems. In the first, an agent finishes its task and asks someone to approve it. In the second, it presents the decision that needs to be made, explains what changed, shows the supporting evidence and identifies the consequences of each available option.
Both qualify as human in the loop. Yet the experience of being responsible for the decision is entirely different.
Knowing where a person enters the process tells us nothing about the information they need, the authority they are exercising or how they can make a sound decision.
This becomes a bigger problem as one person starts supervising several agents. When people reviewed work they had largely done themselves, they brought their own understanding to the approval step. They knew the history, the constraints and the decisions made along the way.
With agents, that understanding is no longer guaranteed. The reviewer may see the work for the first time when the approval request arrives. Their ability to judge it depends on what the system has chosen to communicate, which in most tools today amounts to a diff and a summary.
What the EU AI Act asks for instead#
The European Union's AI Act addresses this question in more concrete terms. Article 14 sets out requirements for human oversight of high-risk AI systems, focusing on what people must be able to do rather than simply where they appear in a workflow.
People assigned to oversee these systems must be able to understand their capabilities and limitations, monitor their operation, recognise the risk of over-relying on their outputs, and interpret those outputs correctly. They must also be able to disregard or reverse a system's output, decide not to use it, and intervene or stop the system safely.1
Each requirement describes a capability that oversight must provide. An approval button may establish that a person has the final say, but it does not establish that they understand what they are approving, can recognise a problem or have the means to intervene effectively.
Article 14 applies to high-risk systems, so most software delivery teams should treat it as a precedent rather than a legal requirement for their own workflows. The underlying principle is worth adopting more broadly: human oversight has to be designed around what the person can understand and do, not merely whether they are present.
What medicine learned about handoffs#
Software is hardly the first industry to struggle with handovers. Aviation, nuclear operations and healthcare have spent decades developing procedures for transferring responsibility, often in response to failures with serious consequences.
Aviation uses position relief procedures that include mandatory readback. Nuclear operations rely on three-way communication, where the receiver repeats an instruction and the sender confirms it. In healthcare, the I-PASS programme structures what clinicians communicate when handing over responsibility for a patient.
A study covering nine hospitals and 10,740 patient admissions found that implementing a structured handoff programme reduced medical errors by 23%, from 24.5 to 18.8 per 100 admissions. Preventable adverse events fell by 30%, from 4.7 to 3.3 per 100 admissions.2
What makes the result interesting for software teams is that better handoffs did not require substantially more time. Oral handovers took an average of 2.4 minutes per patient before implementation and 2.5 minutes afterwards, a difference the study found statistically insignificant.
The improvement came from changing what was transferred and how it was communicated, rather than simply asking people to spend longer explaining things.
Designing better handoffs between people and agents should therefore not mean adding more meetings, approval stages or documentation for its own sake. The purpose is to give each receiving party enough information to continue without having to reconstruct everything from scratch.
Why context goes out and comprehension comes back#
A handoff between a person and an agent has two directions, and each presents a different challenge.
When a person hands work to a machine, the main challenge is transferring context. When an agent returns work to a person, the challenge is transferring comprehension.
A machine can preserve its working state in written form. When a session ends or a subagent takes over, the next execution can rebuild its working context from whatever was saved. This is the purpose of context engineering: ensuring the system has the information it needs at the point it needs it.
The quality of the result depends on whether the right information was captured and made available. If a constraint or previous decision was never recorded, the next agent cannot reliably recover it.
People work differently. A person's understanding develops through participation. While working on a problem, they build a mental model of the system, its history, its constraints and the reasons behind particular choices. When they leave the task, some of that understanding fades. Returning to it requires state reconstruction.
Peter Naur described a related problem in 1985. He argued that the real product of programming is a theory held in the programmer's mind, and that this theory cannot simply be recovered from the documentation.
That observation becomes especially relevant when agents perform more of the implementation work. Developers used to build their understanding partly through the act of building the system. They encountered the constraints, made the trade-offs and discovered the awkward details themselves.
When an agent does that work, the person responsible for the outcome may never encounter those details.
The two directions therefore need different kinds of information. The agent needs enough context to act correctly, while the person needs enough understanding to exercise judgment. Treating both as the same transfer overlooks that difference.
What to put in a brief for an agent#
Consider what happens when an agent begins work with an incomplete specification.
It may make reasonable assumptions and produce something that appears to satisfy the request. Later, a missing requirement emerges. Perhaps a service must support a legacy client, or an authentication change must preserve a particular session behaviour. The agent now has to revisit work that would have been done differently had the requirement been known earlier.
A study of real coding-agent sessions identified 921 requirement-emergence events across 402 sessions that could be reliably replayed. When a requirement appeared, the amount of earlier work invalidated afterwards was roughly twice that of matched edits without a new requirement. The effect did not show a detectable decline as sessions progressed.3
The authors describe this as a temporal association, not proof that the late requirement caused the rework. Their estimates also leave room for a more moderate effect. Even with those qualifications, the finding points to a familiar engineering problem: discovering important requirements after implementation has started tends to make earlier work less relevant.
For agents, the answer is not to write longer prompts. It is to provide a brief that establishes what the work means and where the agent's authority ends.
That brief should explain the intended outcome, the constraints that apply and the properties that must remain unchanged. It should define which tools and data are available, what the agent may decide independently, what budget it can use, and what conditions the result must satisfy to be accepted. It also needs to identify acceptable risks and the situations in which the agent must stop and ask for a decision.
Previous decisions belong there too, especially when their reasoning is not obvious from the current state of the system.
Take a simple instruction: "Create a tenant onboarding API."
An agent could produce a working implementation, but the instruction says nothing about who may call the API, how idempotency should work, how tenant boundaries are enforced or what should happen when provisioning fails partway through. It also leaves open which service owns the resulting data.
A better brief makes those choices explicit, or clearly identifies which of them the agent is authorised to make.
The goal is not to specify every implementation detail in advance. It is to establish enough context that the result can be evaluated against what was actually intended, rather than against assumptions nobody agreed to.
What to put in a decision brief for a person#
The return journey is less straightforward because much of the existing tooling gives the impression that it has already been addressed.
Pull request summaries have improved considerably. GitHub Copilot and CodeRabbit, for example, can produce readable explanations of what changed and why. But a good summary of code changes is not necessarily a good handoff to the person who must make a decision.
There are three important gaps.
First, these summaries are generally organised around the branch base rather than the last state a particular reviewer actually understood. Second, they describe the change without necessarily identifying the decision the person is being asked to make. Third, they provide information without checking whether the reviewer has understood enough to act on it.
A decision brief should tell the person what judgment is required, what has changed conceptually, what evidence supports the result, which assumptions the agent made, and what uncertainty or residual risk remains. It should also explain the alternatives considered and the consequences of the available choices.
The comprehension delta is central to this.
Imagine receiving a summary that says, "843 lines changed across 12 files." That describes the size of the change, but it says almost nothing about what the reviewer needs to understand.
Now consider: "The authentication trust boundary moved to the shared identity service, so session invalidation is now a cross-service concern."
The second statement identifies a conceptual shift and its consequence. It tells the reviewer something that may change how they understand the system. That is what a comprehension delta is meant to capture.
There is a risk here, however. A well-written explanation can make an AI recommendation feel more trustworthy without making it more correct.
Bansal and colleagues found that explanations "increased the chance that humans will accept the AI's recommendation, regardless of its correctness".4 A fluent explanation may therefore increase reliance on an AI system even when its recommendation is wrong.
This is why better briefs cannot be treated as proof of better decisions. Their purpose is to reduce the effort required to verify a claim, making it easier for a person to inspect the evidence, challenge assumptions and understand the consequences before choosing.
Whether that leads to better decisions is something teams need to test. It is also one of the questions comprehension engineering is intended to answer.
What a handoff contract contains#
Once the requirements in both directions are made explicit, they can be expressed as a handoff contract.
Rather than simply defining the structure of a message, the contract establishes what must be transferred when control moves between a person and an agent, what authority the receiver gains, and what response is expected.
The following schema is experimental. It is a starting point for testing and discussion, not a standard that teams should adopt without examining their own needs.
| Field | Human to machine | Machine to human |
|---|---|---|
| Sender and receiver | A named person hands over a named mission. | A named agent or workflow hands back to a named accountable person. |
| Transfer objective | What the receiver should achieve. | What judgment the receiver has to exercise. |
| Mission state | Where the mission stands now. | Where the mission stands now. |
| Payload | Context: constraints, acceptance conditions, decision history, data and tool scope. | Comprehension: the decision, the delta, the evidence, the assumptions, the uncertainty and the trade-off. |
| Invariants | What must not change. | What did not change. |
| Authority after handoff | What the agent may now decide alone. | What the person is authorised to decide. |
| Evidence | Prior validation results the agent should trust. | Validation performed, and what it does not cover. |
| Stop conditions | When to halt and escalate rather than proceed. | What would make this decision reversible, and how. |
| Expected response | An artefact plus an evidence package. | A typed decision plus a recorded rationale. |
The amount of detail required will vary, and should depend on the impact of the decision rather than the size of the implementation.
A one-line change to an authentication trust boundary may deserve a detailed explanation because the consequences are substantial. Five hundred lines of generated test fixtures may need only a short summary. What matters is how much someone must understand to take responsibility for what happens next.
The second principle concerns invariants, the properties that must remain true throughout the work.
They belong in both directions of the contract. An agent needs to know which properties it must preserve. When the work returns, the reviewer needs to know which of those properties were preserved and what evidence supports that conclusion.
Otherwise, the agent may protect the wrong things, while the reviewer has to repeat checks that the handoff should already have accounted for.
Why the reasoning has to be recorded#
Recording only the outcome of a decision creates a problem for whoever takes over next.
A developer can inspect a code change and see what happened. That does not necessarily explain why the team chose one approach over another, which alternatives it rejected or which constraints shaped the decision.
Architecture decision records were created to preserve that kind of information. They separate the resulting change from the reasoning behind it.
The same principle applies to human-agent handoffs.
When a person makes a decision, recording the rationale gives the next agent more context. It can see which constraints mattered, what trade-offs were accepted and why certain alternatives should not be revisited without new evidence.
When an agent returns work to a person, its account of the assumptions, evidence and trade-offs helps the person reconstruct what happened while they were not involved.
This does not mean preserving a model's internal chain of thought. An internal reasoning trace is not necessarily a faithful account of the computation that produced an answer, and it is not a reliable substitute for an explanation a person can verify.
The record should instead contain externally checkable information: the assumptions made, the alternatives considered, the evidence used and the trade-offs accepted.
Those details can be examined, challenged and carried into the next handoff.
How handoffs make asynchronous work possible#
The wider benefit of designing handoffs is that people and agents no longer need to remain continuously engaged with one another.
A person can give an agent a defined task, leave it to work and return when a genuine decision is required. The agent can pause without losing the information needed to continue. The person can resume without having to reconstruct the entire process from messages, logs and code changes.
This is what makes asynchronous work practical.
It also changes how many agents one person can reasonably supervise. Managing one agent through constant interaction is very different from coordinating several agents that can work independently and return with decisions ready for review.
That capacity problem is already becoming important for the hybrid team.
The technical ability to pause and resume work is not the main obstacle anymore.
LangGraph supports interrupts that allow a workflow to pause with its state preserved through a checkpointer and resume when the required input arrives.5 Temporal is built around durable execution and can wait without consuming compute. The OpenAI Agents SDK can serialise pending approval state, while the Claude Agent SDK can hold a permission callback open for the lifetime of a process and defer longer waits.
These mechanisms address the mechanics of waiting, but they do not settle the content of the handoff. Teams still have to decide what the person should receive, what they must understand and what their response should authorise.
Without that design, an asynchronous workflow can still leave someone staring at "Done, approve?" several hours after the relevant context has disappeared.
Which handoff failures to count#
When a handoff goes wrong, saying that communication failed is not particularly helpful. Different failures have different causes, and they need different fixes.
On the way from a person to an agent, the common problems are missing context, stale context, ambiguous authority and unstated invariants.
Missing context means a requirement or constraint was never supplied. Stale context means the information was accurate when recorded but no longer reflects the current state. Ambiguous authority leaves the agent unsure which decisions it can make independently. Unstated invariants allow it to change something the team expected to remain fixed.
The failures on the way back to a person are somewhat different.
An agent may explain the work at the wrong level of abstraction, making it difficult to see the decision that matters. It may present a conclusion without supporting evidence, omit a consequential assumption or provide all the necessary information in a form that the reviewer still struggles to understand.
These are problems of comprehension rather than missing data alone.
Two other failures concern when a person is involved at all.
Over-escalation happens when an agent interrupts someone for a decision it could reasonably have made within its existing authority. Under-escalation happens when an agent makes a consequential decision that should have been brought to a person.
Both deserve attention because they reveal whether the organisation has placed its decision boundaries correctly, and they are relatively easy to measure.
After each human decision, ask whether it genuinely required that person's involvement. If a particular approval repeatedly receives a "no", there may be a case for automating it. If a review or postmortem identifies a consequential decision that never reached a person, the workflow needs an additional escalation point.
Over time, these observations provide a practical tuning signal for the decision queue.
The goal is not to maximise or minimise the number of approvals. It is to ensure that people are involved where their judgment adds value and that agents can proceed independently where it does not.
What an approval actually authorises#
A handoff does more than transfer information. It may also change who has permission to act.
That makes it a security boundary, even though many agent workflows still treat it primarily as an interaction between a system and its user.
Consider what an approval means in practice.
Has the person authorised one specific action, a class of actions, the rest of the session or the entire mission? Does approval give the agent access to credentials or tools it could not use before? Can it perform irreversible operations? If the agent delegates part of the work to another agent, does that authority follow the delegation?
These questions are easy to overlook when an approval is represented as a single button.
Some parts of the underlying security problem already have established answers.
The Model Context Protocol's authorization specification, for example, requires servers to validate that an access token was issued specifically for them. Servers must reject tokens that do not identify them as the intended audience, and they must not pass a token received from a client through to an upstream API.6
These requirements help prevent credentials from being used outside their intended scope.
Recursive delegation between agents is less settled. An agent may assign work to another agent, which may in turn use additional tools or services. Without explicit rules, it becomes difficult to determine which permissions should follow the work and which decisions require fresh authorisation.
Teams are already deploying systems that operate this way.
A handoff contract provides a way to make those boundaries explicit. It can specify the authority being transferred, its limits, the conditions under which further approval is needed and what must happen when control returns.
The alternative is to let these decisions emerge from implementation details, which is a poor foundation for managing consequential authority.
How to test this in one month#
There is no need to redesign every workflow before finding out whether structured handoffs make a difference.
Start with one agent workflow that already contains a meaningful human decision. It should be frequent enough to observe repeatedly and consequential enough that the quality of the handoff matters.
For each handoff from the agent back to a person, measure four parts of the total latency.
First, record how long the request waits before someone picks it up. Then measure the time to decision ready, the period the person spends rebuilding enough context to make a judgment. Separately record any clarification loops and the time taken to make the decision itself.
These are different sources of delay, yet current tooling tends to make the waiting period the most visible. As a result, teams often focus on routing approvals faster without examining how much work the recipient must do once the request arrives.
After establishing a baseline, replace the "Done, approve?" message with a decision brief that identifies the decision required, explains the conceptual change relative to what the reviewer last understood, presents the relevant evidence and makes the trade-offs visible.
Measure the same four latency components again.
On the outbound side, track how many clarification loops were needed between assigning the work and receiving an acceptable result. This helps reveal whether better initial context reduces the amount of back-and-forth required.
There is some reason to expect the re-entry part of the process to improve.
In a controlled study of programmers returning to interrupted tasks, developers who received automatically generated resumption cues completed their tasks at twice the success rate of those relying on their own notes.7 The study took place in a laboratory rather than a production environment, and the two cue designs performed similarly, so the result should not be treated as a direct prediction for agent workflows.
Still, it suggests that helping people rebuild their understanding can have a measurable effect.
The experiment may show that decision briefs reduce re-entry time, improve the quality of review or reduce clarification loops. It may also show little difference in a particular setting. Either result is worth knowing, provided the team measures it rather than assuming that a more elaborate handoff must be better.
Once the handoff itself works, a larger organisational question appears. What happens to the people who used to coordinate this work, and to those who learned the job by participating in it?
That is where the next part of the AI Native Operating Model begins.
Sources and further reading#
- European Union, Artificial Intelligence Act, Article 14 (Human oversight). The obligations apply to high-risk systems. ↩
- Amy Starmer and colleagues, "Changes in Medical Errors after Implementation of a Handoff Program", New England Journal of Medicine, 2014. ↩
- "Requirements After the First Edit: Mining Late Requirement Emergence and Rework in Real-World Coding-Agent Sessions", arXiv preprint, 2026. The paper reports a temporal association rather than a demonstrated cause. ↩
- Gagan Bansal and colleagues, "Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance", CHI 2021. ↩
- LangGraph, interrupts documentation. ↩
- Model Context Protocol, Authorization specification, 2025-06-18. ↩
- Robert DeLine and Chris Parnin, "Evaluating Cues for Resuming Interrupted Programming Tasks", CHI 2010. ↩
Background: Peter Naur, "Programming as Theory Building", Microprocessing and Microprogramming, 1985, on why a program's theory cannot be revived from its documentation.
Previously in the series: The AI Native Control Room
Next in the series: Managing the System That Does the Work
Related articles: The Delegation Boundary · The Hybrid Team · Towards an AI Native Operating Model · What AI native means
Are your approvals carrying anything? We run value-stream assessments to identify where human judgment is needed in hybrid delivery, then help teams design handoffs that make those decisions easier to understand and act on. info@re-cinq.com
