McKinsey’s new article, The rise of the agentic coworker: A banking CIO’s guide to the next wave of AI, puts human oversight at the centre of a changing banking operating model. As AI agents begin acting across systems, the authors argue, supervision must be deliberately designed around risk.
This article is a response to that argument, and a practical complement to it. At Leapter, we believe one implication deserves particular attention: the decision about when a human becomes involved is itself a business rule.
Which case requires approval? Which exception stops execution? Which limit may an agent never cross?
A rule answers those questions. A role identifies the person responsible once that rule applies.
That distinction determines whether human oversight works in practice.
From assistance to delegated authority
McKinsey defines an agentic coworker as a coordinated system of agents, skills, and tools responsible for a business role and an end-to-end workflow alongside humans. Unlike an agent completing a single task on request, it plans and executes multiple steps, coordinates handoffs across systems, and retains context across cases and interactions. It operates persistently, with responsibility for an outcome.
McKinsey captures the stakes clearly:
“A copilot that gets something wrong creates rework. An agentic coworker that gets something wrong can change a production system, expose client data, trigger a downstream compliance event, or cause a cascading failure across a chain of dependent agents before anyone notices.”
The article sets out five foundations:
- Safe autonomy: Match controls to risk, limit permissions, and require evidence before action.
- Governed identities and ownership: Give every agent a distinct identity, a named human owner, and a managed lifecycle.
- Deliberate human oversight: Define when people approve, sample, or handle exceptions. Expand autonomy only after validation.
- Bank-owned enterprise context: Keep business policies, risk parameters, and institutional knowledge under the bank’s control.
- A common gateway: Enforce controls consistently across agents, models, and tools, with shared traceability and cost visibility.
For banking and insurance leaders, the next question is concrete: where do the conditions governing human intervention live, and who can verify them?
Why human in the loop is a rule
Imagine a bank assigns a risk manager to supervise an agent. Her name appears in the governance documentation. Her responsibilities are clear.
The agent processes ten thousand cases. Fifty reach her.
What selected those fifty?
That selection is the operational meaning of “human in the loop.” It determines where the institution retains individual human judgment and where it has delegated authority to software.
Naming the risk manager does not define that boundary. The boundary comes from conditions: an amount above a limit, contradictory evidence, an unfamiliar transaction pattern, a policy exception, or an action outside the permitted scope.
Those conditions are business logic.
If they remain vague, the agent interprets them. If they are scattered across prompts, configuration, and workflow code, the accountable owner may struggle to establish what the system actually does.
A bank can therefore have a clearly assigned human role and an inadequately controlled decision about when that person is involved.
Human oversight begins with ownership of the rule that selects what receives oversight.
The agent should not interpret its own mandate
“Escalate material cases” leaves the word material unresolved.
A small payment to a changed beneficiary may deserve more attention than a larger, routine payment. Several individually permitted actions may exceed an aggregate limit. Complete documentation may still contain conflicting information.
An authority rule must describe these combinations and their consequences.
Consider a payment-operations agent. Before execution, the workflow checks its proposed action against the bank’s approved mandate. Missing information requires verification. A protected action requires approval. An action outside the mandate is denied. Only cases satisfying the permitted conditions proceed.
The rule also defines what happens while approval is pending. An unavailable reviewer cannot silently become permission to execute.
This boundary needs enforcement outside the agent’s discretion. Otherwise, the same system proposing an action also decides how generously to interpret its permission to act.
An executable rule provides consistency. The surrounding architecture must ensure the agent cannot bypass it.
Make the mandate something the business can inspect
Our view at Leapter is that people should be able to examine the business logic for which they are accountable.
That includes the logic governing an agent’s authority.
A Blueprint can express the escalation decision through defined inputs, conditions, and outputs, together with explanations and tests. Business and risk owners can follow the decision path, question a threshold, and examine an exception before approving a change.
AI can help create and refine that logic. Execution applies the defined rules without a model improvising the decision. The same inputs, Blueprint version, and engine version produce the same output.
This gives the institution a specific artifact to inspect and govern.
It also makes an important conversation possible: “Show me the condition that caused this case to proceed without review.”
The answer can point to the logic that executed. Our article on deterministic tools for AI agents explains this separation between agent coordination and defined business decisions.
Changing the rule changes the delegation
Suppose a team proposes raising an approval threshold. Fewer cases would wait for review.
That is a change in delegated authority, with a productivity benefit attached.
Before approving it, the owner should understand which cases would disappear from the review queue. Historical examples help reveal those changes. Tests should also cover expected outcomes, boundary conditions, missing evidence, and unusual combinations.
Past performance alone cannot establish that broader authority is appropriate. Historical cases may omit rare failures, and earlier decisions may themselves have been wrong.
The institution also needs to preserve learning. Reviewers encounter ambiguous policies and emerging exceptions. Removing their involvement can remove that signal.
A revised supervision model should therefore explain what remains visible through exceptions, sampling, overrides, and monitoring, alongside what becomes automatic.
The owner must own more than the consequences
Approving an individual case permits one action. Approving an escalation-rule change can affect thousands.
The latter deserves explicit ownership, evidence, a recorded reason, and a controlled version.
Business and risk leaders define the mandate. Compliance contributes relevant obligations. Architecture and engineering make the boundary enforceable. Evidence connects the rule applied, its evaluation, any required human approval, and the eventual action.
Leapter’s trace explains the Blueprint’s evaluation. The surrounding systems complete that operational chain, as we discuss in Why Your AI Agents Can’t Pass an Audit.
The practical complement we would add to McKinsey’s framework is this: put the escalation rule in front of the person accountable for the agent’s outcomes.
Can they read it, test it, and explain why these cases require judgment while those may proceed?
That is where “human in the loop” becomes a control the institution owns.
Explore the broader argument in our eBook, Why Your Enterprise AI Isn’t Scaling.
