Home / CCA-F / Agentic Architecture / Task Decomposition and Planning — Detail & Examples
DWG 1.2 — DETAIL & EXAMPLES

Task Decomposition and Planning — Detail & Examples

Part of Agentic Architecture · overview: domain-1.html
In this page

A worked decomposition showing sequential vs. parallel structure, a replanning trace when a step doesn't go as expected, and three deliberate strategies for handling ambiguity.

1.2aDecomposing an ambiguous goal

Consider the goal: "Research our top 3 competitors' pricing and produce a summary." A naive agent might do this as one long serial chain. A well-decomposed plan separates what's actually dependent from what isn't:

WORKED EXAMPLE · SEQUENTIAL VS. PARALLEL DECOMPOSITION
TASKResearch 3 competitors' pricing pages and produce one comparison summary.
  1. Identify the 3 competitors and their pricing page URLs — this step must finish before anything else can start.
  2. Fetch and extract pricing data from each of the 3 pages. These three fetches don't depend on each other at all — they can run in parallel.
  3. Once all three are back, synthesize a single comparison — this step depends on all three parallel fetches completing, so it waits for the slowest one.
Structure:Step 1 (sequential) → Steps 2a/2b/2c (parallel) → Step 3 (sequential, depends on all of 2).

1.2bReplanning when a step surprises you

Plans are a starting hypothesis, not a commitment. Here's the same task hitting a snag and adjusting:

ACTFetch pricing page for Competitor B
OBSERVEPage requires a login — pricing isn't public
DECIDE (replan)Original plan assumed all 3 pages were directly fetchable. Adjust: search for a recent third-party review or press release citing Competitor B's pricing instead
ACTSearch for "Competitor B pricing review 2026"
OBSERVEFound a comparison article with 2026 pricing figures
DECIDEProceed to synthesis using the review as the source for Competitor B, with a note on provenance (see Domain 5.4)

1.2cThree ways to handle ambiguity

Pick deliberately, not by default
  • Ask: the goal says "top 3 competitors" but doesn't say which three. If the cost of guessing wrong is high (the report goes to a VP who has specific companies in mind), it's worth one clarifying question before spending time on research.
  • Assume and state: if the cost of a wrong guess is low and re-running is cheap, pick the 3 most obvious competitors, say so explicitly in the output, and proceed — this is usually the right default for low-stakes ambiguity.
  • Explore in parallel: for a genuinely uncertain fork (e.g., "the pricing page" could mean the public page or the enterprise page), spawn both paths and let the synthesis step decide which is more useful, rather than guessing upfront.

Claude Certified Architect — Study NotesDWG 1.2