Domain 1 · Lesson 4 · Agentic Architecture (27%)

Task Decomposition & Session Management

Task Statements 1.6 & 1.7 — picking a decomposition pattern, and resume vs fork vs fresh.

Course progress: Domain 1 ▸ lesson 4 of ~4

Two independent skills close out Domain 1: choosing how to break a task apart, and choosing how to carry state across sessions.

Fixed pipeline (prompt chaining) vs dynamic decomposition

Prompt chaining (fixed)Dynamic / adaptive decomposition
ShapePredetermined sequential stepsSubtasks generated from what's discovered at each step
Use whenPredictable, multi-aspect workOpen-ended investigation
ExampleCode review: analyze each file individually, then a cross-file integration pass"Add comprehensive tests to a legacy codebase": map structure → find high-impact areas → build a prioritized plan that adapts as dependencies surface
Decision rule Predictable structure → prompt chaining. Unknown territory where each step reveals the next → dynamic decomposition.

Why split reviews per-file

Analyzing many files in one pass causes attention dilution: some files get deep feedback, others shallow, bugs get missed, and you get contradictory findings (a pattern flagged in one file, approved in another). Fix: per-file local passes + a separate cross-file integration pass. (Lesson revisited in Domain 4 — a bigger context window does not fix attention dilution.)

Session management: resume, fork, or start fresh

ToolWhat it doesReach for it when
--resume <name>Continue a specific named prior conversationPrior context is mostly still valid
fork_sessionCreate independent branches from one shared baselineExplore divergent approaches from the same analysis (e.g., two refactor strategies)
Fresh + injected summaryNew session seeded with a structured summaryPrior tool results are stale (code changed since)
The subtle exam point Starting a new session with a clean structured summary is more reliable than resuming with stale tool results. Resuming drags along outdated file contents the model may still trust. If files changed materially, prefer fresh + summary — or at minimum, explicitly tell the resumed session which files changed so it re-analyzes only those, rather than trusting stale reads.

Check yourself

You must add comprehensive tests to an unfamiliar legacy codebase where dependencies are discovered as you go. The best decomposition approach is:
Correct: option 2. Open-ended investigation where each step reveals the next calls for adaptive/dynamic decomposition. A fixed chain (option 1) suits predictable multi-aspect work, not discovery. Single-pass (3) invites attention dilution; the consensus scheme (4) suppresses real but intermittently-caught bugs.
You return to a task after teammates heavily refactored the files you had analyzed. The most reliable way to continue is to:
Correct: option 3. When prior tool results are stale, a fresh session seeded with a clean summary beats resuming — resumption carries outdated file reads the model may trust. Forking (option 2) also inherits the stale baseline. Passive rediscovery (4) is unreliable.
Domain 1 wrap — the through-line Loop control = stop_reason. Multi-agent = context-isolated spokes + a decomposing hub. Guarantees = hooks/gates, not prompts. Decomposition = chaining (predictable) vs dynamic (open-ended). Sessions = resume (valid), fork (divergent), fresh+summary (stale).
Ask your teacher. Ready for the Domain 1 cumulative quiz? Do it after a short break (spacing aids retention). Then say "start Domain 2" and I'll build it.