Lesson 4 · Domain 1 — Agentic Architecture & Orchestration (27% of exam)

Task Decomposition & Session Lifecycle

Last lesson: when to enforce with a hook instead of a prompt. This lesson: two more decisions you make once per workflow — how to break a task into pieces, and how to manage a session across time — and closes out Domain 1's task statements.

Prompt chaining vs. dynamic decomposition

Two shapes of task decomposition, and the exam wants you to match the shape to the predictability of the task:

Prompt chaining — a fixed sequence of steps, known in advance. A 12-file code review with three known aspects (style, security, performance) doesn't need to adapt mid-flight: run each file through a local pass, then run one cross-file integration pass at the end. Fixed, sequential, predictable.
Dynamic decomposition — subtasks generated based on what's discovered along the way. "Add comprehensive tests to a legacy codebase" can't be planned upfront in full — you map structure first, identify high-impact areas, then build a prioritized plan that adapts as dependencies surface.

Splitting a large review into a per-file pass plus a separate cross-file pass isn't just organizational tidiness — it avoids attention dilution, where a single giant pass produces vaguer, more contradictory findings than two focused ones. You'll see this idea again in Domain 4 applied to independent review instances.

Session state: resume vs. fork

// Continue a specific prior investigation by name
claude --resume refactor-auth-migration

// Fork a shared analysis baseline into two independent branches,
// each exploring a different approach from the same starting point
claude --resume codebase-baseline --fork-session testing-strategy-a
claude --resume codebase-baseline --fork-session testing-strategy-b

--resume <name> continues one specific conversation. fork_session branches off a shared baseline — useful when you want to compare two divergent approaches without re-doing the shared analysis that got you to the fork point. The branches are independent after that: nothing done in one is visible in the other.

The trap: resuming with stale tool results

If you resume a session after the files it previously analyzed have changed, the agent's prior tool results — reads, greps, analysis — are now stale. It doesn't know the code moved out from under it unless you tell it explicitly.

The official guide is direct about the fix: when resuming after code changes, name the specific files that changed so re-analysis is targeted, not full. And when prior tool results are extensively stale rather than mostly valid, starting a fresh session with an injected structured summary is more reliable than resuming at all.

Why this matters beyond the exam

Primary source: Anthropic's Agent SDK overview covers session resumption and forking directly — this lesson closes out Domain 1, compressing Task Statements 1.6 and 1.7.

Check your understanding

Q1. A code review touches 12 files with three review aspects (style, security, performance) known upfront and unlikely to change. Which decomposition fits best?

Q2. You resumed a session with --resume after several files it previously analyzed changed significantly. What's the risk?

Q3. What does fork_session actually give you?

That's all of Domain 1. Want a quick recap of how tasks 1.1 through 1.7 fit together before moving to Domain 3? Just ask.

← Lesson 3: Hooks Study Plan Lesson 5: CLAUDE.md Hierarchy →