Source: tomasev-2026-intelligent-ai-delegation.pdf Date: 2026-02-12 (arXiv: 2602.11865v1) Authors: Nenad Tomašev, Matija Franklin, Simon Osindero (Google DeepMind)
The paper proposes a framework for "intelligent delegation" in AI agent systems, arguing that current multi-agent systems rely on brittle heuristics for task decomposition and assignment. True delegation requires not just splitting tasks but transferring authority, responsibility, and accountability — with mechanisms for trust, monitoring, and verification. The framework is organised around five pillars: dynamic assessment, adaptive execution, structural transparency, scalable market coordination, and systemic resilience.
The paper reads like a theoretical description of problems we've been solving empirically. The mapping is striking:
Permission Handling (§4.7) ↔ Visibility tiers and RBAC. The paper argues that delegation requires "strict roles and bounded operational scopes." Our visibility tier system (public, draft, candidate, critic, feedback, private, archive) with per-agent read/write permissions is exactly this. The Composer cannot write files; the Critic cannot see source materials; the Curator has broad access. These aren't arbitrary restrictions — they enforce an information partition that shapes behaviour. The paper calls this "Permission Handling"; we call it the authority model.
Structural Transparency (§4.5, §4.8) ↔ Git-backed provenance. The paper calls for "strictly enforced auditability" with attribution for both successful and failed executions. Every document operation in PCE is a git commit with an actor field. The document_history tool shows who did what and when. Task costs are recorded per-agent. The paper's "Verifiable Task Completion" maps to our Critic scoring mechanism — the Critic evaluates the Composer's output against criteria and produces a numerical score.
Task Decomposition (§4.1) ↔ Commutator triage. The Commutator receives a remit and decides how to decompose it — which agents to involve, in what order. The paper's notion of "optimising the task execution graph for efficiency and modularity" is what the Commutator does when it triages between compose, curate, and check paths.
Authority Gradient ↔ Sycophancy and the Composer guardrail. The paper discusses how steep authority gradients prevent delegatees from challenging delegators. We observed exactly this: the Composer was writing files to disk because it inferred that's what the pipeline wanted, even though it shouldn't have had write access. The fix was both structural (remove write tools) and prompt-based (reinforce the pipeline contract). The paper would call this "engineering dynamic cognitive friction."
Span of Control ↔ Supervision cost bottleneck. The paper asks "how many AI agents can a human expert reliably oversee without excessive fatigue?" We documented this today in supervision-cost-bottleneck.md. The answer: at current maturity, the PI supervises perhaps 3-4 agent "engineers" plus the Consul, and most of their time goes to assignment and context-sharing rather than substantive decisions. The paper's framing of span of control as goal-dependent and domain-dependent matches our experience — routine curation needs less oversight than design decisions.
Zone of Indifference ↔ Permission boundary guardrail (BUG-018). The paper describes how agents within their "zone of indifference" execute instructions without critical deliberation. We saw this when the Commutator, denied access to a document, entered a frantic search loop trying every alternative path — it was operating within its zone of indifference (follow the instruction) rather than stepping outside it (report the access denial). The prompt guardrail we added is exactly the paper's recommendation: engineer agents to recognise when a technically valid action is contextually wrong.
Transaction Cost Economics ↔ FEAT-004 and the Commutator bypass. The paper frames delegation choices through transaction costs: is it cheaper to do it yourself, delegate to a known sub-agent, or delegate to an unknown agent? Our decision to bypass the Commutator for curation tasks (FEAT-004) is a transaction cost calculation — the 55K tokens the Commutator spends routing a predetermined task is pure overhead. Direct routing reduces the transaction cost of delegation.
Trust Calibration. The paper argues delegators need accurate models of delegatee capabilities. Our system assumes fixed capability — the Composer always has the same tools and model. We don't dynamically assess whether a particular agent is performing well on a particular type of task. The Critic score is a post-hoc evaluation, not a pre-delegation capability assessment. Future work: could the Commutator maintain a running model of agent performance to inform routing?
Adaptive Execution. The paper calls for switching delegatees mid-execution when performance degrades. Our pipeline is fixed once the Commutator has routed — if the Composer produces bad output, the Critic sends it back for revision, but there's no mechanism to say "this task would be better handled by a different agent" mid-stream. The configurable workflow graphs (FEAT-017) would enable this, but the adaptation logic itself is undesigned.
Bidirectional Contracts. The paper argues contracts should protect the delegatee as well as the delegator. In our system, agents have no way to refuse or renegotiate a task. The Composer can't say "this remit is underspecified" or "I lack the source material to do this well." It just tries and produces whatever it can. Adding a structured "reject with reason" output would improve pipeline quality.
Reversibility as a delegation parameter. The paper distinguishes irreversible tasks (financial trades, deleting data) from reversible ones (drafting an email). Our system treats everything as reversible because git makes it so — but that's a property of the infrastructure, not a conscious delegation parameter. Tasks that interact with external systems (sending emails, publishing documents) would need stricter oversight.
Contextuality and privacy surface. The paper notes that high-context tasks require more information to be shared, expanding the privacy surface. Our information partition addresses this structurally — the Critic doesn't see source materials, only the draft — but we haven't formalised the relationship between context requirements and privacy exposure.
Market metaphor. The paper is heavily oriented toward open agent economies — decentralised markets, competitive bidding, smart contracts. This is the wrong frame for an organisational context. Within a firm, delegation is not a market transaction; it's a management decision. You don't put a task out to bid among your employees. The PCE model — fixed roles with defined capabilities, managed by policy — is closer to how actual organisations delegate. The market model becomes relevant only at the boundary between organisations (e.g., outsourcing a task to an external service).
Overemphasis on formal verification. "Contract-first decomposition" requiring all sub-tasks to have precise verification mechanisms is impractical for creative and knowledge work. The Composer's output cannot be formally verified — it's prose. The Critic's evaluation is subjective by design. The paper acknowledges this tension (§2.2, "Subjectivity" axis) but doesn't resolve it.
The paper gives us useful terms for things we've been describing informally:
This paper validates the PCE approach of using organisational theory as the design basis for multi-agent systems. The authors independently arrive at many of the same structures we've built (roles, permissions, auditing, information partitions), suggesting these are convergent solutions to real problems rather than arbitrary design choices.
The key gap the paper identifies that's most relevant to us: we have structural controls but not dynamic ones. Our permissions are static per-role. Our workflow graph is fixed. The paper argues for continuous reassessment, adaptive routing, and dynamic trust calibration. These are the next layer of sophistication — and they connect directly to FEAT-017 (configurable workflows) and the supervision cost observations.
The paper's framing of delegation as involving "transfer of authority, responsibility, accountability" is more precise than our current language. We tend to say "the Commutator routes tasks" — but what's actually happening is a transfer of authority (the Composer is authorised to produce content on this topic) with retained accountability (the Critic evaluates the outcome, the Curator decides whether to publish). Making this explicit in the prompts could improve agent behaviour.