The Six-Suitcase Problem - Letting Failure Set Decomposition Depth

I ran a coding agent through ten tasks against a small seeded repository. Three were easy: rename a variable across two files. Four were moderate: add a validation function. Three were genuinely hard: refactor a multi-file transformation to support a new input format. I gave the agent one decomposition strategy for all ten, no exceptions: understand the task, locate the relevant code, implement the change, test it, verify the result. Five subtasks, every time, regardless of what the task actually needed.

The problem

Watching that run play out is the planning equivalent of packing six suitcases for an overnight trip. The easy tasks, the variable renames, got dragged through all five subtasks anyway. Understand a two-file rename. Locate the two files. Implement the rename. Test it. Verify it. That's five LLM calls' worth of ceremony spent on something a single confident attempt would have finished in one shot, because the decomposition depth was chosen before the agent had seen a shred of evidence about how hard the task actually was.

The expensive half of that failure is worse than wasted tokens on the easy tier, though. The hard tasks, the genuine multi-file refactors, still failed at that same fixed depth, because five fixed subtasks don't have any particular reason to land where the real difficulty in a hard task actually sits. A refactor that needs finer-grained decomposition in one specific spot, and coarser handling everywhere else, gets neither. It gets the same five-step template as the variable rename, stretched thin over a problem it was never sized for. I logged cost and success per task, cross-tabbed against pre-classified difficulty, and the pattern was exactly what you'd expect from a decomposition depth chosen in advance and applied like a blanket over everything: disproportionate cost on the tier that didn't need it, and no corresponding gain on the tier that did.

Five subtasks was never really the wrong number. Two-file renames and multi-file refactors just don't share a natural decomposition depth, so choosing one number upfront means guessing, and the guess is wrong for most of the distribution most of the time.

The pattern

The fix is a decomposition strategy that tracks observed difficulty instead of committing to a shape before the agent has attempted anything. This is As-Needed Decomposition, and the mechanism is simple to state even though it took a real shift in how I built the graph to implement it: attempt the whole task in one shot first. Run the test suite against that attempt. Only decompose, and only recurse into finer subtasks, when that attempt's own failure signal says to.

An easy task resolves in one shot, at a fraction of the fixed-depth cost, because nothing ever forced it through five subtasks it didn't need. A moderate task decomposes exactly as far as its first failure indicates and no further, because success at any level stops the recursion right there. A hard task recurses as deep as it genuinely needs to, capped at three levels in my implementation, which in practice went deeper than the fixed version's five subtasks ever reached for that same task, because depth here is being set by where the failures actually occur rather than by a schedule written before the agent ever looked at the problem.

The recursive shape matters mechanically. A failed attempt at the current scope splits into two or three finer subtasks, and only those subtasks get retried. That's the detail that makes the cost math work in the pattern's favor: you're paying only for the narrower attempt at whatever specifically didn't work, never for a full restart every time a sub-piece fails. Decomposition becomes a response to a specific, localized failure instead of a blanket strategy applied uniformly across a task whose actual shape you haven't seen yet.

This is a real, published mechanism. ADaPT, As-Needed Decomposition and Planning with Language Models, showed exactly this shape works: decomposition depth driven by observed failure rather than chosen upfront. What convinces me the idea holds up beyond that one paper is that its core intuition, decompose or replan only where a failure signal actually points, keeps showing up in later work attacking related problems from different angles: bounding a plan repair to just the failed sub-goal's own scoped context instead of regenerating an entire plan, separating local recovery from global replanning in systems coordinating across multiple devices, routing repair only to the specific failing node in a larger orchestration rather than the whole thing. None of that later work is ADaPT itself. It's independent evidence that "recurse or replan only on observed failure" is a direction other people keep arriving at from different starting problems, a stronger signal than one paper making a good point once.

Design considerations

The recursion cap is where this pattern's honesty lives, and I built mine at three levels on purpose rather than leaving it unbounded. Three is a design choice, not a law of nature. A task that genuinely needs a fourth level of decomposition still fails under this pattern. It just fails later, and after spending more tokens getting there than the fixed-depth version would have spent failing on the same task from the start. As-needed decomposition changes when you pay the cost of going deeper into a hard problem. It does nothing to make a genuinely hard task tractable, and I'd rather say that plainly than let the pattern's efficiency gains on the easy and moderate tiers imply something it can't deliver on the tier that's actually hard.

The pattern also depends entirely on having a real failure signal to recurse on. My test suite gave me an unambiguous pass or fail for every attempt, which is exactly the condition this pattern needs to work well. Tasks where success is fuzzy, a piece of writing, a design recommendation, anything without a scriptable check, don't give the recursion a clean trigger. Without a sharp failure signal, "decompose on observed failure" degrades into "decompose whenever the output feels unsatisfying," which is just fixed-depth decomposition wearing a different justification. I'd only reach for this pattern where the task in question has something close to a test suite behind it, literal or otherwise.

There's a tempting move I deliberately avoided: letting the agent decide upfront how deep a task probably needs to go, based on its own read of the task description, and calling that "adaptive." That move is fixed-depth decomposition with an extra guessing step bolted on front, and it inherits the same failure mode, just with a smarter-sounding excuse. The entire value of As-Needed Decomposition comes from never guessing at difficulty and always waiting for an actual attempt to fail before spending anything on a finer breakdown. The moment you let the system estimate difficulty instead of observe it, you've quietly rebuilt the thing this pattern exists to replace.