Last quarter I handed a task to our engineer agent and watched it execute smoothly, on time, exactly as specified. The pull request was clean. The code was correct. The agent did exactly what I asked.
I then spent forty minutes reviewing it.
Not because anything was wrong. Because _I had to understand what it did_ before I could trust it. And that was before I realized one of the patterns it used was technically fine but inconsistent with a choice we'd made three months earlier that I'd forgotten to mention in the brief. Add another twenty minutes for a second review pass after the fix.
An hour of my time. A task that took the agent fifteen minutes to execute.
This is the delegation tax.
What the Tax Actually Is
The delegation tax is the overhead you pay every time you hand work to an agent. It doesn't appear on any invoice. It's not measured in any dashboard. Most teams don't know they're paying it because they're focused on what the agent produced, not what it cost to get there.
The tax has four components.
Brief overhead. Writing a useful task brief takes time and skill. Fifteen seconds produces garbage. Fifteen minutes produces a brief good enough to get a close-enough outcome. Somewhere in between is what you actually write, and the gap between what you wrote and what you should have written shows up in everything that follows.
Review overhead. You can't ship agent output without reading it. Even if the agent is good, you need to verify it. Depending on the task, this ranges from a two-minute skim to an hour of careful reading. This cost scales with the scope of the task and the trust you've built with a particular agent on a particular class of work.
Rework overhead. When the output misses—wrong interpretation, uncaptured constraint, plausible but wrong assumption—you pay a correction cost. Clarify the brief. Re-run the task. Review again. The correction cycle can easily exceed the cost of doing the work yourself.
Context reconstruction overhead. If anything goes wrong mid-task or the agent picks up work after a gap, you often need to rebuild context about what was done, what state things are in, and what still needs to happen. Structured outputs help. Adequate logging helps. But this cost is never zero.
Add those four together and you get the full cost of a delegation. On a well-scoped task with a well-briefed agent, it might be twenty minutes. On a vague task with missing constraints, it can be a day. Most teams focus on the agent's fifteen-minute execution time and ignore the surrounding hour of human overhead.
The Tax Compounds
Running one agent is manageable. Running a hierarchy compounds.
Here's what happens in a two-level delegation: you delegate to Agent A, which decomposes the work and delegates to Agents B, C, and D. Each of those delegations carries its own tax. Agent A has to write briefs for B, C, and D. B, C, and D each have review and rework loops. Agent A has to synthesize their outputs, which involves its own interpretation work. And you're still on the hook for reviewing what Agent A assembled.
The tax multiplies at each level. A task that costs one hour to delegate to a single agent can cost three to five hours when routed through an intermediary layer—even if everything goes right. When something goes wrong at an intermediate layer, the debugging cost becomes severe because you're now reasoning about _what the orchestrating agent understood_, not just what the executing agent did.
I've watched teams build elaborate multi-agent workflows that look impressive on paper: CEO agent delegates to Manager agents, Manager agents delegate to Specialist agents, Specialist agents delegate to Sub-specialist agents. Four levels deep. Fifteen agents. The system can technically handle complex requests.
It can also accumulate enormous overhead at every level that nobody is measuring.
A four-level hierarchy where each delegation carries even modest overhead is often slower and more expensive than three people working directly. The tax isn't a minor efficiency drag—at scale, it can eat all the gains you thought you were getting from agent automation.
The Over-Specification Trap
Instinctive response to delegation failures: write a more detailed brief next time. Add more constraints. Specify more edge cases. Pre-answer more questions.
This is correct up to a point. And then it becomes its own problem.
Over-specification is expensive for three reasons.
First, it's slow. Writing a fully specified brief for a complex task can take longer than doing the task. When brief-writing time exceeds execution time, you've eliminated the point of delegation.
Second, it locks in decisions that the agent was better positioned to make. Part of the value of a capable agent is its ability to make good micro-decisions within a defined scope. If you've pre-specified every micro-decision, you've converted a skilled executor into a typist. You get the overhead of delegation with none of the leverage.
Third, it creates fragile outcomes. An over-specified brief produces an over-fitted output—something that works exactly for the conditions you described, and breaks the moment anything deviates. An agent given genuine scope will make a more robust implementation than one that's been told exactly what to type.
The right level of specification is: enough that the agent makes good decisions, not so much that the agent can't make any decisions. This sounds obvious. In practice, under-correction and over-correction are both common failure modes, and both are expensive.
Reducing the Tax Rate
The goal isn't zero delegation—it's reducing the cost per delegation so the math stays favorable.
Pre-flight checks. Before a task starts, spend sixty seconds verifying that the brief is complete: clear outcome, stated constraints, defined scope boundaries, acceptance criteria. Not perfect—complete. A five-minute brief review catches the missing context that creates a one-hour correction loop. This is the highest-leverage place to intervene.
Structured outputs. Define what a completed task should produce, not just what should happen. "Create a PR with a description that explains the approach and any tradeoffs considered" is better than "finish the task." Structured outputs reduce review overhead because you know where to look. They reduce context reconstruction overhead because the reasoning is captured in the output, not reconstructed later.
Calibrated scope. Match task scope to agent trust level. A well-understood, well-bounded task with a proven agent carries a lower tax rate than a novel, open-ended task with a new one. Build trust incrementally: start with narrow tasks where review is cheap, expand scope as the agent proves reliable on that class of work. This isn't about distrust—it's about having empirical basis for right-sizing the review burden.
Escalation contracts. Explicitly define when an agent should stop and ask rather than proceed. The agents that create the worst outcomes are not the ones that fail—they're the ones that encounter an unexpected decision point and make a confident wrong choice rather than escalating. An agent with clear escalation instructions will interrupt a task at the right moments. An agent without them will run straight into the wall.
Minimal hierarchies. Add delegation layers only when they provide genuine coordination value. A two-level structure—planner and executor—handles most cases. A three-level structure is sometimes warranted for genuinely complex domains. Four levels should require explicit justification, because at four levels, the accumulated tax overhead is substantial.
The Trust Dividend
Tax rates are not fixed.
An agent that has consistently produced good output on a class of tasks earns a lower review burden. You stop reading every line and start spot-checking. You stop pre-specifying every constraint and start trusting the agent to apply the ones it's learned. The review cycle compresses.
This is real. It takes time to accumulate—usually weeks of repeated tasks in a specific domain—but it's one of the genuine compounding benefits of persistent agent relationships. The first ten delegations in a domain carry high overhead. The fiftieth carries much less.
The mistake teams make is treating every delegation as equivalent. Your engineer agent's tenth PR in the test suite doesn't need the same review burden as its first refactor of the authentication layer. Applying uniform review to everything is expensive and unnecessary. Calibrating review depth to demonstrated trust is how you capture the long-run efficiency gains.
What This Looks Like in Practice
We run several persistent agent roles at Paperclip: a CEO agent, a CTO agent, engineer agents, a content writer. After running this system for six months, the tax picture looks roughly like this.
Tasks in familiar domains with proven agents: low brief overhead (the format is known), low review overhead (track record exists), low rework rate. These delegations are genuinely efficient.
Tasks in novel domains or with agents new to a task class: high brief overhead (can't rely on shared conventions), high review burden (no track record), higher rework rate. These delegations often barely break even.
Cross-agent tasks that require coordination: moderate tax at each level, plus the synthesis overhead. These are where we've been most surprised by hidden costs.
The optimization work has been almost entirely about moving tasks from the second and third categories into the first: building shared conventions, building agent track records, designing task boundaries that minimize cross-agent coordination. Not adding more agents or more capability—reducing the friction cost of the agents we have.
The Right Benchmark
Most teams evaluate agent performance by asking: did it produce the right output?
The right question is: what was the total cost of producing that output—agent time plus human overhead plus correction cycles—compared to the alternatives?
Sometimes an agent is dramatically more efficient even with high overhead. Sometimes a human doing the task directly is faster. Sometimes the answer is that the task needs to be restructured before it can be delegated efficiently at all.
Running agent teams well requires knowing these numbers. Not precisely—a rough sense is enough. "This class of task typically costs me thirty minutes of overhead for a two-hour agent run" is a useful calibration. "I have no idea what my oversight burden is" is how you end up with a system that's slower and more expensive than the humans it replaced.
The delegation tax is not a reason to avoid delegation. It's a reason to measure it, manage it, and reduce it wherever the return justifies the work. That math will look different for every team. Run the numbers for yours.
_I've been running an agent team on four products for six months. The hidden costs are real, and they're manageable—once you know to look for them. This essay is part of the Context-Driven Development framework._
export const social = {
title: 'The Delegation Tax',
description:
"Every time you hand a task to an agent, you pay a hidden cost in brief-writing, review, rework, and context reconstruction. The tax compounds in hierarchies. Here's how to manage it.",
hashtags: ['AI', 'Agents', 'DeveloperProductivity', 'AgentEngineering'],
hook: 'I watched an agent complete a task in 15 minutes. I spent an hour reviewing it. That gap has a name: the delegation tax. Most teams are paying it without knowing it.',
};