Agentic delegation research is converging on the right requirements. The enforcement object is still missing.
In February 2026, researchers at Google DeepMind published Intelligent AI Delegation (Tomašev, Franklin, and Osindero, arXiv:2602.11865), a framework for how AI agents should delegate work to other agents and to humans. The paper deserves attention because its central move is correct: it treats delegation as a transfer of authority, responsibility, and accountability, with explicit roles, boundaries, and trust mechanisms, rather than as task routing between agents.1 That framing rejects the simplification that dominates multi-agent engineering, where delegation is whatever the orchestrator happens to do.
The paper also names the right risk dimensions. Its taxonomy of task characteristics includes two that are decisive for runtime governance: verifiability and reversibility.2 Its own examples of irreversible actions — executing a financial trade, deleting a database, sending an external email — are exactly the class of effect-bearing actions where after-the-fact review arrives too late by construction. And it concedes, from inside mainstream agentic-systems research, that current AI-to-AI delegation is too opaque to support robust oversight.3
All of that is progress. What follows is an analysis of where the framework stops, because where it stops is precisely where the unsolved engineering problem begins.
Where the framework's assurance actually lives
Read structurally, the paper's assurance mechanisms operate beside execution or after it.
Monitoring receives extensive treatment: outcome-level and process-level targets, direct and indirect observability, black-box and white-box transparency, privacy-preserving options, and transitive attestation across delegation chains.3 This is a genuinely useful map. It is also, in its entirety, a map of observation. Monitoring produces evidence of what occurred. Runtime authorization produces evidence of what was permitted before occurrence. These are different evidentiary objects, and no refinement of the first becomes the second.
Verifiable task completion, the framework's settlement layer, has the same character. Verification there transforms a provisional output into a settled fact: payment releases, reputation updates, liability attaches, disputes resolve. Valuable machinery. But it answers the question "was the delegated work completed to specification?" A regulated deployment must also answer a prior question: was this effect-bearing action authorized before it executed, and can that verdict be independently reconstructed? Signed completion credentials, escrow bonds, reputation ledgers, and recursive attestations create accountability trails.4 They do not create an authorization verdict that existed before the action did.
Permission handling: adjacent, not equivalent
The framework comes closest to the boundary in its treatment of permissions, and the section rewards close reading. High-stakes domains, it argues, require risk-adaptive, just-in-time permissions, strictly scoped to the task, gated where appropriate by human or third-party approval. It adds privilege attenuation across recursive delegation chains, semantic constraints on operations, automated revocation, algorithmic circuit breakers, and policy-as-code for auditing permission rules.5
This is scoped access done seriously. It is still not authorization. Permission management answers the question of who may hold which credentials over which resources. Authorization answers whether this specific proposed action, evaluated against binding policy, in current context, is permitted to execute now, and it answers with a verdict. An agent holding a perfectly scoped, just-in-time credential can still propose a harmful action inside that scope. The paper's own examples of irreversible side effects — including financial trades, database deletion, and external email — describe the relevant class of risk.2 Access is a precondition of the problem, not the solution to it.
Requirements stated, mechanisms absent
The most interesting passages in the paper are the ones that state requirements the framework itself does not mechanize.
Its liability-firebreak construct requires that an agent facing downstream risk it cannot insure must "halt execution and request an updated transfer of authority" from the human principal.6 Structurally, that is an abstention that blocks execution and transfers custody to an authorized human. The paper does not specify what object records that abstention, what evidence accompanies the custody transfer, or what guarantees the halt is not bypassed.
Its discussion of safety floors argues that certain classes of tasks require mandatory verification steps that cannot be traded away for speed or cost, because competitive markets will otherwise price safety out.7 Structurally, that is a non-bypassability requirement. The paper does not specify the architectural property that makes a verification step non-bypassable rather than merely mandated.
Its treatment of the zone of indifference calls for agents capable of recognizing when a technically permissible request is contextually ambiguous enough to warrant challenging the delegator or requesting human verification.8 Structurally, that is the trigger condition for an abstaining verdict. The paper frames it as a capability agents should have, not as a verdict a boundary must render.
In each case the requirement is right, and in each case the same two questions go unanswered: what artifact satisfies the requirement, and what happens when that artifact cannot be produced?
The missing objects
Three things are absent from the framework, and they are the three things that convert delegation governance from coordination into enforcement.
The first is the authorization artifact: a verdict, rendered before execution, by a decision procedure whose inputs are policy, context, and the proposed action specification, represented in a form sufficient for an independent third party to reconstruct the verdict without access to the internal state of the system that proposed the action. Without this object, delegation may be coordinated, credentialed, monitored, and settled, but nothing in the record establishes that any given effect-bearing action was permitted before it happened.
The second is the runtime authorization boundary: the enforcement point interposed between proposed action and execution, where that artifact is produced and where release is conditional on it. The framework's protocol survey makes the absence concrete. As presented there, existing agent protocols require added fields or streams to carry delegation-specific verification, monitoring, bidding, and permission-attenuation semantics. The paper's proposed extensions are therefore evidence that native protocol semantics still do not carry the full authorization object.9
The third is the failure rule. A system claiming pre-execution authorization requires closed verdict semantics: every proposed effect-bearing action resolves to ALLOW, DENY, or ABSTAIN, where ABSTAIN blocks execution pending authorized human override, and escalation is a consequence of ABSTAIN rather than a fourth verdict. Every indeterminate state — the policy engine unavailable, the context stale, the artifact unproducible — resolves to a blocking outcome. The framework contemplates human oversight, tiered approvals, circuit breakers, and revocation, but nowhere commits to the rule that non-authorization means non-execution.
This distinction is not new to FERZ's work. FERZ's prior publications on observability-based authorization and the authorization artifact gap argued that governance of effect-bearing AI actions cannot be satisfied by monitoring, logging, or completion review. See, for example, On the Impossibility of Observability-Based Authorization and the Five Tests Standard.10 The control has to exist before execution, at the point of release, and it has to produce an authorization artifact from which the verdict can be independently reconstructed. Agentic delegation makes that requirement more visible, but it does not change its structure.
What this means for delegation infrastructure
The paper's value is that it makes the delegation problem explicit. Its limitation is that it leaves the enforcement object underspecified. That gap matters because regulated systems do not merely need to know who delegated a task, or whether the task was later completed. They need to know whether the specific effect-bearing action was authorized before it executed.
The useful move in this paper is treating delegation as authority transfer rather than task routing. The unresolved engineering question is narrower: what artifact authorizes an effect-bearing delegated action before release, and what happens when that artifact cannot be produced? In regulated systems, observability and completion verification do not close that gap. The control has to sit at the runtime authorization boundary and fail closed.
Delegation infrastructure becomes governable when authorization is native to it: when the protocols that carry intents, bids, contracts, and settlements also carry verdicts, and when the absence of a verdict is, by architecture rather than by policy aspiration, the absence of execution. Frameworks like this one are mapping the territory with increasing precision. The boundary still has to be built.
Notes
FERZ, Inc. builds runtime authorization infrastructure for AI systems in regulated industries. The research corpus underlying this analysis, including the Five Tests Standard and the impossibility result for observability-based authorization, is published at github.com/edmeyman/4ts-standard and on Zenodo.
Footnotes
-
Tomašev, N., Franklin, M., and Osindero, S. (2026). Intelligent AI Delegation. arXiv:2602.11865, submitted February 12, 2026. Definition of intelligent delegation, including transfer of authority, responsibility, accountability, roles, boundaries, intent, and trust mechanisms: Section 2.1. ↩
-
Task characteristics, including verifiability and reversibility, and the examples of irreversible actions such as financial trades, database deletion, and external email: Tomašev et al. (2026), Section 2.2. ↩ ↩2
-
Structural opacity of AI-to-AI delegation: Tomašev et al. (2026), Section 4, "Structural Transparency"; monitoring taxonomy: Section 4.5. ↩ ↩2
-
Verifiable task completion and settlement mechanisms, including credentials, escrow, reputation, and dispute resolution: Tomašev et al. (2026), Section 4.8. ↩
-
Permission handling, privilege attenuation, automated revocation, circuit breakers, and policy-as-code: Tomašev et al. (2026), Section 4.7. ↩
-
Liability firebreaks and updated transfer of authority: Tomašev et al. (2026), Section 5.2, cross-referencing the reversibility discussion in Section 2.2. ↩
-
Safety floors and mandatory verification constraints that cannot be bypassed for efficiency: Tomašev et al. (2026), Section 5.3. ↩
-
Zone of indifference and dynamic cognitive friction: Tomašev et al. (2026), Section 2.3. ↩
-
Protocol survey and proposed protocol extensions for verification, monitoring, bidding, and permission attenuation: Tomašev et al. (2026), Section 6.1. ↩
-
Meyman, E. On the Impossibility of Observability-Based Authorization, Technical Note v1.4.0, FERZ, Inc., Zenodo concept DOI: 10.5281/zenodo.19647542, published June 22, 2026. Meyman, E. Five Tests Standard (5TS), FERZ, Inc., Zenodo concept DOI: 10.5281/zenodo.21040295, published June 29, 2026. See also Meyman, E. Verifiable AI Governance: The Five Tests Standard (5TS) and Proof-Carrying Decisions, Zenodo concept DOI: 10.5281/zenodo.21048661, published June 30, 2026. The predecessor Four Tests Standard, defining the Stop, Ownership, Replay, and Escalation tests and the Proof-Carrying Decision object, was published in November 2025: Meyman, E. Verifiable AI Governance: The Four Tests Standard (4TS) and Proof-Carrying Decisions, ResearchGate publication 397176413, November 2025; 4TS Technical Specification v1.0.2, ResearchGate publication 397738710, November 2025; specification and conformance bundle at github.com/edmeyman/4ts-standard, first published November 18, 2025. ↩