Agent Delegation

Delegation is not merely saying “you do this.” The system must choose an agent that has the skill, permission, time, and reliability needed for that specific subtask.

Subtask → capability check → permission check → cost/latency check → delegate

What You Will Learn

• How an orchestrator selects an agent for a subtask.
• How capability, price, latency, reliability, and permissions affect routing.
• How to detect and recover from a poor delegation decision.

Module 4 covered how work gets divided. This module covers a separate question: once a subtask exists, which specific agent should actually handle it?

Complex Task
     ↓
Planner
     ↓
Subtasks
 ┌───┼────┐
 ↓   ↓    ↓
A1  A2   A3

That diagram looks simple. The decision behind each arrow — why this subtask went to that agent — is where real engineering judgment lives.

What actually happens behind each arrow, step by step

Subtask exists, ready for delegation
     ↓
Check capability: which agents can do this?
     ↓
Check current reliability: how has each candidate performed
on this specific task type recently?
     ↓
Check cost tier: does this subtask need the
strongest available model, or would a cheaper one suffice?
     ↓
Check permissions: is each candidate actually authorized
for this subtask's scope?
     ↓
Select the agent that clears every check
     ↓
Delegate, with authorization scoped to this subtask only
     ↓
Log the decision and its criteria for later evaluation

Notice the order here is deliberate, not arbitrary. Capability is checked first because there’s no point weighing cost or latency for an agent that can’t do the task at all. Permissions are checked last among the candidate-narrowing steps specifically because it’s the one criterion that can disqualify an otherwise perfect candidate outright — an agent capable of the work, cheap, fast, and reliable is still the wrong choice if it isn’t authorized to touch what this specific subtask requires.

---

Delegation is a decision with real criteria, not a coin flip

A delegation decision weighs several things at once:

• Capability — can this agent actually do this task well?
• Cost — what does running this agent cost, per task?
• Latency — how fast does this agent respond?
• Reliability — how consistently does this agent get it right?
• Permissions — is this agent even authorized to do this?

Get any one of these wrong and the failure shows up differently. A capability mismatch produces bad output. A cost mismatch produces a bill nobody budgeted for. A permissions mismatch produces a security incident — a real one, covered later in this module.

Criterion	Gets it wrong →	hard because
Capability	Bad or incomplete output	Capability isn’t binary — an agent can be strong at one task type and weak at an adjacent one
Cost	An unplanned, oversized bill	The cheapest option that looks adequate can fail silently, not visibly
Latency	Users waiting on a decision that itself takes time to make	The routing decision has its own real cost, easy to forget when optimizing the task it routes to
Reliability	Repeated, undiagnosed failures	Averaged scores hide task-specific weaknesses that matter more than the average
Permissions	A security incident	Authorization standards for delegation are still actively being defined, not solved

Each of these gets real treatment below — not as an abstract list, but with current, dated evidence for why getting each one wrong has happened to real systems.

---

Capability matching: the counter-intuitive part

The obvious intuition is that capability matching means “send hard tasks to strong agents, easy tasks to weak ones.” That’s correct, but it misses something more important that real production teams have learned the hard way.

The agent doing the delegating needs to be at least as capable as the hardest task it’s deciding about — even if it never executes that task itself.

A documented 2026 production pipeline makes this concrete. In a coding-agent system, the Coordinator agent — the one that analyzes a codebase, drafts a spec, and delegates tasks to specialist agents — is specifically where the strongest available model earns its cost. The reasoning, stated directly: “A weaker model at this stage produces malformed task decompositions that no downstream specialist can recover from.” (Augment Code, Best AI Model for Coding Agents in 2026)

Read that carefully. It’s tempting to assume the delegating agent’s job is “easy” — it just routes work, it doesn’t do the hard reasoning. That’s backwards. A bad decomposition poisons every subagent downstream of it, no matter how capable those subagents are individually. The delegator’s mistake doesn’t stay contained to one subtask — it propagates to all of them.

This is directly the same lesson Module 4 taught about task allocation: get the upfront decision right, and downstream execution goes smoothly. Get it wrong, and no amount of downstream capability can fully recover.

---

Cost: what capability-matched delegation actually saves

This is where delegation decisions get measured most concretely, because the numbers are large.

RouteLLM, a peer-reviewed approach to sending each request to the cheapest model actually capable of handling it, reported up to 85% cost savings while retaining 95% of GPT-4 performance on MT-Bench in its controlled evaluation. The same work reported cost reductions of 45% on MMLU and 35% on GSM8K at the stated quality target. These are benchmark-specific routing results, not a promise that every delegation system will save 85%. (RouteLLM project; LMSYS explanation; paper)

The general industry pattern by 2026: route simple tasks to a small model (Haiku-class), reserve flagship models for hard tasks, and the reported cost reduction runs 5 to 10x. (EITT, AI Agents 2026 Guide)

The honest failure mode

Cost-based delegation isn’t free money, and it’s worth being precise about how it actually fails. If the delegation decision misjudges a task’s real difficulty and routes it to a model too weak to handle it, the savings don’t just disappear — they go negative:

“If your router misjudges and pushes hard prompts to the small model, the savings evaporate into retries, escalations, and the silent quality regression.” — Digital Applied, LLM Model Routing in 2026

That word silent matters. A retry or an escalation is at least visible — you can measure it. A silent quality regression means the delegation decision was wrong and nothing told you. This is precisely why the evaluation discipline from your previous course applies just as much to delegation decisions as to any other part of an agent system.

---

Latency: the decision itself isn’t free

This is a underrated cost most delegation discussions skip. Deciding who should do the work takes real time, before the work even starts.

Delegation method	Added latency
Rule-based (regex, keyword match)	Under 1 ms
Embedding-based routing	About 5 ms
Semantic routing / ML classifier	50–100 ms

(Digital Applied, LLM Model Routing in 2026)

One honest observation worth repeating directly: “Vendor content never mentions that the router itself adds latency — it has to look at the request before it can route it.”

For most tasks, this overhead is small relative to the actual inference that follows. But it’s not zero, and a delegation system that adds a 100ms classifier in front of every single request — including the trivial ones that didn’t need sophisticated routing at all — is paying a real, compounding cost for a decision that, for most of those requests, could have been made with a 1ms rule instead.

---

Reliability: delegation decisions need their own track record

An agent’s reliability isn’t static — it varies by task type, and a delegation system tracks this rather than assuming a fixed capability score.

A production-grade delegation decision considers not just “can this agent theoretically do this,” but “how consistently has this specific agent gotten this specific kind of task right recently.” This is directly related to the observability discipline from your previous course — without tracking per-agent, per-task-type success rates, a delegation system has no real signal to improve its own decisions over time, and repeats the same misjudgments indefinitely.

What this actually looks like in practice

Concretely, this means a delegation layer should maintain something closer to a per-agent scorecard than a single static rating:

• Success rate by task category — an agent might excel at boilerplate contract clauses while performing poorly on novel liability language, and a single averaged score hides that difference entirely
• Recency weighting — a model update, a prompt change, or a tool becoming unavailable can shift an agent’s real reliability overnight; a track record that treats last month’s performance the same as yesterday’s will react too slowly to a regression
• Escalation frequency — an agent that technically “succeeds” but frequently needs a human or a Critic agent to intervene isn’t actually reliable in the sense that matters for delegation, even if its raw completion rate looks fine

Without this granularity, a delegation system can’t distinguish “this agent is broadly unreliable” from “this agent is excellent at 90% of what it receives and consistently wrong about one specific, identifiable slice” — and those two situations call for completely different fixes. The first calls for replacing the agent. The second calls for refining what gets delegated to it, which is a delegation decision, not an agent-quality problem at all.

---

Permissions: the criterion with the sharpest real consequences

This is worth taking as seriously as capability, because getting it wrong doesn’t just produce bad output — it produces a security incident.

Current research on delegation authorization

Delegation isn’t just “which agent is capable” — it’s also “which agent is authorized, and with what scope.” This has become active, current research territory. Google DeepMind’s own 2026 paper on “Intelligent AI Delegation” proposes Delegation Capability Tokens — a scoped, attenuable authorization mechanism built on a cryptographic technique called macaroons, specifically so that when Agent A delegates to Agent B, the authorization Agent B receives can be narrower than what Agent A itself holds, never broader. (AIP: Agent Identity Protocol, arXiv)

A broader 2026 survey found that despite multiple partial proposals — from Google DeepMind, Mastercard’s agent-commerce work, and several IETF draft standards — no single implemented protocol yet combines every requirement real delegation authorization needs: offline-verifiable scoping, chained policy across multiple delegation hops, and provenance tracking across both MCP and A2A. (AIP, arXiv)

Worth sitting with: as of this writing, delegation authorization is less mature than delegation mechanics. The industry has largely solved “how do agents hand off work” and is still actively working out “how do we prove that handoff was actually authorized.”

A real, dated security incident

This isn’t a hypothetical risk. In March 2026, specific versions of LiteLLM — a widely-used routing and delegation proxy for multi-model AI systems — were found to contain malicious code targeting cloud credentials, SSH keys, and Kubernetes secrets, causing affected production systems to experience runaway processes. (Augment Code, 5 Best Model Routing Platforms)

The incident was scoped to specific package versions, not the entire routing-infrastructure category — but it illustrates something important about permissions in delegation systems: the component making delegation decisions sits at a privileged point in your architecture. It sees every request and decides where authority flows next. Compromising that single component compromises the trust boundary for everything downstream of it.

---

Applying this to a concrete scenario

Back to the legal-contract review pipeline — Planner, Executor, Critic — now through a delegation lens specifically.

Capability matching. The Planner, which decides how to decompose the contract into checklist items, is exactly the “Coordinator” role from the coding-pipeline example above. A weak model here produces a poorly-scoped checklist — the same overlapping-scope problem from Module 4 — and no amount of Executor or Critic quality downstream can fully compensate for a checklist that was wrong from the start.

Cost. Not every checklist item needs the same model tier. A boilerplate termination clause matching a known template is a good candidate for a cheaper, faster model; a unusual liability clause with no clear precedent is exactly where the delegation decision should reserve the stronger model — precisely RouteLLM’s underlying logic, applied to legal review instead of general queries.

Permissions. If this system ever delegates to a third-party or externally-hosted specialist agent — say, a vendor-provided compliance-checking agent — the Delegation Capability Token concept becomes directly relevant: that external agent should receive authorization scoped only to the specific contract section it’s reviewing, never the full document repository the Planner itself has access to.

Reliability. Suppose the Executor agent performs well on payment and termination clauses but consistently produces weak comparisons for liability language specifically — a pattern only visible if success is tracked per clause type, not as one aggregate Executor score. The correct fix isn’t replacing the Executor. It’s routing liability clauses specifically to a more capable model or a human reviewer, while leaving the Executor’s strong performance on everything else untouched.

---

Interview-relevant framing

Q: How would you design a delegation system to control cost without sacrificing quality?

Ans: I’d start with rule-based routing for obvious cases — that’s under a millisecond of overhead — and reserve heavier classification for requests that are actually ambiguous. Critically, I wouldn’t make the delegation decision itself using a weak model, even though it feels like the ‘cheap’ part of the pipeline — a 2026 production example showed the coordinator making decomposition decisions needs to be at least as capable as the hardest task it’s deciding about, because a bad decomposition poisons every downstream agent regardless of how capable they are individually.

Q: Why does delegation permission scope matter, and how would you enforce it?

Ans: Because the component making delegation decisions sits at a privileged point in the architecture — it decides where authority flows. The real LiteLLM incident in March 2026 showed what happens when that trust boundary is compromised: real credential and secret exposure, not a theoretical risk. I’d want delegated authorization to be narrower than the delegator’s own permissions at every hop, the way Google DeepMind’s Delegation Capability Tokens are designed — attenuating scope on each handoff rather than passing full authority downstream by default.

A third question worth preparing for:

Q: How would you tell the difference between an unreliable agent and a poorly-scoped delegation decision?

Ans: By checking whether an agent’s failures cluster around a specific task category or spread evenly across everything it receives. An agent that’s excellent at 90% of its work and consistently wrong on one identifiable slice doesn’t need to be replaced — it needs the delegation logic refined so that specific slice routes elsewhere. Treating that as a general reliability problem and swapping the agent entirely would lose the 90% it was good at, to fix a problem that was actually about what got delegated to it, not the agent itself.

Common Misconception

Incorrect idea: The most capable model should receive every subtask.

Why it is incorrect: The best delegate is capable enough and also satisfies permission, cost, latency, availability, and reliability requirements.

Key takeaways

• Delegation is a distinct decision from task allocation — it’s specifically about which agent handles a subtask, weighed against capability, cost, latency, reliability, and permissions.
• The delegating agent itself needs strong capability, not just the agents it delegates to — a documented 2026 production pipeline found a weak coordinator produces malformed task decompositions no downstream specialist can recover from.
• Capability-matched cost routing can work well — RouteLLM reported up to 85% cost savings while keeping 95% of GPT-4 performance on MT-Bench — but that is a benchmark-specific result, and a misjudged routing decision produces a silent quality regression, not just a visible retry.
• The delegation decision itself has real latency cost — from under 1ms for rule-based routing to 50–100ms for heavier ML classifiers — and applying expensive routing logic to every request, including trivial ones, is its own real inefficiency.
• Reliable delegation requires tracking per-agent, per-task-type success rates over time, not a fixed, assumed capability score.
• Delegation authorization is less mature than delegation mechanics as of 2026 — active research (Google DeepMind’s Delegation Capability Tokens, multiple competing IETF drafts) has not yet converged on one complete, implemented standard.
• A real, dated security incident (LiteLLM, March 2026) shows delegation infrastructure is a privileged attack surface — compromising the component that decides where authority flows compromises everything downstream of it.

Module 6 moves from delegation decisions to the coordination layer that actually executes them at scale: orchestration — the general problem of managing an entire multi-agent system’s execution, not just one handoff at a time.