Problem decomposition is the act of turning one difficult task into smaller, connected subproblems. In Super Intelligence, decomposition matters because a model can often solve short, well-defined steps more reliably than one large request containing many hidden dependencies. The quality of the decomposition determines whether those smaller steps can be solved, checked and recombined without losing the original problem.
A good decomposition is not simply a longer list. It preserves the goal, identifies dependencies, separates independent work, reveals missing information and creates checkpoints where errors can be detected before they spread.
This article explains problem decomposition in SI through task graphs, dependency order, hierarchical planning, least-to-most prompting, chain-of-thought, subquestions, tool routing, parallel work, recombination, verification and failure recovery. It also shows where decomposition can make a problem worse by splitting apart information that must remain together.
Research such as Least-to-Most Prompting Enables Complex Reasoning in Large Language Models explored solving simpler subproblems before harder dependent ones, while Chain-of-Thought Prompting Elicits Reasoning in Large Language Models helped establish the value of intermediate reasoning on multi-step tasks. These are different techniques, but both make structure inside the problem more explicit.
Previous: 034 — Test-Time Compute. Here we focus on the structure of the work being given that compute.
The Hidden Transition: One Prompt Becomes a Task Graph
Suppose a user asks: “Compare two school timetables, identify clashes, propose a repair, explain the trade-offs and draft a message to parents.” That looks like one request, but it contains at least five different jobs: read the two timetables, detect conflicts, generate repair options, evaluate trade-offs and draft communication.
If the model immediately writes the parent message, it may hide an unresolved scheduling error inside polished prose. A better system represents the work as a graph where later steps depend on verified earlier outputs.
The task graph becomes: ingest → normalise → compare → detect clashes → generate candidates → verify feasibility → choose or present options → draft communication. This structure makes failure easier to locate.
What Counts as a Subproblem?
A subproblem should have a meaningful input, a defined output and a role in the larger task. “Think harder” is not a subproblem. “List every room conflict between Timetable A and Timetable B” is.
Useful subproblems are small enough to test but large enough to preserve the relationships needed for correctness.
The right granularity depends on the task. Splitting every sentence into its own microtask can create overhead and lose context.
Decomposition Is Not the Same as Summarisation
Summarisation reduces information. Decomposition restructures work. A decomposed task can still retain every relevant fact while assigning different operations to different stages.
A planning system might summarise raw documents before reasoning, but that summary is a separate representation decision. Good decomposition asks which facts each stage must preserve.
Decomposition Is Not the Same as Parallelisation
Some subproblems can run in parallel; others depend on earlier outputs. The decomposition identifies the structure, while the execution schedule determines which branches can run simultaneously.
Three independent policy documents can be summarised in parallel. Comparing their effective dates must wait until those summaries preserve the dates correctly.
A Worked Example: Planning a School Open House
Goal: produce a feasible open-house plan using a hall, three classrooms, six teachers and four activity stations. Constraints: the hall is unavailable from 2–3 PM, two teachers are unavailable after 4 PM, and every activity needs at least one teacher.
A weak prompt says “Plan the open house.” A better decomposition first extracts resources and constraints, then generates a schedule, then checks every constraint, then repairs conflicts, then prepares the final human-readable plan.
The model can handle interpretation and explanation, while a scheduling or constraint tool can verify feasibility. Decomposition exposes where each tool belongs.
Stage 1: Extract the Goal
Before solving, state what success means. Is the objective to fit all activities, minimise room changes, maximise attendance capacity, or preserve teacher preferences?
If the objective is not explicit, later subproblems can optimise different things and produce incompatible outputs.
A strong decomposition begins with a stable goal statement that every branch inherits.
Stage 2: Extract Hard Constraints
Hard constraints are conditions that cannot be violated: room unavailability, teacher availability, capacity limits, safety rules and fixed event times.
List these separately from preferences. A preference such as “keep the science station in the lab if possible” should not block a feasible schedule when the lab is needed elsewhere.
Stage 3: Separate Facts From Assumptions
A user may omit important information. The system should mark unknowns rather than silently fill them.
If activity duration is unspecified, the scheduler cannot construct a trustworthy timeline. The next subproblem may be to ask the user or choose an explicitly labelled assumption.
Stage 4: Generate Candidate Structures
Once the state is clear, the system can produce one or more schedules. Different candidates may optimise different trade-offs.
Candidate A minimises teacher movement. Candidate B maximises room capacity. Candidate C preserves the preferred science-room placement.
The decomposition keeps candidate generation separate from candidate evaluation so the scoring criteria remain visible.
Stage 5: Verify Hard Constraints
Each candidate is checked systematically. Does any teacher appear in two places at once? Is the hall used during 2–3 PM? Does every activity have a teacher?
A formal scheduler or simple program can make these checks exact. The language model does not need to re-read prose and hope it notices every conflict.
Stage 6: Evaluate Preferences and Trade-Offs
Only after hard feasibility passes should the system compare soft criteria. How many room changes occur? Which schedule uses larger rooms? Which teacher preferences are satisfied?
This ordering prevents a polished but infeasible option from winning because it “sounds better”.
Stage 7: Recombine Into a Human Decision
The final output should reconnect the subproblems: feasible schedule, key constraints satisfied, trade-offs, unresolved assumptions and the action required from the organiser.
Recombination is part of correctness. A system that solves every subproblem independently but combines the wrong candidate at the end still fails.
Dependency Graphs
A dependency graph shows which tasks must finish before others begin. Nodes are subproblems; directed edges represent required inputs.
For the open house, constraint extraction must precede feasibility checking. Candidate schedules can be generated after constraints are known. Parent communication depends on an approved final schedule.
This graph is useful for both reasoning and orchestration.
Critical Path
The critical path is the sequence of dependent tasks that determines the earliest possible completion time. Parallelising tasks outside the critical path can save resources but may not reduce total latency.
Agent systems benefit from identifying the critical path instead of parallelising everything indiscriminately.
Hierarchical Decomposition
Large tasks can be decomposed at several levels. “Prepare annual budget” becomes revenue, expenses, staffing and cash-flow modules. Each module can decompose further.
Hierarchical structure preserves overview while allowing local work. It also makes ownership clearer in multi-agent or human-AI teams.
Least-to-Most Reasoning
Least-to-most approaches solve simpler subproblems first and use their results to solve harder dependent questions.
Example: before answering “How many students can attend all three sessions?”, first compute capacity for each room, then session overlap, then the final shared constraint.
The advantage is that earlier verified facts reduce the complexity of later stages.
Chain-of-Thought Versus Explicit Decomposition
A model can produce intermediate reasoning in one sequence without creating explicit subproblem objects. That is useful but less inspectable.
Explicit decomposition gives each subtask a name, input and output. This makes it easier to assign tools, run parallel branches and retry only the failed component.
The two methods can work together: each subproblem may still require internal multi-step reasoning.
Question Decomposition
Complex research questions often contain several factual dependencies. “Which policy changed first, why, and what operational effect followed?” can be split into date, cause and effect subquestions.
Search each subquestion against the appropriate sources, then recombine only after provenance is clear.
This reduces the chance that a model mixes evidence from different claims.
Worked Research Example
Question: “Did the school shorten device loans before or after expanding the device pool, and what reason did it give?”
Subproblem 1: find the effective date of the shorter loan period. Subproblem 2: find the date of the device-pool expansion. Subproblem 3: find an official statement of rationale. Subproblem 4: compare dates. Subproblem 5: synthesise the answer with citations.
The decomposition converts one vague research task into five checkable evidence operations.
Parallel Decomposition
Independent branches can run simultaneously. A report comparing four cities can assign one evidence-gathering task per city.
Parallel work saves latency but increases coordination cost. All branches need a common schema so outputs can be compared later.
If one branch reports population in 2024 and another in 2026, recombination becomes misleading.
Schema Before Parallel Work
Define the output fields before launching branches: source date, metric, unit, uncertainty and citation. This prevents each agent from inventing its own representation.
A shared schema is the equivalent of agreeing on mathematical notation before combining separate calculations.
Sequential Decomposition
Some tasks cannot be parallelised because later work depends on earlier decisions. A database migration plan must inspect the current schema before designing the new schema.
Trying to run all stages at once causes branches to rely on guesses about missing inputs.
Dynamic Decomposition
The best decomposition may not be known at the start. A research agent can begin with broad subquestions, discover a contradiction, then create a new verification subproblem.
Dynamic decomposition is useful for open-ended tasks, but it needs budgets and stopping rules to prevent unlimited task expansion.
Static Decomposition
Routine workflows can use a fixed task graph. Invoice processing might always follow extract → validate → calculate → approve → record.
Static graphs are easier to test because the handoffs are known in advance.
Decomposition by Data Type
A document task can split text extraction, table extraction and image interpretation into separate branches, then merge them.
This is helpful when each modality needs a specialised tool. The recombination step must preserve which fact came from which source region.
Decomposition by Operation Type
A task can split into retrieval, calculation, generation and verification rather than by topic.
Example: “Find the current fee, calculate annual cost, explain the difference from last year.” Retrieval obtains both fees, calculator computes totals and the model explains the change.
Decomposition by Uncertainty
Another strategy is to isolate what is known from what is uncertain. Solve the well-defined part first, then target remaining uncertainty with search or clarification.
This prevents one ambiguous detail from blocking the entire task.
Decomposition by Risk
Consequential steps can be separated from harmless ones. A system may autonomously research and draft while requiring approval before publishing or sending.
This is decomposition across authority boundaries, not only reasoning boundaries.
Decomposition by Reversibility
Reversible draft operations can happen early. Irreversible or difficult-to-reverse actions can be delayed until verification is complete.
This ordering reduces the cost of mistakes.
A Bad Decomposition: Splitting Coupled Information
Suppose a legal clause has a rule in paragraph 1 and an exception in paragraph 2. Assigning the paragraphs to separate agents can make each produce an incomplete interpretation.
The correct subproblem boundary must preserve coupled evidence.
Decomposition should follow semantic dependencies, not arbitrary page length.
A Bad Decomposition: Losing the Global Objective
Separate agents can optimise their local tasks perfectly while harming the overall result. One agent minimises cost, another maximises speed, a third maximises quality, and nobody resolves the trade-off.
A central objective and recombination policy are required.
A Bad Decomposition: Too Many Tiny Tasks
Every handoff creates overhead: serialization, context setup, tool calls, latency and possible information loss.
If a five-line calculation is split into twenty agents, coordination can cost more than solving the original problem directly.
A Bad Decomposition: Hidden Circular Dependencies
Task A waits for B, B waits for C, and C waits for A. The workflow deadlocks.
Dependency graphs should be checked for cycles. If the real task is iterative, represent the cycle explicitly with stopping conditions.
A Bad Decomposition: Premature Commitment
The first decomposition can bias the solution. If the task is split according to a wrong assumption, every branch may reinforce it.
For difficult problems, generate alternative decompositions and compare them before spending the full budget.
Decomposition and Context Windows
Breaking a large problem into subproblems can reduce the amount of context each call needs. This helps when a full document set exceeds the context window.
But local calls may lose cross-document dependencies. A shared summary or structured state must preserve the global constraints.
Decomposition and Memory
A long workflow needs memory of solved subproblems, rejected branches and verified facts.
Without persistent state, agents repeatedly rediscover the same information and may contradict earlier decisions.
Memory should store outcomes and provenance, not every speculative thought.
Decomposition and Retrieval
Each subproblem can issue a focused retrieval query instead of sending the entire corpus into one context.
Focused retrieval improves relevance, but cross-subproblem evidence must be reconciled during recombination.
Decomposition and Tools
Subtasks can be routed to specialised tools: calculator for arithmetic, database for state, search for current evidence, code runner for tests, parser for structure.
The decomposition therefore acts as a tool-routing plan.
Decomposition and Agents
Multi-agent systems often assign subproblems to separate agents. This can increase parallelism and specialisation.
The benefit depends on coordination quality. Multiple agents with the same prompt and no shared state may duplicate work rather than divide it.
A Manager Agent
One pattern uses a manager to break the task down, delegate, inspect outputs and recombine.
The manager becomes a central bottleneck and single point of failure. Its decomposition quality should be evaluated independently.
Peer-to-Peer Coordination
Agents can also exchange messages directly. This reduces manager bottlenecks but makes state and authority harder to control.
Complex coordination should be justified by task structure, not by the number of agents available.
Human–AI Decomposition
Humans can define the major modules while SI handles repetitive subproblems. This is often stronger than asking the model to invent the entire decomposition for a consequential workflow.
Expert domain knowledge is especially valuable for identifying hidden dependencies and non-negotiable constraints.
Verification at Subproblem Boundaries
Each subproblem should return a checkable artifact: source-backed fact, calculated number, passed test, structured record or draft.
Do not wait until the final answer to discover an early branch was wrong.
Local Verification Versus Global Verification
Local checks confirm subproblem correctness. Global checks confirm that the recombined solution satisfies the original goal.
Both are necessary. A schedule can contain individually valid appointments that still overlap globally.
Recombination Errors
Suppose four research branches each return correct facts, but the synthesis attributes one fact to the wrong country. Every branch was correct; recombination failed.
Use stable identifiers and structured outputs to prevent this class of error.
Contradictory Subproblem Outputs
Two branches may disagree. The system should not average incompatible facts blindly.
Create a resolution subproblem: inspect source dates, authority and definitions. Preserve the disagreement until it is resolved.
Replanning After Failure
If one subproblem fails, the system can retry locally rather than restarting everything.
Example: OCR fails on one table. Re-run that page through a visual model while preserving the successfully extracted text sections.
Checkpointing
A long decomposition can save intermediate verified state so work survives interruption.
Checkpointing also makes human review easier: approve the research findings before the publishing stage begins.
Cost Accounting by Subproblem
Record tokens, tool calls and latency per node. One branch may consume 80% of the budget while contributing little to quality.
This reveals where to simplify, cache or replace a model step with deterministic software.
Critical-Subproblem Analysis
Some subproblems dominate final reliability. In a financial report, data extraction and arithmetic may matter more than stylistic drafting.
Allocate stronger verification to critical nodes instead of treating every paragraph equally.
Task Graph Versioning
Workflows change. Version the decomposition itself so a result can be traced to the task graph that produced it.
This matters when a new branch is added for compliance or a previously manual check becomes automated.
A Problem-Decomposition Failure Map
Level 1: wrong overall goal. Level 2: missing constraint. Level 3: bad subproblem boundary. Level 4: hidden dependency. Level 5: unnecessary fragmentation. Level 6: failed handoff. Level 7: local verification missing. Level 8: recombination error. Level 9: no global check. Level 10: decomposition cost exceeds value.
This eduKateSG diagnostic map helps determine whether the failure belongs to reasoning structure rather than model capability.
Worked Diagnosis: Correct Subanswers, Wrong Final Report
Four agents return accurate city statistics, but the final table shifts one row. The problem is recombination, not research.
Fix identifiers and schema mapping before asking the research agents to work harder.
Worked Diagnosis: Every Branch Misses the Same Exception
The policy exception was separated into a different chunk and never attached to any subproblem.
The decomposition boundary destroyed required context. Rejoin the rule and exception.
Worked Diagnosis: Workflow Is Slow Despite Parallel Agents
The critical path contains one sequential database approval that takes 30 seconds. Parallelising five other branches cannot reduce below that bottleneck.
Optimise or move the critical dependency rather than adding agents.
Worked Diagnosis: Agent Keeps Expanding Tasks
A research agent repeatedly creates new “check one more source” tasks after evidence is already sufficient.
Add a stopping rule based on required claims and evidence coverage.
A Practical Decomposition Worksheet
Write the goal in one sentence. List hard constraints. List unknowns. Identify outputs the final answer needs. Draw subproblems that create those outputs. Add dependency arrows. Mark which nodes can run in parallel. Assign tools. Define local checks. Define the global completion test.
Then ask what can be merged. If two subproblems require the same context and always move together, combining them may reduce overhead.
Independent Exercise 1: Research
Task: compare current and previous tuition policies, explain changes and draft a parent notice. Name a reasonable decomposition.
Answer
Retrieve current policy; retrieve previous policy; verify dates; compare differences; identify parent-relevant implications; draft notice; check notice against source differences.
Independent Exercise 2: Mathematics
Task: solve a multi-part algebra problem where part C depends on A and B. Can all parts run in parallel?
Answer
Not if C requires outputs from A and B. A and B may run in parallel if independent; C waits for both.
Independent Exercise 3: Coupled Evidence
A contract clause and its exception are on separate pages. Should they be analysed independently?
Answer
Not if the exception modifies the clause. Preserve both in the same semantic subproblem or explicitly join them before interpretation.
Independent Exercise 4: Authority
A workflow researches, drafts and publishes. Which stage should usually carry the highest permission boundary?
Answer
Publication or other external state change. Research and drafting can often remain lower-risk and reversible.
Independent Exercise 5: Global Check
Every schedule row is valid individually, but two rows use the same teacher at the same time. What failed?
Answer
Global verification. Local checks did not enforce the cross-row constraint.
Functional Decomposition Versus Domain Decomposition
A task can be divided by function or by subject matter. Functional decomposition splits operations: retrieve, calculate, verify, write. Domain decomposition splits the world: finance, staffing, transport, education.
The best choice depends on coupling. If each domain has independent evidence but uses the same analysis method, domain branches work well. If all domains depend on one shared calculation, functional decomposition may reduce duplication.
Many complex workflows use both: domain branches gather evidence, then shared functional stages compare and synthesise.
Decomposition by Evidence Ownership
Different facts may belong to different authoritative sources. A travel plan needs airline schedules, hotel availability, passport rules and weather. One agent should not treat a travel blog as authority for all four.
A strong decomposition can assign each evidence class to its correct source system before synthesis begins.
This reduces the chance that one convenient source becomes an accidental authority for unrelated claims.
Decomposition by Temporal Horizon
Long projects contain immediate, medium-term and long-term decisions. A launch plan may split “today’s blocking issues”, “this week’s dependencies” and “next quarter’s scaling work”.
Temporal decomposition helps planning because near-term steps need precise state while long-term steps can remain conditional.
The farther the horizon, the more uncertainty should remain explicit.
Decomposition by Confidence
A system can separate high-confidence facts from uncertain hypotheses. Verified facts become stable inputs; uncertain claims become research or clarification tasks.
This prevents uncertain assumptions from silently spreading into every branch of the workflow.
Confidence-based decomposition is especially useful in research and incident response.
Decomposition by Reuse
If many tasks need the same subproblem, make it a reusable module. Examples include “resolve current policy version”, “calculate exchange rate”, “check document permission” or “validate date format”.
Reusable subproblems improve consistency and make evaluation cheaper because one module can be tested across workflows.
Decomposition by Failure Domain
A system can separate steps according to how they fail. Extraction errors, calculation errors, source errors and permission errors have different repair mechanisms.
This is one reason the Clementi-style “first unstable point” method works well for SI. The task graph should help map a visible failure back to the component capable of repairing it.
A Complete Worked Example: Research Report With Four Evidence Streams
Task: prepare a report on whether a school should extend library opening hours. Evidence required: student demand, staffing cost, security constraints and current utilisation.
Subproblem A retrieves usage logs and calculates hourly occupancy. Subproblem B analyses survey responses. Subproblem C retrieves staffing cost rules. Subproblem D identifies security constraints from current policy.
A synthesis stage cannot begin responsibly until each evidence stream returns source identity, date, units and uncertainty. The final recommendation should distinguish observed demand from survey preference and policy constraints.
This decomposition prevents a common mistake: letting one strong narrative source overpower quantitative evidence from another domain.
Worked Example: Product Launch
Task: launch a tutoring programme next month. Subproblems include curriculum readiness, tutor availability, pricing, room capacity, enrolment workflow, parent communication and compliance.
Some branches can run in parallel. Curriculum preparation and parent-copy drafting can proceed while room availability is checked. Pricing depends on staffing and class capacity. Publication depends on approved dates, fees and terms.
The dependency graph keeps the public announcement from being published before the operational facts are stable.
Worked Example: Debugging a Software Failure
Bug report: “Users are charged twice after retrying checkout.” Decompose into request logs, payment-provider records, retry logic, idempotency keys and database transaction state.
Each branch asks a different question. Did the client send two requests? Did the server process one request twice? Did the provider create two charges? Did the database record both?
A model can summarise the evidence, but the decomposition prevents a vague conclusion such as “the payment AI failed”.
Worked Example: Education Diagnosis
Student says, “I understand algebra in class but fail tests.” Decompose performance into concept recall, untimed practice, mixed-problem recognition, timed execution, error recovery and exam strategy.
Different sensors test each layer. A student who solves every problem untimed but collapses under time pressure needs a different intervention from one who cannot explain equation balance.
This mirrors the wider eduKateSG repair philosophy: diagnose the first unstable point instead of applying more undifferentiated practice.
Task Decomposition as Compression of Complexity
A large problem may contain thousands of details, but only a few dependency relationships determine how work must flow. A task graph compresses the complexity into modules and edges.
The graph is useful when it preserves the dependencies that matter. If it omits one crucial edge, the apparent simplicity becomes dangerous.
Information Interfaces Between Subproblems
Each subproblem should expose an interface: required inputs, output schema, provenance, confidence and failure status.
This is analogous to software APIs. A module should not require the next stage to infer hidden assumptions from free-form prose.
Structured interfaces reduce coordination load in multi-agent systems.
Contracts for Subproblem Outputs
Example contract for research retrieval: claim, source_url, source_date, quoted_or_paraphrased_evidence, source_type, unresolved_conflict. Example contract for calculation: formula, inputs, units, result, verification.
Contracts make recombination safer because the synthesiser knows what each field means.
Typed Handoffs
A date should remain a date, not become an ambiguous string. A currency amount should retain its currency. A document ID should remain an identifier rather than a guessed title.
Typed handoffs prevent information from degrading as it moves through agents.
Provenance Through the Task Graph
Every derived result should be traceable to its source inputs. If a final report states “cost rises 18%”, the system should know which staffing and capacity values produced that number.
Provenance is especially important when intermediate summaries compress multiple sources.
Uncertainty Propagation
Subproblem outputs can carry uncertainty. If demand is estimated from a small survey, the final recommendation should not present it as exact population behaviour.
Recombination should preserve uncertainty rather than averaging it away through confident prose.
Error Propagation
An early error can contaminate many downstream branches. If the wrong exchange rate is used, every cost comparison based on it becomes wrong.
Critical shared inputs deserve strong verification because their error fan-out is large.
Fan-Out and Fan-In
Fan-out occurs when one verified input feeds several branches. Fan-in occurs when several branches converge into synthesis.
High fan-out nodes are leverage points for caching and verification. High fan-in nodes are risk points for recombination errors.
Task Graphs as Directed Acyclic Graphs
Many workflows can be represented as directed acyclic graphs, or DAGs, where dependencies move forward and no node depends on its own future output.
Iterative processes add controlled cycles: draft → review → revise. The cycle needs a stop condition, maximum iterations or acceptance rule.
Cycle Detection
An agent can accidentally create circular tasks: “verify plan after budget”, “calculate budget after plan”, with neither providing an initial assumption.
Workflow engines can detect cycles and ask for a missing starting condition.
Topological Ordering
For an acyclic task graph, topological ordering produces a valid sequence in which every node runs after its dependencies.
This classical algorithmic idea is useful for agent orchestration. The language model can propose the graph; software can enforce execution order.
Scheduling Parallel Nodes
Once dependencies are explicit, independent nodes can be dispatched concurrently. This reduces latency without sacrificing correctness.
Resource limits still matter. Launching 100 model calls in parallel may exceed rate limits or budget, so the scheduler can cap concurrency.
Backpressure
If downstream synthesis cannot keep up with upstream agents, results accumulate. Backpressure slows producers or batches outputs.
This systems concept matters in large multi-agent workflows just as it does in data pipelines.
Priority Queues for Subproblems
Not every pending task has equal importance. A blocker on the critical path should run before an optional stylistic refinement.
Priority can depend on dependency count, risk, expected information gain or deadline.
Information Gain as a Decomposition Strategy
When several unknowns exist, solve the one most likely to change the final decision first.
Example: before researching ten hotel amenities, first check whether the hotel is available on the required dates. Availability has greater decision value.
Value of Information
A subproblem is valuable when its result can alter a decision enough to justify its cost.
This helps prevent agents from researching low-impact details while the main uncertainty remains unresolved.
Decomposition and Test-Time Compute Allocation
Article 034 introduced adaptive inference budgets. Decomposition makes those budgets local. Spend more compute on the difficult branch instead of scaling the whole task equally.
A report may need deep verification for one disputed statistic while routine formatting remains one-pass.
Decomposition and Caching
Verified sub-results can be reused across tasks. If the current policy version is already known and unchanged, later branches need not retrieve it again.
Cache keys should include source version and relevant context so stale results are not reused incorrectly.
Decomposition and Idempotency
Subtasks that create external state should be safe to retry or have outcome checks. A failure in a later branch should not cause earlier file creation to duplicate.
Execution design therefore belongs alongside reasoning design.
Decomposition and Human Approval
A task graph can place approval gates before consequential nodes. Research → draft → human review → publish is a simple example.
The graph records that publication cannot execute merely because upstream drafting succeeded.
Decomposition and Auditability
An audit trail can record node inputs, outputs, tool calls and status. This is more useful than one giant transcript because it maps evidence to responsibilities.
Auditability helps reproduce failures and compare workflow versions.
Decomposition and Privacy
Different branches can receive different minimum data. A scheduling branch needs availability; a payment branch needs invoice state. Neither automatically needs the other’s sensitive fields.
Subproblem boundaries can therefore support data minimisation when access is designed correctly.
Decomposition and Security
A research branch exposed to untrusted web pages should not share the same write permissions as a publishing branch.
Separating them reduces the chance that prompt injection in retrieved content reaches a consequential tool.
A Security-Oriented Task Graph
Stage 1 searches and reads untrusted content with read-only tools. Stage 2 extracts evidence into a sanitised structured record. Stage 3 reasons over that record. Stage 4 requests human approval. Stage 5 performs the external action with a narrow tool.
The graph creates trust boundaries as well as reasoning boundaries.
Decomposition and Multi-Model Routing
Different subproblems can use different models. A small model handles classification; a strong reasoning model handles the hard proof; a vision model reads the diagram.
This reduces cost and can improve capability by matching architecture to task.
Model Routing Failure
If the manager sends a visual table to a text-only model, the subproblem may fail even though decomposition is sound.
Routing decisions need capability metadata and evaluation.
Decomposition and Specialized Solvers
A subproblem that matches a classical algorithm should use it. Shortest path → graph search. Linear constraints → solver. Arithmetic → calculator. Database state → query.
SI is strongest when decomposition reveals opportunities to hand exact work to exact tools.
A Full Completion Checklist
Goal preserved. Constraints preserved. Unknowns explicit. Dependencies acyclic or deliberately iterative. Parallel branches share a schema. Critical inputs verified. Subproblem outputs typed. Provenance retained. Contradictions resolved. Global constraints checked. External actions gated. Completion rule satisfied.
If any item is missing, the decomposition may produce a polished result without a dependable process.
Independent Exercise 6: High Fan-Out
One exchange rate feeds 20 cost calculations. Where should verification effort be concentrated?
Answer
On the exchange-rate source and timestamp before fan-out, because one error would contaminate all 20 branches.
Independent Exercise 7: Information Gain
You are planning a trip. You can research restaurant menus or confirm whether the destination is open on the travel date. Which should come first?
Answer
Confirm availability/opening first because it has greater decision value and can invalidate later work.
Independent Exercise 8: Privacy
A report has finance and HR branches. Should both receive every employee salary and medical note?
Answer
No. Give each branch only the minimum authorised data needed for its subproblem.
Independent Exercise 9: Tool Routing
A branch needs exact shortest-path distance on a graph. Should the model generate dozens of prose routes?
Answer
Use a graph algorithm or routing tool, then let the model explain the verified result.
Independent Exercise 10: Retry
A file-creation node times out and the workflow restarts. What must be checked?
Answer
Whether the file was already created, using resource identity or idempotency support, before retrying the state-changing node.
Frequently Asked Questions About Problem Decomposition
Why decompose a problem?
To reduce cognitive and computational complexity, expose dependencies, route work to suitable tools and create checkpoints for verification.
Can decomposition make performance worse?
Yes. Bad boundaries can lose context, add overhead, create coordination errors or lock the system into the wrong framing.
Is chain-of-thought the same as decomposition?
No. Chain-of-thought is one form of intermediate reasoning. Decomposition explicitly defines subproblems and dependencies, which can then be solved by several methods.
Can subproblems run in parallel?
Only when their required inputs are independent. Dependencies determine the safe execution order.
How small should a subproblem be?
Small enough to have a clear output and check, but large enough to preserve all information needed for correctness.
Who should define the decomposition?
The model can propose one, but humans or deterministic workflow designers may define or review decomposition for consequential tasks.
How do agents share subproblem results?
Prefer structured state, stable identifiers, provenance and explicit schemas rather than unbounded conversational summaries.
What is the final test?
Verify that the recombined solution satisfies the original goal and constraints, not merely that each local task succeeded.
Problem Decomposition Turns Complexity Into Inspectable Structure
The purpose of decomposition is not to make every task longer. It is to make dependencies, responsibilities and checks visible. A good decomposition reduces uncertainty; a bad decomposition merely redistributes confusion.
For SI systems, this structure is what makes test-time compute efficient. Compute can be allocated to the branch that is actually difficult, tools can be matched to the right operation, and failures can be repaired locally instead of rerunning the entire workflow.
Continue through the How Super Intelligence Works hub. Previous: 034 — Test-Time Compute. Next: 036 — Planning.
Decomposition Completion Standard
A decomposition is complete only when every required final output has an owner, every dependency is represented, each high-risk handoff has a validation rule and the recombination step can be checked against the original goal. The task graph should make it possible to answer: what failed, what depends on it, what can continue safely and what must be rerun?
For substantial workflows, keep a node register containing subproblem ID, purpose, inputs, source or tool, expected output, acceptance test, dependencies and status. This turns decomposition into an operating artefact rather than an ephemeral paragraph generated once and forgotten.
Then test the graph under disturbance. Remove one required input, make one tool unavailable, return a contradictory source and change one approved object after review. A strong decomposition should isolate these failures instead of allowing them to contaminate unrelated branches.
Finally, compare the decomposed workflow with a direct baseline. Decomposition earns its complexity when it improves reliability, parallelism, tool selection, auditability or recovery enough to justify the coordination overhead. If one direct model call solves the task reliably and cheaply, forcing a twenty-node graph is not sophistication; it is unnecessary load.
This completion standard establishes the bridge to planning. Decomposition tells us what pieces exist and how they depend on one another. Planning adds current state, available actions, preconditions, effects, resources and the temporal route through those pieces.
Final Transfer Exercise: Decompose Before You Automate
Take one recurring task from work or study and write the direct version first. Then draw a second version with explicit subproblems. For each node, name the required input, the output, the source of truth, the tool, the acceptance test and the next dependent node. Mark every unknown instead of inventing a value.
Now remove one node. If the workflow can still reach the final goal safely, that node may be unnecessary overhead. If several later nodes collapse, the removed node is a critical dependency and deserves stronger verification. This simple ablation exercise reveals whether the decomposition reflects the real structure of the task.
Finally, compare the direct and decomposed versions on accuracy, repairability, latency and cost. The purpose is not to maximise the number of steps. The purpose is to create exactly enough structure that errors become local, evidence remains traceable and independent work can proceed in parallel without losing the original objective.
A reader has mastered decomposition when they can look at a large request and identify what must stay coupled, what can separate, which steps can run together, which must wait, and where a global verification must reunite the work. That is the working floor carried into planning.
One Last Rule: Decompose Around the Constraint, Not the Vocabulary
Two sentences can sound unrelated while depending on the same hidden constraint, and two paragraphs can use the same vocabulary while belonging to different subproblems. Decomposition should follow causal, informational and operational dependency rather than superficial topic similarity. That is why a current policy rule and its exception belong together, while a policy summary and a publication action can remain separate even though both mention the same policy.
The practical test is whether one subproblem can be solved and verified without guessing an output owned by another. If not, the boundary is too early. If two modules can proceed independently and communicate through a clear typed handoff, the boundary is probably useful. This criterion gives builders a durable way to tune decomposition as workflows grow.