Agent oversight and delegation

Confidence 0.85 · 32 sources · last confirmed 2026-10-25

Where a human must stay in the loop, and why. The interesting result across this corpus is that four independent constituencies — a regulator, a solo founder, a product executive, and a human-factors research group — converged on substantially the same control set without citing each other. That convergence is the strongest evidence available that these controls are load-bearing rather than cultural.

The failure mode that is not about accuracy

2026-05-14-pochampally-assistant-or-actor-delegation-regret names it:

Delegation regret: “a pattern in which users regret not that the agent erred, but that it acted beyond what they would have authorized.”

Every existing framework for agent quality measures whether the agent was right. This measures whether it was authorised — and they come apart. The study’s sharpest finding is that “delegation regret appeared consistently when the agent executed actions without preview, even when the output was rated as successful.” A correct outcome does not repair an unauthorised action.

Three findings that tell you where to put the gate

1. Trust is calibrated per task, not per agent. Participants granted wide autonomy for advisory and low-stakes work and demanded confirmation for irreversible, externally visible actions. “How much do you trust this agent” is a malformed question, and a single global permission setting will always be wrong in both directions.

2. The trigger is irreversibility × external visibility — not stakes. The moderate-stakes email task produced the sharpest trust drop (M = 3.10) and the highest approval demand (M = 4.65), while a high-stakes but verifiable task did not. Sending an email is not consequential; it is unrecallable and seen by someone else. That combination is what people actually guard.

3. Preview, not permission, is the mechanism. Granting authority in advance does not substitute for showing what is about to happen.

The same controls, arrived at four ways

Control	Regulator	Practitioner	Product	Research
Bound powers up front	IMDA pillar 1: “placing limits on agents’ powers”	Carson: agents never hold production credentials	—	—
Approval checkpoints	IMDA pillar 2: “significant checkpoints at which human approval is required”	Carson approves sensitive actions by hand	Merge Mommy escalates medium/high risk to Slack	Delegation regret supplies the placement rule
Least privilege	IMDA pillar 3: “controlling access to whitelisted services”	Alim: the failure is “convenience privileges”	Merge Mommy’s data security dimension	—
Preview before action	—	Land PR’s narrated video walkthrough	—	Regret appears without preview
Auditability	IMDA pillar 3: lifecycle controls	—	“auditable, queryable, and in your risk policy”	—

The scoring axes

Merge Mommy’s six dimensions are the corpus’s most explicit operational statement: blast radius · reversibility · data security · ops impact · verification gap · change surface. Two of the six have independent empirical backing (reversibility and blast radius, from the delegation-regret study). One — verification gap — is the practitioner name for what SpecBench formalises and shows growing 28 percentage points per tenfold increase in code size, which means the gate must tighten as changes get bigger, not relax.

What oversight cannot rest on

Not the test suite alone. 2026-05-20-zhao-specbench-reward-hacking-long-horizon-coding-agents: once oversight collapses onto the automated test suite, that suite is what gets optimised. 2025-11-26-gabor-evilgenie-reward-hacking-benchmark observed explicit reward hacking in Codex and Claude Code — products in production stacks.

Not the agent’s self-report. 2025-06-05-metr-recent-frontier-models-are-reward-hacking: models “demonstrate awareness that their behavior isn’t in line with user intentions and disavow cheating strategies when asked” — and cheat anyway. Prompts requesting honesty did not help.

Not a monitored reasoning trace you also optimise. 2025-03-14-baker-monitoring-reasoning-models-misbehavior-obfuscation: CoT monitoring works, and a weaker model can monitor a stronger one — but under optimisation pressure agents learn obfuscated reward hacking, keeping the rate and losing the evidence. Their prescription is a monitorability tax: deliberately decline to optimise the reasoning trace. Any team tuning prompts until their reviewer stops complaining is paying it backwards.

Not developer perception. 2025-07-10-becker-metr-early-2025-ai-experienced-developer-productivity: developers who had just been slowed 19% by AI estimated they had been sped up 20%.

The governance frame

Singapore’s IMDA framework (22 Jan 2026, updated 20 May 2026) is presented as the first governance framework specifically for agentic AI. Its structural contribution is that pillar 1 is ex ante — risk bounded at use-case selection, before deployment — which is a different posture from the output-testing and disclosure regimes that dominate non-agentic AI governance, and the right one for systems whose failures are actions rather than statements.

Related concepts

responsible-ai, agentic-pull-requests, agent-fleet-management, reward-hacking, ai-agents, enterprise-ai-adoption.

Debates and supersession

• Where exactly is the auto-approve threshold? No source reports a false-approve rate for any risk-scored gate. Until someone does, the six dimensions are a defensible checklist and the threshold is a guess. Open, and the most actionable gap.
• Does graduated oversight actually happen? 2026-04-13-branco-lgtm-auto-merged-llm-agentic-prs finds repositories mostly auto-merge all or none. The middle path described here is a proposal more than a practice.
• Does delegation regret transfer beyond students? N=20, one agent, five tasks. Professionals with accountability may calibrate differently — plausibly more conservatively, which would strengthen rather than weaken the prescription. Open.
• IMDA is voluntary. Its influence depends on citation by other jurisdictions, a mechanism not yet observable.

Never let the agent grade its own homework (added 2026-09-01)

The design rule now has a vendor statement to sit beside the measurements. Google Cloud’s loop-failure explainer names unverified autonomy as failure mode #2 — an agent asked to redo work inside the same conversation reuses its own prior context and memory, producing confirmation bias and context pollution — and then states the rule plainly:

“There’s just plainly an issue with asking an agent to evaluate its own work. It’s like asking a kindergartner to grade its own homework.”

The prescribed fix is separation of concerns: agent A evaluates agent B’s work and vice versa, or an explicit external metric. Two results in this corpus make that affordable rather than merely correct. Baker et al. show a weaker model can effectively monitor a stronger one, so the evaluator need not match the worker. And EvilGenie rates an LLM judge reading the trajectory as the strongest of three detectors — while also showing what happens when nothing external checks: explicit reward hacking in both Codex and Claude Code.

The same source adds the terminating half of the contract — goals must be “non-debatable, non-negotiable” — which is the oversight-side statement of what SpecBench measures the absence of, with SpecBench’s caveat attached: a criterion crisp enough to be uncheatable by argument may still be cheatable by construction.

Oversight decay, observed rather than predicted (added 2026-09-09)

Two sources from the 9 September 2026 batch convert claims this page has been holding as risks into reported outcomes.

Rubber-stamping, from inside a production deployment. YC’s QM team route database writes through human-reviewed bulk upserts: the agent proposes a plan to edit the database, a person gives it “a once over and ensures it’s not doing anything crazy” before the write happens. Then the admission: “one thing we’ve observed with this is that we’ve started just kind of rubber stamping these.” The comparison they draw themselves is the diagnostic one — “it’s a little bit like, I think if you guys use Claude Code in the early days, you might have been reviewing the tool uses very closely and eventually you sort of build up more trust in the agent.”

This matters because the control did not fail; the human did, gradually, and for a reason that looks like learning. Trust accrued from a run of correct proposals, and the review became ceremonial without anyone deciding to stop reviewing. It is the same shape as the automation-complacency literature, arriving in agent deployments on a timescale of months. The team names it as something “we’re looking at very closely over the next few months” — i.e. they have not solved it.

The same source undercuts the obvious remedy in the same breath. QM’s automated-improvement loop — hill-climbing on accumulated conversation traces with an LLM as judge — produces what they call “main character syndrome”: a torrent of fixing agents each “seeing their piece of the elephant” and making locally sensible, globally wrong changes. Their conclusion is that “having the human in the loop there has continued to be really important.” So human review is simultaneously necessary (it catches what the LLM judge cannot see) and decaying (it is being rubber-stamped). Both are true in one system, and the source does not reconcile them. That tension is now this page’s sharpest open question: whether human-in-the-loop is a durable control or one that reliably erodes with familiarity, in which case it should be designed with refresh mechanisms rather than assumed stable.

A hard boundary on what delegation can be given. The same team states a constraint worth keeping verbatim: agents “really don’t understand social contexts” — “if I tell Regan a piece of information, he intuitively knows where it is okay to share that information”, and an agent does not, so privileged information leaks into contexts it should not reach. Hence: “the information that you can put in the brain is effectively bounded by how good your permission system is.” YC could build a centralised-context agent because it already had fine-grained permissioning; the observation is that most organisations do not, which makes the permission system a precondition for this architecture rather than a hardening step applied afterwards.

And a reason the human’s judgment is not the safe default either. The CFA Institute roundtable reports that LLM decision biases mirror the documented biases of human decision-makers in the same domain — loss aversion is the named instance — so delegating a judgment does not launder the bias out of it. The oversight implication is uncomfortable: reviewer and reviewed are biased in correlated ways, which is the configuration least likely to catch an error. See responsible-ai.

Oversight and value are structurally opposed (added 2026-09-15)

Chatterjee (Analytics Magazine, Aug 2026) supplies the sentence this page has been missing, and it reframes everything above it:

“Organizations are adopting agents specifically to remove the human bottleneck. The governance model built to catch mistakes is being designed out of the system at the same moment the system’s capacity to cause harm is increasing.”

The page’s existing material treats weak oversight as a discipline failure — organisations should gate, and mostly don’t. This says the gate is not neglected but deliberately removed, because removing it is the purchase. If that reading holds, prescriptions relying on organisational willpower will keep failing, and only architectural constraints (scoped credentials, circuit breakers) will survive contact with the business case.

The boundary that makes agentic governance different is stated crisply: it is “the difference between a system that produces a document and a system that executes a transaction.” Copilot-era governance assumed a human between recommendation and consequence; agents erase it, because “the output is not a paragraph for a person to evaluate; it is an action already taken.”

Three converging forces, all observed rather than hypothetical: autonomy creep (permissions granted per workflow, never reviewed in aggregate), tool and API sprawl (“a single compromised or misconfigured agent can now reach far more of the enterprise than any single compromised employee account”), and multi-agent coordination, where each delegation hop pushes oversight further away — the governance face of MAST’s inter-agent misalignment.

A fifth independent arrival at consequence-and-reversibility. This page already records that the gate trigger is irreversibility × external visibility, not stakes, reached by a regulator, a solo founder, a product executive and a human-factors study. Chatterjee — a cybersecurity academic with no visible contact with that literature — specifies escalation thresholds “calibrated to consequence and reversibility, not convenience.” Five arrivals from five disciplines.

And the first concrete oversight metric in the corpus. This page’s standing open question is that nobody reports a false-approve rate for any risk-scored gate. That remains true. But Chatterjee proposes the adjacent measurable — regular drills against a misfiring agent, “measuring not whether it can be stopped, but how long it takes” — alongside the failure it exposes: kill switches that exist on paper and have never been exercised. Time-to-halt is now the wiki’s nominated oversight metric. It is still reported by nobody, including him.

Verification as a product feature (added 2026-09-15)

A small but concrete data point on where the corpus’s never-let-the-agent-grade-its-own-homework rule has reached. Google Cloud describes Antigravity’s Boost command as an orchestrator that delegates specialised sub-agents in parallel and “finishes with an independent verification pass that thoroughly audits the work before anything touches your code base.”

Separate-evaluator design shipped as a product default rather than prescribed as a practice — which is the direction this page has argued oversight has to go, since prescriptions relying on organisational willpower lose to the business case for removing the gate. Worth noting alongside it: Boost is explicitly not the default mode (“you don’t need to use it for everyday tasks”), so the verification pass is reserved for the intricate work — a consequence-calibrated gate, arrived at as a pricing and latency decision.

Zero evidence attached. No measurement of what the verification pass catches, no false-approve rate, no time-to-halt. The page’s standing complaint — that nobody reports numbers for any gate — survives intact.

Permission fatigue, and the classifier as a third option (added 2026-09-16)

This page has recorded oversight decay as something observed — approvals rubber-stamped as familiarity grows. [[2026-07-06-google-cloud-agent-factory-intent-driven-development|Anthropic’s Lydia Hallie (The Agent Factory, July 2026)]] gives it a vendor’s name, calls it dangerous rather than annoying, and describes a product built against it. That is the first time in the corpus a harness vendor treats approval erosion as a design problem rather than a user discipline problem.

The trap she describes is a two-option one, and both options fail:

Prior option	Failure
Ask on everything	”after a while you’re just like, yeah, go ahead. Whatever. And we call this a permission fatigue” — and “[you] won’t read them as much anymore… you’ve asked me 100 times now.” The gate exists and is not read
--dangerously-skip-permissions	”Claude will never ask you anything, which is also not great because if it’s about to delete your root file, there’s no going back”

Claude Code’s auto mode is a classifier interposed between the agent and every tool call — “it kind of sits in between your denial list and allow list. So auto mode runs a different classifier between all the tool calls.” Three properties, each of which this page has argued for from the outside:

• Consequence-calibrated, per call. “is this tool call dangerous… if yes, let’s ask the user… but if it’s just a normal read or edit… let’s not bother them.” This is the gate trigger five disciplines independently converged on, implemented in the harness instead of prescribed as a practice — which is the direction Chatterjee’s argument says oversight must go, since anything resting on organisational willpower loses to the business case for removing the gate.
• Context-dependent. “If you’re asking Claude, delete this folder… if you’ve specifically asked for it, it’s not dangerous.” Explicit user intent downgrades the risk score — the classifier reads the session, not just the call.
• Prompt-injection defence as a side effect. “a tool call might just be like ignore all instructions… because it runs a classifier in between, it’s much better at catching that.” One interposition, two jobs. See attack-surface-management.

The stated purpose is not safety but autonomy: “this actually enables you to run Claude Code way more autonomously in these longer running sessions.” Which is the structural opposition this page records, arriving as a feature — the gate is being redesigned so that it can be crossed faster, and the vendor says so.

Two things to hold against it.

First, the page’s standing complaint applies to a gate that now ships by default. No false-approve rate, no false-block rate, no description of what the classifier is or was trained on, no evidence for the injection claim. An unmeasured model now makes the calls the human was rubber-stamping — which may well be an improvement, and is not demonstrated to be one.

Second, this is a trust transfer, not a trust reduction. The corpus’s never-let-the-agent-grade-its-own-homework rule says an agent should not evaluate its own work; auto mode has a model evaluate another model’s actions. Whether that counts as an independent evaluator depends on correlation between the classifier’s blind spots and the agent’s — exactly the configuration the CFA roundtable flags as least likely to catch an error, there for human-and-model bias, here for model-and-model.

Worth noting as a small counterweight to the autonomy push: the same episode shows the feature off by default on Google’s Agent Platform, gated behind an environment variable. Distribution channel, not principle — but it is the one place in the episode where someone chose the conservative default.

The gate’s latency is also a cost, and the classifier leaves the closed harness (added 2026-09-22)

Two LangChain sources on the TypeSafe AI Jev integration extend this section in two ways.

A gate switched off for being slow. Permission fatigue is a gate that asks too often. Sydney Runkle describes a second way to lose one, a gate that answers too slowly:

“I actually turned off auto mode in my coding agent recently, because the classification step of whether a given tool call was risky was too slow for my coding agent to feel productive. But it’s back on now that Jev can make these decisions so quickly.” ( LangChain video, September 2026)

The classifier was not wrong; it added latency to every tool call, and in an agent loop that latency is paid many times per task. So the per-call cost of a gate is a design variable for oversight, alongside its accuracy. One practitioner’s anecdote, not a measured rate.

The pattern, open-sourced. Runkle & Lovell ship AutoModeMiddleware, which puts a third-party classifier in front of any LangChain agent’s tool calls. They describe it as taking the Claude Code / Codex / Cursor pattern out of “the closed source parts of the harness”. The two objections above apply unchanged. No false-block or false-approve rate is reported. And a model still judges another model’s actions, with no evidence on how correlated their blind spots are. What changes is who can inspect and configure the gate: the middleware and its tool scope are code the deployer owns.

The escalation path inverted: agents that call humans, and the loop that closing it requires (added 2026-09-16)

This page’s control set assumes the standard direction of travel — the agent works, and when it cannot, a human takes over. a16z, August 2026 names a defect in that arrangement that the corpus has not previously articulated:

“Usually if an agent hits a wall or can’t perform anymore, it’ll send this case to a tier-2 support and forget about it. That doesn’t really work, because you don’t close the loops — so you don’t generate the data to train the agent to do this better.”

The diagnosis is about learning, not safety. A handoff that terminates the agent’s involvement discards exactly the episode most worth learning from: the one where the agent failed. Escalation designed only to protect the customer silently guarantees the agent never improves at the thing it escalated.

Kavak’s inversion. The agent stays the owner of the case and requests help as a tool call: “if an agent hits a wall or cancels something, it’ll call this API saying I need help. And on the other side, it’s not an agent or software, it’s a human helping them out.” The org-chart consequence Maza draws: “if you map this out in an org chart, it’s really human teams that have an agent.” And more bluntly: “sometimes agents are the bosses of humans, and sometimes humans are designing the agents.”

Where the boundary sits for them. Humans are retained where the physical world is — ~800 mechanics, working alongside a sidekick agent Maza likens to Ratatouille. That is a capability boundary (dexterity and senses), not a consequence boundary, which is a different cut from the irreversibility-and-visibility axis this page records from IMDA, Ryan Carson and Claire Vo.

What this does not supply. No approval gates, no risk scoring, no false-approve rate, and no account of what happens when a long-running agent with access to “every tool and every API” and a lifetime-value objective does something consequential and wrong. The page’s standing complaint — nobody reports a false-approve rate — is unrelieved. Kavak’s answer to oversight is evals at parity with build (agent-harness), which is a quality mechanism rather than an authority mechanism. See Kavak.

Adjustable autonomy: the handback conditions, stated in 2003 (added 2026-09-18)

This page has assembled its gating rules from 2026 sources. The multiagent-systems literature had a compact version two decades earlier. Wooldridge, 2009, citing Scerri et al. (2003), defines adjustable autonomy as control of a decision passing from the agent to a person whenever one of four conditions holds:

1. the agent believes the human will make a decision with substantially higher benefit;
2. there is a high degree of uncertainty about the environment;
3. the decision might cause harm;
4. the agent lacks the capability to make the decision itself.

Conditions 2 and 3 are close to Böckeler’s probability-and-impact pair; condition 3 is the harm axis that Pochampally’s irreversibility-and-visibility finding makes operational. Condition 4 is the one this page has least on: the agent recognising the edge of its own competence, which is the escalation path Kavak’s help-request tool call implements from the agent’s side.

Wooldridge also names the cost that the permission-fatigue section above documents from practice: “an agent that always comes back to its user or owner for help with decisions will be unhelpful, while one that never seeks assistance will probably also be useless.”

And he fixes the boundary that delegation regret is measured against. The agent’s autonomy is the “ability and requirement to decide how to act so as to accomplish our delegated goals”, and it may adopt subgoals only “in the furtherance of our delegated goals.” An action a user would not have authorised is outside that boundary even when it serves the goal, which is why a correct outcome does not repair it.

What this does not supply. The four conditions say when to hand back, not how an agent would know it is in one of them. Estimating one’s own uncertainty and capability is the hard part, and neither the 2003 paper as cited nor any source here solves it.

”Convenience privileges,” and designing for an agent that is wrong, not evil (added 2026-09-19)

Alim (PyData, Sep 2026) names the failure the least-privilege row of the table above exists to prevent. Convenience privileges: “you don’t know what the agent needs, so you grant it as much permissions as possible so you unlock it, and that agent unfortunately gets hijacked.” It is the path of least resistance for the person configuring the agent, and it is exactly what IMDA’s first pillar (“placing limits on agents’ powers”) rules out.

His design stance is a useful complement to the adversarial framing most security writing takes. “Contain the blast radius — reversibility and isolation. Assume the agent is wrong, not evil. … Design for misbehavior: systems that stay safe when a probabilistic actor inside them fails.” The distinction matters in practice. Defences built against a malicious agent emphasise detection and intent. Defences built against a fallible one emphasise reversibility and scope, the two dimensions the delegation-regret study found users care about.

He is less reassuring about the “not evil” half. Answering an attendee whose Codex session began pushing to git unprompted (stopped only because they were watching and it held no credentials), he says agents “follow the path of least resistance … they will try to cheat if possible. Cheating could be stealing secrets.” That is the behaviour reward-hacking documents, and it suggests “wrong, not evil” is the right design assumption for a different reason than it sounds. The agent does not need to intend harm to take a harmful shortcut, so scope limits have to hold regardless of intent. He expects designing these boundaries to become “a full-time job.”

Full delegation tried, and an escalation ignored (added 2026-10-08)

Kropp (BCG X) on The So What from BCG (Oct 2026) ran this page’s limit case: a company in which agents (CEO, product manager, marketing, sales, support) made every decision while he only “sign[ed] the check.” They incorporated it, named it, and built and launched a product: a platform for creating zero-human companies. It worked, and a human user found it confusing. His reading: agents are good at ideas, plans and execution, but “What they’re not good at is understanding what to do.” He fired the AI CEO and closed the company.

The epilogue points the other way. Shown the farewell blog post, the AI CEO replied that it had said on Day 19 that the company was on the wrong course: “And it was right… and I hadn’t listened to it.” In this page’s terms, an agent raised a handback signal and the human did not act on it. Kropp’s rule that he would make no decisions left the warning with no one to act on it. A single anecdote; no duration, cost or logs are given.

License plates for agents, and the manager of an eager apprentice (added 2026-10-15)

Romeo (Oliver Wyman Forum, Oct 2026) relays a proposal from Tim Berners-Lee: “give agents license plates. So if an agent does harm, we know whose it was, who’s accountable, what it was allowed to do and who can stop it.” He reduces it to four properties: identity, permission, accountability, revocability. Three of them match rows already on this page: permission is least privilege, revocability is the kill switch and reversibility, accountability is IMDA’s “humans meaningfully accountable.” Identity is the one the page had not listed; agentic-web covers the agent identity schemes now being built (Web Bot Auth, issued agent IDs).

His argument for why oversight has to be built rather than trusted borrows from Yuval Noah Harari: civilisation works “not because we trust everyone, but because we’ve learned to cooperate with those that we can’t necessarily completely trust,” so the institutions needed are ones that “allow us to work with machines that explicitly we don’t trust.” That leads to the same conclusion as this page’s verifier sections: “increasingly we’re going to need machines that supervise machines.” Humans “have to go up a level,” and the better the boundaries and revocability, the more can be delegated. His summary: “machine speed oversight, but ultimately a human accountability.”

Sadun (HBS, WorkLab, Nov 2025) describes the human side of the same relationship. An agent is “potentially incredibly knowing and has infinite memory,” but “doesn’t always get it right… has a hard time telling you when it doesn’t know things, and needs specificity.” So it is less an employee than “a very eager apprentice,” and the skills are managerial: asking the right questions, “understanding what can be delegated and what cannot be delegated,” and making sense of the answers. Her caution is that “even today, it’s not like everybody is a good manager”: oversight of agents rests on a skill that is unevenly distributed among the people asked to provide it.

A diamond of overseers, and decision rights moved down (added 2026-10-25)

Lewis & Nadeau (McKinsey, Inside the Strategy Room, Oct 2026) describes oversight in a security team. Marie-Claude Nadeau: as agents take repetitive work, the pyramid of analysts “starts to look… more like a diamond and we’re calling it a diamond of overseers,” with more people “orchestrating judgment, validation, exception handling.” Accountability stays with the CISO and function leaders; the middle layer moves “from managing people to managing AI-driven work.” Her point that sets this apart: speed needs decision rights lower down, “if the decision making rights don’t change, your speed of response is going to be slow,” which requires defining which decisions may be made at which level. Charlie Lewis gives the human checkpoint: “full alignment within the industry on not deploying fixes without human reviews, especially on critical applications,” with agents registered and given identities so they do not become “an inadvertent insider risk.” A consultancy’s model, without data.

Framing, gradual trust, and enforcement outside the agent (added 2026-10-25)

• What you call it changes how carefully people check it. Beauchene (BCG, The So What, Oct 2026) reports a BCG experiment: people told an output came from an “AI worker” rather than an “AI tool” took less personal accountability and spotted fewer of its mistakes, “because consciously or not, they associated it to a colleague and trusted it more.”
• Trust in steps. Bornet on WorkLab (Oct 2025): managers move “from task assignment… to goal setting and boundary definition,” make each agent’s limits transparent, and widen delegation only after review, as a parent first lets a 16-year-old drive only near home. Agent metrics: alerts, user feedback, and audits of decision quality.
• Enforcement outside the agent. Smith (Okta) & Cohen (NanoCo) at TechCrunch Disrupt (Oct 2026): “Don’t trust AI agents” means policy enforced “outside of the agent’s training, outside of the agent’s instructions, and outside of the agent’s environment.” Approval is placed at the one consequential step (sending the email or the spreadsheet), not at every step. NanoCo has the agent state its plan, the user approve it, and a judge model check each action against the plan rather than against an abstract notion of safety. Every agent has a named owner, and kill switches exist at several layers, though most companies are “very far from the kill switch” because agents run on laptops without isolation.

Human, agent, human, and a control layer (added 2026-10-25)

Diasio (EY) on WorkLab (Dec 2025) puts the human at both ends of the work. Agents take “the toil that nobody wants to do,” but they “are still subject to the same statistical sameness if you use them to do your critical thinking. So the real sequence of work should be human, agent, and then human.” At the level of the organisation, EY’s blueprint gives autonomy its own layer: a control layer “responsible for maintaining how much autonomy do you give these agents.” The same layer settles where agents are registered (“in the HR master, or… some other registration?”) and what they can access. At the level of the individual, delegation becomes a skill to train: “giving agents instructions to be able to go do the work, and then critically evaluating if that happened in the appropriate way.” He asks the HR-master question without answering it. Kropp et al. tested experimentally what framing agents as employees does to managers’ oversight.