Decomposing Complex Tasks into Prompt Chains
The Question This Lesson Answers Lesson 62 explained how to design a chain once you know its steps. This lesson answers the earlier question: given a complex task, how do you decide what the steps should be?
Lesson 15 introduced decomposition patterns: sequential, parallel, map-reduce, and routing. Here, we develop a repeatable method for turning a real, messy task into a chain, including how to find step boundaries, how to map dependencies, and how to decide which steps can run at the same time.
The Decomposition Method
- Describe the final deliverables precisely ↓
- List every piece of information or decision the deliverables need ↓
- Find the natural step boundaries ↓
- Map the dependencies between steps ↓
- Assign an executor to each step (code, model, or person) ↓
- Check the granularity: merge steps that are too small, split steps that are too large ↓
- Derive the execution order, including parallel stages The rest of this lesson applies this method to one realistic example.
The Example Task An instructor sends rough notes about a new course. From these notes, produce:
- A course description for the website (about 120 words)
- A list of 5 frequently asked questions with answers
- An SEO title and meta description All content must use only facts from the notes, and everything must be reviewed for consistency before publishing. The Instructor's Notes (Input) new course - Django REST APIs. 6 weeks, live classes sat+sun 7-9pm IST. need basic python + some django. build 2 projects: task manager api, ecommerce product api. jwt auth, permissions, pagination, testing w/ pytest. fee 4999, early bird 3999 till 15 nov. certificate after both projects. recordings available. A single prompt asked to produce everything at once would have to interpret messy notes, write in three different styles, respect SEO length limits, and check consistency, all in one response. This is exactly the situation decomposition is for.
Step 1: Describe the Final Deliverables Precisely Deliverable Requirements Course description About 120 words, for prospective students, only facts from the notes FAQ 5 questions and answers, based only on the notes SEO title Under 60 characters, includes "Django REST" SEO meta description Under 155 characters Review All deliverables consistent with each other and with the notes Why Start Here Precise deliverables reveal hidden requirements. For example, "SEO title under 60 characters" is an exact constraint that code can check, which affects how that step is designed.
Step 2: List What the Deliverables Need Work backwards from each deliverable:
Deliverable Needs Description Course facts; a structure (what to say first) FAQ Course facts; likely student questions SEO title and meta The course's main topic; ideally the final description Review All deliverables and the original facts One need appears everywhere: reliable, structured course facts. The notes are messy, so extracting facts once, and checking them, will serve every later step.
Step 3: Find the Natural Step Boundaries A step boundary belongs wherever one of these changes:
Boundary Signal Why It Suggests a New Step In the Example The type of task changes Extraction, writing, and checking need different instructions Extract facts → write content → review The audience or style changes Different outputs need different tone and length Description vs FAQ vs SEO text A result must be validated Validation is easier on a small, structured output Check extracted facts before writing anything An exact rule applies Exact rules belong in code SEO length limits A human decision is needed People should not have to read an entire chain's output to approve one point Instructor approves the extracted facts Work can happen independently Independent work can run in parallel FAQ does not depend on the description The Resulting Steps Step Job Executor extract_facts Turn the notes into structured facts (title, duration, schedule, prerequisites, projects, topics, fees, certificate, recordings) Model approve_facts Instructor confirms the facts are correct Person (optional) write_outline Decide the order and emphasis of the description Model write_description Write the 120-word description from the facts and outline Model write_faq Write 5 FAQs from the facts Model write_seo_meta Write the SEO title and meta description from the description Model check_seo_lengths Verify character limits Code review_all Check every deliverable against the facts and each other Model Step 4: Map the Dependencies A dependency means one step needs another step's output. Draw them explicitly:
extract_facts ├──────────────→ write_outline → write_description → write_seo_meta │ │ │ └──────────────→ write_faq │ │ │ │ │ └────────→ review_all ←───────────────┘ Representing Dependencies in Code Python's standard library includes graphlib.TopologicalSorter (Python 3.9 and later), which orders steps so that every step runs after the steps it depends on, and groups steps that can run at the same time.
from graphlib import TopologicalSorter
DEPENDENCIES = { "extract_facts": set(), "write_outline": {"extract_facts"}, "write_description": {"write_outline"}, "write_faq": {"extract_facts"}, "write_seo_meta": {"write_description"}, "review_all": {"write_description", "write_faq", "write_seo_meta"}, }
sorter = TopologicalSorter(DEPENDENCIES) sorter.prepare() stage = 1 while sorter.is_active(): ready = sorted(sorter.get_ready()) print(f"Stage {stage}: {ready}") for step in ready: sorter.done(step) stage += 1 Output:
Stage 1: ['extract_facts'] Stage 2: ['write_faq', 'write_outline'] Stage 3: ['write_description'] Stage 4: ['write_seo_meta'] Stage 5: ['review_all'] Code Explanation DEPENDENCIES Each key is a step; each value is the set of steps it depends on. extract_facts depends on nothing, so it is first.
TopologicalSorter A topological sort orders items so that each item comes after everything it depends on.
Stage-by-stage processing
prepare() checks the graph and raises a CycleError if steps depend on each other in a circle, which would make the chain impossible to run. get_ready() returns all steps whose dependencies are complete. done(step) marks a step as finished, making its dependents ready. The steps returned together in one stage do not depend on each other, so they can run in parallel. What the Output Tells You write_faq and write_outline both depend only on extract_facts, so they run together in stage 2. With parallel execution, the chain needs 5 stages instead of 6 sequential steps, which reduces total waiting time.
The check_seo_lengths code step is not shown separately here because it is part of write_seo_meta's validation (Lesson 62).
Step 5: Assign Executors The table in Step 3 already lists an executor for each step. Review the assignments with these questions:
Could code do this exactly? Character limits, date calculations, and price comparisons belong in code. Does this need a model's language ability? Extraction from messy notes, writing, and semantic review do. Does a mistake here have real consequences? If wrong facts would be published, add a human approval step after extraction, where checking is quick because the facts are short and structured. Step 6: Check the Granularity Granularity means how large each step is. Both extremes cause problems.
Signs a Step Is Too Large Its prompt contains instructions for several different kinds of output. When it fails, you cannot tell which part caused the failure. Its output is hard to validate in one check. Different parts of it need different styles or audiences. Fix: split it along one of the boundary signals from Step 3.
Signs a Step Is Too Small It performs a trivial transformation that the previous step could include. It has no validation of its own and no distinct failure mode. It adds latency without improving quality. Fix: merge it with a neighboring step.
Applying the Check to the Example write_outline and write_description could be merged for a short, 120-word description. Keeping them separate is useful only if testing shows that descriptions are poorly structured without an outline. Start merged, and split only if needed. write_seo_meta is small, but it has its own exact validation (character limits), so it is worth keeping separate. Revised Dependencies DEPENDENCIES = { "extract_facts": set(), "write_description": {"extract_facts"}, "write_faq": {"extract_facts"}, "write_seo_meta": {"write_description"}, "review_all": {"write_description", "write_faq", "write_seo_meta"}, } This version has one fewer step, and write_description and write_faq now run together in stage 2.
Step 7: Derive the Execution Plan With the dependencies fixed, the execution plan follows automatically from the topological sort. The chain runner from Lesson 62 can execute each stage, running the steps of a stage in parallel, and stopping if a step fails.
Thinking About Failures by Stage If This Step Fails Consequence Strategy extract_facts Nothing else can run Retry once, then ask the instructor for clearer notes write_faq Description and SEO can still proceed Retry; publish without FAQ only if acceptable write_seo_meta Length check fails Retry with feedback ("title is 68 characters; limit is 60") review_all finds inconsistencies Do not publish Return the deliverables and the review for human editing Mapping failures to stages shows which steps are critical, such as extraction, where reliability investment matters most.
Decomposition Heuristics Heuristic Explanation Extract once, use many times Structure messy input in one early step that all later steps share Put exact rules in code Limits, calculations, and policies should not depend on the model Validate where outputs are small Check structured intermediate results, not only long final outputs Separate generation from review Review needs a different perspective (Lesson 10, Tip 6) One audience per writing step Different readers need different tone and length Place human checkpoints where checking is cheap Approving 10 extracted facts is faster than reviewing a full page Start with fewer steps Split only when testing shows a step is unreliable Common Mistakes Mistake 1: Decomposing Around the Prompt Instead of the Task What it is: Splitting a long prompt into pieces at arbitrary points, such as "first half of instructions, second half".
Why it happens: The original prompt is the starting point.
What it causes: Steps that do not correspond to distinct jobs, with unclear inputs and outputs.
How to fix it: Start from deliverables and needs, not from an existing prompt.
Mistake 2: Hidden Dependencies What it is: A step quietly relies on another step's output without the dependency being recorded.
Why it happens: Dependencies are obvious to the developer at the time.
What it causes: Steps run in the wrong order or in parallel when they should not.
How to fix it: Write the dependency map explicitly and generate the order from it.
Mistake 3: Repeated Extraction What it is: Each writing step reads the raw notes and interprets them independently.
Why it happens: Each step is written on its own.
What it causes: Inconsistent facts across deliverables, such as two different fees.
How to fix it: Extract facts once, validate them, and give the same facts to every later step.
Mistake 4: Too Many Steps From the Start What it is: Designing a chain with a step for every small action.
Why it happens: Decomposition seems to always improve quality.
What it causes: High cost and latency, with more places to fail.
How to fix it: Start with the fewest steps that have distinct jobs, and split based on test results.
Mistake 5: Review Without the Source What it is: A review step that sees only the generated content, not the extracted facts.
Why it happens: Only the outputs are passed to the reviewer.
What it causes: The reviewer cannot detect invented or changed facts.
How to fix it: Give the review step the facts as the source of truth.
Best Practices Start from deliverables and work backwards. Needs reveal shared steps such as extraction.
Use boundary signals. Task type, audience, validation, exact rules, human decisions, and independence.
Write dependencies explicitly. Generate execution order and parallel stages from them.
Assign executors deliberately. Code for exact rules, models for language, people for important approvals.
Check granularity in both directions. Merge trivial steps; split overloaded ones.
Identify critical steps. Invest reliability effort where a failure blocks everything after it.
Try It Yourself Exercise 1: Decompose a Task Apply the seven-step method to this task: "From a recorded live class transcript, produce a summary for students, 5 quiz questions with answers, and a list of topics the instructor promised to cover next time." Write the steps, executors, and dependency map.
Exercise 2: Generate the Stages Write the dependency dictionary for your decomposition from Exercise 1 and run it through TopologicalSorter. Identify which steps can run in parallel. Then deliberately add a circular dependency and observe the CycleError.
Exercise 3: Granularity Test Implement two versions of the course-content chain: one with separate write_outline and write_description steps, and one with them merged. Run both on three sets of instructor notes and compare description quality, number of model calls, and total time. Decide which version to keep.