The Tower of Hanoi Is the Best Lesson in Delegation I Know

This week I built a Tower of Hanoi for the Lab. I expected a weekend toy. What I got was the clearest picture I have of a skill I use every day and rarely explain well: handing work to someone else, human or agent, without losing control of the outcome.

The puzzle has three pegs and a stack of discs. You can solve it in your head for three discs. For eight you cannot, unless you stop trying to hold the whole plan and start trusting a smaller version of yourself to handle most of it. That trust is the whole trick. It is also exactly what a good brief to a Claude Code subagent, a contractor or a team lead has to earn.

The puzzle, in one paragraph

The Tower of Hanoi is a puzzle where you move a stack of discs from one peg to another, one disc at a time, never placing a larger disc on a smaller one. The French mathematician Édouard Lucas published it in 1883 under the pen-name N. Claus de Siam, an anagram of “Lucas d’Amiens,” and sold it with a legend: temple priests moving a tower of 64 golden discs, and the world ending when they finish (the history is summarised here).

Play a round before reading on. The point lands harder in your hands than in my prose.

If you solved four discs in fifteen moves, you probably noticed something halfway through. You stopped thinking about individual moves and started thinking in chunks: get the top three out of the way, move the big one, put the three back. That shift is recursion. It’s also the moment a manager stops doing the work and starts directing it.

Recursion is delegation with a contract

Recursion solves a problem by handing a smaller copy of it to a sub-call that you trust to finish. The whole solution for n discs is three lines: move n − 1 discs out of the way to the spare peg, move the largest disc to the goal, move the n − 1 discs back on top of it.

Notice what the top-level call does not do. It does not plan the n − 1 moves. It does not check each one as it happens. It writes two briefs, makes one move with its own hands, and waits. The sub-calls do the same thing one level down, and so on, until somebody is handed a single disc and simply moves it.

Run the chart and watch who is busy. At any moment exactly one node is moving a disc. Every node above it is waiting on a report. For four discs there are fifteen calls and fifteen moves, and nobody, including the top of the chart, makes more than one. Seniority in this org is not doing more of the work. It is owning a larger outcome and being responsible for a better brief.

I spent a long time in enterprise product management before I started building alone, and the failures I remember were rarely failures of effort. They were failures at the boundary between levels: a team handed a goal without the constraint that mattered, or a constraint without the goal. Hanoi makes that boundary explicit. A sub-call is useless if it is told to move three discs but not where to.

The brief is the recursive call

A delegation brief works when it carries every argument the sub-call needs, because the sub-call has no other way to know them. Look at the signature: hanoi(n − 1, from, to, via). Each argument is a line in a brief.

• To is the outcome. Not the activity, the state of the world when they are done.
• n − 1 is the scope: exactly which discs are theirs.
• Via is the working space they may use. The spare peg is a resource, and a sub-call that does not know it exists cannot do the job.
• The rule, never a larger disc on a smaller one, is the invariant that holds everywhere, at every level.
• Disc n is out of bounds. It is the one you are keeping. Touch it and the whole plan collapses.
• Return is the definition of done: the smaller tower stands on the named peg, in order, and the caller can see that without asking.

That mapping is almost literally how agent delegation works now. Anthropic’s Claude Code documentation on subagents describes each subagent as running in its own context window, with its own system prompt and tool access, and returning only a summary to the main conversation. In other words, the sub-call cannot see your head. It sees the brief. The docs also note that subagents can spawn their own subagents, up to three layers below the main conversation by default, which is a recursion tree with a depth limit.

I learned the cost of a bad argument the expensive way. On Ballistica, my game project, I run agents in waves of parallel lanes, each working from a written brief. In one wave, the briefs themselves were wrong six times, and two lanes rediscovered work that had already been closed. The agents did what they were told. The calls had the wrong arguments. The fix was a rule in my own project file: every defect a brief names cites a commit or a file and line, or is labelled unverified until someone checks it. It is the to parameter, enforced. My earlier write-up on the four rules in one CLAUDE.md covers the standing-instructions half of the same problem.

The obvious move is the wrong one

Greedy delegation, making whatever move shows the most visible progress toward the goal, fails on the Tower of Hanoi in a way you can count. It is the clearest example I know of why a manager who measures progress by what’s on the goal peg will get lost.

Start with the very first move. The smallest disc wants to go straight to the goal. For an odd number of discs that is correct. For an even number it is wrong: the optimal first move is to the spare peg, away from where you are trying to go. Send it to the goal anyway and the best you can then do costs one extra move. Small, but it is the shape of the whole problem: the right step sometimes looks like moving backwards.

Now make that instinct a policy and let it run.

The blind version walks back into a position it has already been in on its ninth move, for every tower size I tested, three to eight discs. It would circle forever. Give it a memory, so it refuses to repeat a position, and the outcome splits by parity. With an odd number of discs it paints itself into a corner and stops. With an even number it gets there eventually: 23 moves against 15 for four discs, 731 against 255 for eight, nearly three times the work.

I see this in product teams constantly. The roadmap that ships the most visible items each sprint looks like progress and keeps undoing itself. The recursive manager looks slower at first, because many of its early moves put discs on the spare peg, on purpose, to clear the way. Clearing the way is the work.

Exponential work, constant management

Decomposition does not reduce the total work of the Tower of Hanoi. The minimum is 2ⁿ − 1 moves whichever way you think about it. What decomposition reduces is how much any single participant has to hold.

Without the recursion, a planner has to reason about the puzzle as one flat space, and that space has 3ⁿ positions, every arrangement of n discs on three pegs. With the recursion, the person at the top makes one move and writes two briefs, at any size. Scroll through the chart and watch the three lines separate.

This is the honest version of the claim people make about AI agents. Agents don’t make hard work small. A large job with a clean decomposition is still a large job, and every subagent’s requests count against the same usage limits as the main conversation, according to the same documentation. What a decomposition buys you is that nobody, human or model, has to hold the whole 3ⁿ space in one context. The cost moves from comprehension to coordination, and coordination is what briefs are for.

The legend makes the scale concrete. At one move a second, 64 discs take 2⁶⁴ − 1 seconds: about 585 billion years, roughly 42 times the age of the universe. The Lab version lets you buy faster priests. At a billion moves a second, you still wait 585 years. A faster worker does not rescue a problem that doubles.

Where the analogy breaks

The Tower of Hanoi is a perfect delegation story because its sub-calls never fail, never misread the brief and never disagree. Real delegation does all three, so the metaphor needs three corrections before you use it.

Returns need checking. In Hanoi, “done” is visible: the tower is on the peg or it isn’t. In real work, a sub-agent reports success in the same confident tone whether or not it succeeded. Define the check before you delegate, and run it on what comes back. I wrote about this in agent evaluation before shipping; the short version is that a final-state check beats a status message.

Sequential is not parallel. Hanoi’s two sub-calls cannot run at the same time; the second needs the first to finish and the big disc to move. Plenty of real work is like that. Spawning ten agents on a dependent chain produces ten agents waiting, or worse, ten agents guessing. Parallelise the independent branches only.

The person at the top still signs. The recursive manager’s one move is the move nobody else may make. In my experience that is usually the decision with consequences: the merge, the send, the spend. More sub-calls mean more returns to review, which is the bottleneck I described in More Agents. One Person Who Signs Off.

Write your next brief as a function call

A good delegation brief is a function call with every argument filled in, plus a return value you can check. Pick one task you will hand off this week, to an agent or a person, and run it through the builder.

GOAL
The checkout page shows the correct tax for Florida addresses.

YOUR SCOPE
src/lib/tax.ts and its tests. The bug, and only the bug.

YOU MAY USE
Read anything in the repo. Run bun test. Create a scratch branch.

NEVER BREAK
Existing passing tests stay passing. No new dependencies.

DO NOT TOUCH
The payment flow, the Stripe calls, the database schema.

DONE MEANS
A failing test for the Florida case that now passes, and the full suite green.

REPORT BACK WITH
Files changed, the test output, and anything you noticed but did not fix.

If something outside your scope is blocking you, stop and tell me what and why. Don’t work around it.

Three habits keep this honest. Write the brief so it would work if you were unreachable until the work is done, because for a subagent you effectively are. Keep the “disc n” line explicit; the thing you are not delegating is the thing most likely to get touched. And if you notice yourself writing a brief for work you could not describe the result of, stop: you are not ready to delegate it, and no amount of ambitious prompting will fix an outcome you haven’t named.

You can’t move n discs alone. You can write the call that moves n − 1.

The full puzzle, with three to ten discs, a hint engine that works from any position, and the recursion drawn live as it runs, is in the Lab: Tower of Hanoi.

FAQ

Sources

Checked October 2026. Move counts, durations and the greedy results are computed by the puzzle code that powers these exhibits, which is tested against a brute-force search.

1. Tower of Hanoi — Wikipedia (Lucas, 1883; the 64-disc legend; 2⁶⁴ − 1 moves)
2. Create custom subagents — Claude Code Docs