1.5 Decomposition Techniques & Aligning to Business Value

Step back and notice something: prompt chaining, routing, sectioning, and orchestrator-workers from Lesson 1.2 aren't independent tricks you memorized in isolation — they're all applications of a smaller set of DECOMPOSITION techniques. This lesson names that underlying toolkit directly, because the exam sometimes asks about decomposition on its own terms, one level of abstraction below "which pattern."

Decomposition is what makes a complex problem tractable in the first place: instead of one giant, monolithic prompt trying to do everything at once, you break the problem into smaller, well-scoped steps. Each step is individually easier to prompt correctly, easier to evaluate (you can check one step's output in isolation), and easier to debug (when something's wrong, you know which step produced it) — exactly the same reliability argument you've seen in miniature every time a workflow composition beat a single sprawling call.

There are four decomposition techniques, and each maps onto something you've already met. The question that picks between them is always the same: does this sub-step DEPEND on the previous one's result, is it INDEPENDENT of the others, does it belong to a DISTINGUISHABLE CATEGORY that needs its own handling, or does it need to spawn FURTHER decomposition beneath it?

Recursive/hierarchical decomposition is worth a second look because it's the one that can go more than one level deep: an orchestrator spawns subagents, and each of THOSE subagents might decompose its own piece of work further before it's done — a security audit's "backend" subagent might itself split into "API surface" and "data layer" sub-subtasks. This is decomposition applied recursively, and it's the technique that most directly underlies the multi-agent hierarchies from Lesson 1.4.

There's a second reason decomposition improves reliability beyond "smaller steps are easier," and it's easy to under-weight: every boundary between two decomposed steps is a natural place to insert a validation or gate check. If step 1 extracts data and step 2 acts on it, the seam between them is exactly where you'd verify the extraction actually succeeded before letting step 2 run on garbage input.

This connects directly back to the output-stage concerns from Lesson 1.3 — structured-output contracts and defensive parsing aren't just an end-of-pipeline concern, they belong at EVERY decomposition boundary in a multi-step design, not only at the very end. A monolithic single call has nowhere to put a gate check mid-reasoning; a decomposed design has a checkpoint at every seam, and that's a reliability advantage entirely independent of the "smaller steps are easier to prompt" argument.

Everything in this domain — the pattern you chose, the architecture shape, the decomposition, the decision to add subagents or not — has to be justifiable in one final language: the business's, not the architecture's. An architect who can explain a design only in technical terms ("we used orchestrator-workers with three subagents") hasn't finished the job; they need to be able to say WHICH business need that decision actually serves, in words a non-technical stakeholder would recognize as an answer to their actual question.

Anthropic frames that language as five value pillars, and every architectural tradeoff in this domain should be traceable to at least one of them.

Concrete pairings make this less abstract: "use a smaller model with prompt caching" is a COST and PERFORMANCE decision — it's optimizing spend and latency simultaneously. "Add a human-in-the-loop review before a high-stakes output ships" is a RISK-and-QUALITY decision, sitting closest to the quality-bar and criticality dimensions from Lesson 1.1. If you can't state which pillar a decision serves, that's a signal worth taking seriously — either the decision isn't actually justified, or you haven't finished understanding your own design.

The recurring failure mode here is subtle because it looks like good engineering from the inside: optimizing a metric the business never asked about, at the expense of one it explicitly did. The classic shape is squeezing latency down further when there was no stated SLA requiring it — and paying for that extra speed with a bigger, more expensive model, or with a design that skips a quality check to shave milliseconds, when the business actually asked for cost control or a quality bar, not raw speed.

The fix is the same discipline from Lesson 1.1, applied at review time instead of design time: anchor every tradeoff on the STATED business value, not on whichever metric is easiest to improve or most impressive to report. If a business asked for cost efficiency on a latency-tolerant batch job, and your design instead brags about shaving 50ms off a response nobody was timing, you've optimized the wrong axis — even though "faster" sounds like an unambiguous improvement on its face.

Sequential, parallel, routing, and recursive decomposition answer one question about a decomposed problem: how should the steps be ARRANGED relative to each other? There's a second, entirely separate question that arrangement never answers: once a step is carved out, WHO should own it? This is the ownership lens, and it's complementary to — not a replacement for — the four-technique toolkit from 1.5.2. You apply both to the same decomposed task: arrange the steps with sequential/parallel/routing/recursive logic first, then assign each resulting step an owner using the framework below.

Every discrete task that falls out of a decomposition belongs to exactly one of three owners. WHAT CLAUDE DOES covers steps that genuinely require language understanding, synthesis, judgment under ambiguity, or generation — the model's home turf. WHAT EXISTING SYSTEMS DO covers deterministic lookups, calculations, transactions, or state mutations that a database, a rules engine, or an existing service already handles reliably and cheaply — routing one of these to Claude instead means paying LLM-call cost and accepting non-determinism for something a SELECT statement already solves exactly. WHAT HUMANS DO covers steps that need accountability that can't be delegated, judgment the organization has decided must stay with a person, or a decision whose cost of being wrong is high enough that the organization wants a named human attached to it.

This is the same discipline from Lesson 1.1 — don't reach for the model as a reflex when a simpler, cheaper, more reliable owner already exists — applied one level down, at the granularity of individual task steps rather than the whole system.

Walk a loan-servicing support assistant through this lens to see how the same three criteria produce three different owners inside one workflow. CLASSIFYING the borrower's message intent (payment question, hardship request, general inquiry) goes to Claude: a misclassification just routes to the wrong specialized handler, which is easily corrected, low stakes, and carries no accountability concern. LOOKING UP the borrower's current balance and payment history goes to an existing system: this is a deterministic database read, and routing it through the model instead adds latency, cost, and a real hallucination risk for a fact a direct query answers exactly every time. DRAFTING a response explaining options for a routine payment-date change goes to Claude: reversible (a human or the borrower can push back before anything executes), moderate stakes, and accountability is satisfied because the borrower is only being informed, not committed to anything. APPROVING a hardship forbearance that pauses payments for ninety days goes to a human: it fails reversibility (unwinding a reported forbearance is messy), fails stakes (real financial and regulatory consequences for both sides), and fails accountability (many jurisdictions require a named human decision-maker for hardship determinations) — all three criteria point the same direction at once, which is the strongest possible signal that a step does not belong to Claude.

• •What Claude does — language understanding, synthesis, judgment under ambiguity, generation.
• •What existing systems do — deterministic lookups, calculations, transactions the system already handles reliably.
• •What humans do — non-delegable accountability, organizationally-reserved judgment, or a cost-of-wrong high enough to require a named human decision-maker.

You now have the full arc of Domain 1: elicit the outcome and constraints (1.1), pick the pattern (1.2), design the end-to-end shape (1.3), decide whether multi-agent orchestration is warranted (1.4), choose how to decompose the work (1.5), and — the step that closes the loop back to where you started — justify every one of those choices in the business's own language (also 1.5, and really the whole point of doing any of this).

• 1.Pick a decomposition technique by asking: dependent (sequential), independent (parallel), categorical (routing), or recursive (hierarchical)?
• 2.Place a validation/gate check at every decomposition boundary, not just at the final output.
• 3.For every non-trivial design decision, name the specific business value pillar it serves — efficiency, transformation, productivity, cost, or performance/SLAs.
• 4.Before finalizing, check that you haven't optimized an unrequested metric at the expense of a requested one.