6.2.4 · D2AI Agents & Tool Use

Visual walkthrough — Planning and task decomposition

1,725 words8 min readBack to topic

Related building blocks: 5.3.02-Chain-of-thought-prompting (reasoning inside one model call), 6.2.01-Tool-augmented-LMs (why real agents can't do it all in one pass), 6.2.03-Multi-agent-systems (who runs the parallel pieces), 8.1.03-Reasoning-under-uncertainty (what happens when steps can fail).


Step 1 — What "search" even means for an agent

WHAT. Imagine an agent standing at a starting point. It can take one of several actions (search the web, run code, call an API). After each action it lands in a new situation and again faces a choice of actions. We call each choice-point a node, and each action an edge leading to the next node.

WHY. Before we can count how hard a task is, we must picture the shape of all the ways it could unfold. That shape is a tree: one root (where we start), branching out.

PICTURE. Below, the black dot at the top is the start. From it, arrows fan out — is simply the number of actions available at each step. Every arrow lands on a new dot, and each of those fans out again.

Figure — Planning and task decomposition

Step 2 — How deep, and how many leaves

WHAT. A task rarely finishes in one action. It takes several actions in a row. The number of actions in a row before we reach the answer is the depth, written .

WHY. Difficulty isn't just "how many choices" — it's "how many choices, repeated how many times". Each extra level multiplies the branches again. That multiplication is the whole story.

PICTURE. Count the dots at the bottom row. Level 1 has dots. Level 2 has dots (each of the split into ). By level we have multiplied by itself times:

Figure — Planning and task decomposition

Step 3 — Why is a catastrophe (feel the number)

WHAT. Let's put real numbers in. Say (ten tools/queries to pick from) and (six steps deep).

WHY. Symbols hide how violent exponential growth is. One concrete plug-in makes it visceral: this is why an agent that tries to plan everything in one giant search simply cannot finish.

PICTURE. Each bar is one more level of depth. The height is the running total of paths. Watch it rocket from 10 to a million in six short steps.

  • — after step 1
  • — after step 2
  • — after step 6
Figure — Planning and task decomposition

A million grounded tool calls to answer one question is impossible. This is the pain decomposition cures.


Step 4 — The trick: chop the goal into independent pieces

WHAT. Suppose the big goal secretly splits into subgoals that don't depend on each other. Each subgoal only needs a fraction of the total depth: steps instead of .

WHY. This is the key insight. Total work of depth shared out equally among helpers means each helper only goes deep. And crucially — because the subgoals are independent — we do not multiply their costs together; we add them.

PICTURE. One tall tree of depth (left, red, monstrous) becomes short trees each of depth (right, violet, tiny). The tall tree's leaf count is . Each short tree has only leaves.

Figure — Planning and task decomposition

Step 5 — Add the little trees: the decomposed cost

WHAT. We total the work of the short trees.

WHY. Independent ⇒ we run each search separately and sum their costs — not multiply. That switch from multiply to add is where the exponential collapses.

PICTURE. identical short trees side by side. Each costs ; there are of them, so the total is copies added:

Figure — Planning and task decomposition

Now the same numbers as Step 3, with :


Step 6 — How big is the win? The speedup, term by term

WHAT. Divide the naive cost by the decomposed cost.

WHY. A ratio tells us "how many times faster." Watching the algebra lets us see the exponential survive in the answer — the win keeps growing with depth.

  • — a small tax: more pieces means the shrinks the win a little.
  • — the prize: still exponential in depth . This term is why the payoff is enormous.

PICTURE. Speedup plotted against depth for our numbers: a curve that shoots upward. At it reads .

Figure — Planning and task decomposition

Step 7 — The edge cases (don't get fooled)

WHAT. Check the boundaries where the formula behaves strangely.

WHY. The contract: the reader must never meet a case we skipped. Three matter.

Case A — (no split at all). Splitting into one piece is the original problem. Speedup . No win, no loss — sanity check passed.

Case B — (split as finely as possible). Each piece has depth : a single action. Cost linear, not exponential! Best case. But watch the parent's over-decomposition warning: each tiny piece still pays real-world latency (an LM call, a tool round-trip), so infinitely fine splitting has its own overhead cost the formula ignores.

Case C — subgoals NOT independent. If every piece needs the previous piece's result, you must chain them: the depths add back up to and you multiply branches again — you're back to . Independence is the load-bearing assumption.

PICTURE. Three mini-panels: (one tall tree, no change), (a flat row of single steps, linear), and "dependent" (short trees stitched into a chain, tall again).

Figure — Planning and task decomposition
Recall Quick self-test

With , , if the three subgoals were dependent instead of independent, roughly how many paths? ::: Back to — dependence destroys the saving. With , , (finest split), how many paths? ::: — linear, the best case.


The one-picture summary

Figure — Planning and task decomposition

One monstrous tree ( leaves) versus pocket-sized trees ( leaves total), with the speedup arrow between them — the entire derivation on a single canvas.

Recall Feynman retelling — say it in plain words

Picture every way an agent could act as a branching tree. At each step it has, say, ten choices, and it has to make six choices in a row. That's ten, times ten, times ten — six times — a full million routes. Nobody can walk a million routes.

Now here's the escape. If the big job is really three separate little jobs that don't need each other, you don't walk one six-deep tree — you walk three two-deep trees. Two-deep with ten choices is only a hundred routes, and three of those is three hundred. Because the little jobs are independent you add (three hundred), you never multiply (which would give you the million back).

A million versus three hundred — thousands of times less work — and it came purely from noticing the goal was secretly several small goals. The one catch: they must be genuinely independent. The moment one job needs another's answer, you have to stack them, the tree grows tall again, and the magic evaporates. That single word — independent — is the whole trick.