Domain 3 — Agents and Workflows (14.7%)

14.7% of the exam, roughly 8 questions. Mostly one skill: choosing the least complex pattern that satisfies the requirement.

3.1 Workflow or agent?

The distinction is precise and it is examinable. A workflow orchestrates models and tools through predefined code paths that you wrote. An agent lets the model direct its own process, choosing tools and steps dynamically.

The default is a workflow. Reach for an agent when the stem tells you the path genuinely cannot be hardcoded — and note that agents need ground truth from the environment at each step (tool results, test runs, compiler output) to know whether they are making progress.

3.2 The five workflow patterns

Prompt chaining

Decompose into sequential calls, each working on the previous output, with programmatic gates between steps. Use when the task splits cleanly into fixed subtasks and decomposition improves accuracy — outline then draft, draft then translate, extract then summarise. The gate is the point: it catches a bad intermediate before it propagates.

Routing

Classify the input, then send it to a specialised downstream handler. Use when there are distinct categories that benefit from different treatment: refunds versus technical support versus billing. Also the standard cost pattern — route simple requests to a small model and hard ones to a large one.

Parallelisation

Two variants, and the exam distinguishes them. Sectioning splits a task into independent subtasks run at once — moderate the input while you generate the response, or evaluate four aspects of a document simultaneously. Voting runs the same task several times and aggregates for confidence — multiple passes over code looking for vulnerabilities, where you would rather have false positives than misses.

Orchestrator–workers

A central model decomposes the task dynamically, delegates to workers, and synthesises the results. The difference from parallelisation is that the subtasks are not known in advance; they emerge from the input. Use it for multi-file code changes and research across sources that cannot be enumerated up front.

Evaluator–optimiser

One call generates, another critiques against criteria, and the loop repeats. Use it when there is a clear evaluation rubric and iteration measurably improves the result — literary translation, search refinement, code that must pass a test. It is wasted where the criteria are vague, because the critic then has nothing to push against.

3.3 Autonomous agents

An agent plans and acts in a loop, consulting the human only when it needs a judgement or more information. Practical requirements: tools it can actually use, an environment that gives real feedback, a stopping condition, and bounds on turns and spend. The failure mode to design against is compounding error — a small mistake early becomes the premise for everything after it.

3.4 Building with the Agent SDK

The Agent SDK gives you Claude Code's agent loop, tools and context management as a Python or TypeScript library, so you are not implementing the loop yourself. The options a developer is expected to recognise:

Subagents are worth understanding even at this level, because they solve a real problem: each runs in its own context, so a subagent can read fifty files and return only a conclusion. It inherits nothing of the parent's conversation — the prompt string you pass is the only channel — and restricting its tools list is a genuine boundary rather than an instruction.

3.5 Frameworks

Frameworks reduce boilerplate and add a layer between you and the API, which is a real cost when you are debugging. The guidance the exam reflects: understand the underlying mechanics first, use a framework when it removes work you would otherwise repeat, and be able to see through it to the actual requests being made.

← Previous: Domain 2 — Model Selection and Optimisation  |  Next: Domain 4 — Prompt and Context Engineering →