Agentic architecture and orchestration

Start with the decision that precedes every other: workflow or agent? A workflow is code you wrote in advance — a fixed sequence of model calls and deterministic steps, the same shape every run. An agent is a model in a loop — it decides, act by act, what the next step is, given what it has seen so far. The exam will hand you a scenario and ask which one fits; get the underlying question right and every variant answers itself.

The underlying question is: how predictable is the path? If the steps are known in advance — summarise, classify, format, send — write the steps yourself; that is a workflow, and it is cheaper, more testable and easier to debug. If the number of steps, their order or their very nature depends on what the work reveals — “find the bug and fix it”, “research this and write it up” — you need the model in the loop, because someone has to look at each result and decide what follows. That someone is the agent.

01The agent loop, opened up

Every agent you will be asked about — Claude Code, a subagent, something you build on the Agent SDK — runs the same loop. Learn it once at the mechanical level and a dozen exam questions become rewordings.

In the Claude Agent SDK this loop is the harness’s job, not yours. You call a query with a prompt and configuration; the SDK sends the model requests, executes tool calls, feeds results back, and yields messages to your code as the run progresses. You are not writing while-loops around API calls — you are reading a stream of typed messages and reacting.

Five message kinds come out of that stream, and the exam likes the taxonomy: SystemMessage (session-level information, once at the start), AssistantMessage (what Claude said or did — text, tool_use, thinking blocks), UserMessage (tool results, user input, hook-injected context — the things the harness sends back), StreamEvent (incremental deltas if you asked for them), and ResultMessage (the wrap-up of one query: subtype, cost, duration, usage). One trap lives here: the result message is not guaranteed to be the last item in the stream, and “the run finished” is not the same as “the run succeeded” — iterate to completion and check the subtype. “success” is the one you want.

02Stop conditions — how the loop ends

An agent without stop conditions is a while-true with a credit card. The exam expects you to design the exits, and there are exactly four kinds worth naming. Natural completion: the model emits end_turn because it believes the task is done. Token and turn budgets: max_tokens caps a single generation; your harness or the SDK caps turns, so a confused agent spirals into a wall rather than into infinity. Stop sequences: literal strings that cut generation — precise, mechanical, for format control. And external stops: hooks, permission denials, a human hitting the brake, a wall-clock timeout in your orchestration layer.

The design reading matters more than the list. Budgets are a backstop, not a strategy — an agent that hits max turns has usually been mis-scoped, and the fix is a smaller task or better tools, not a bigger budget. When a scenario says “the agent loops forever on malformed input”, the answer is almost never “raise the limit”; it is “validate the tool result and make failure legible to the model”, which is Domain 2’s religion arriving in Domain 1.

03Multi-agent systems: the coordinator pattern

The moment a task is too big for one context window — or too varied for one prompt — the exam expects the coordinator–subagent pattern, sometimes under Anthropic’s name for it: orchestrator–workers. One lead agent owns the task, the plan and the user; it delegates pieces to subagents, each running the same loop you just learned in its own conversation with its own tools; their results flow back to the coordinator, which decides what happens next. The coordinator is the only one who talks to the user and the only one who sees the whole picture; the workers see their slice.

There are exactly four reasons to reach for a subagent, and the exam quotes all four. Context isolation: the subagent’s reads and dead ends happen in its own window, so the parent’s context stays clean — this is as much a context-management move as an organisational one. Parallelism: independent workers run concurrently (a style check, a security scan, a coverage audit at the same time). Specialised instructions: a system prompt tuned to one job beats a general prompt wearing many hats. Tool restriction: a reviewer limited to read-only tools physically cannot edit files, whatever the task tempts it to do — restriction is enforcement by construction, which beats a politely-worded instruction every time.

04Subagents in practice: defining, invoking, passing context

How does a subagent come into existence? Three ways, and the exam tests the menu. In code, on the Agent SDK: a subagent is an agent-as-tool — you define an agent with its own prompt and tools and expose it as a tool the lead agent can call, which is why “subagents are just tools with a conversation” is an acceptable one-liner. As markdown files: a definition file (name, description, system prompt, allowed tools) in .claude/agents/ makes Claude Code itself able to spawn that persona on demand — this is the filesystem route, and the one a “no code changes” scenario wants. Or built-in: Claude Code ships with general-purpose, and the SDK has its own built-ins.

Invocation and context passing have one rule the exam keeps re-testing: context is passed by value, not by reference. The parent writes a task description — the prompt-in-a-prompt — and the subagent starts a fresh window containing its own system prompt, that description, and whatever tools it is allowed. It cannot scroll up into the parent’s history. When it finishes, what returns is its final report (and structured output if you asked for it), not its transcript. Two consequences follow. Write delegation prompts like briefs for a capable new colleague — self-contained, with the goal, the constraints and the definition of done, because “see previous conversation” is not something you can put in a brief. And expect to pay summarisation: the worker may have read 50,000 tokens; the parent sees the digest. That is not a bug, it is the entire point.

One mechanics gotcha worth real marks: in Claude Code, subagents defined as files are discovered from directories that existed when the session started. Create .claude/agents/ for the first time mid-session and the definitions will not load — restart the session and they appear. And the precedence when the same name is defined twice: managed settings outrank everything, then the --agents flag, then project .claude/agents/, then personal ~/.claude/agents/, then plugins. First match wins.

05Enforcement and handoffs in multi-step workflows

An agent with tools is a stranger with keys. Enforcement is the lock architecture, and the exam wants you to reason in layers. The innermost layer is the tool definition itself — a read-only tool cannot write, no matter what the prompt said; restriction by construction beats instruction. Around that sit permissions: allow and deny rules that gate which tools may run at all (deny beats allow, every time). Around those, hooks — code that runs at lifecycle moments and can veto or shape what happens (next section). Outermost, the workflow: you the architect deciding which steps are agent steps and which are deterministic code — validation gates, a required human approval between phases, a formatter the output must pass through. Enforcement composes; the exam’s wrong answers usually offer one layer when the scenario needs another.

Handoffs are the other half of multi-step orchestration: the planned transfer of work between actors — agent to agent, agent to human, human back to agent. An agent-to-agent handoff carries a contract (the brief, the inputs, the definition of done) and a return path (report, structured result, artifacts on disk). An agent-to-human handoff is not a failure state; it is a designed checkpoint — HITL, human-in-the-loop — and the design questions are always the same three: what triggers it (task criticality? blast radius? low confidence?), what the human sees (the proposal, the evidence, the diff — enough to judge without re-doing), and what happens next (approve and continue, edit and continue, or reject with reasons that go back into the agent’s context as feedback).

The escalation ladder — when the system hands control upward — composes the two: an agent resolves what it can, defers ambiguity upward per its instructions, and a human resolves what the ladder sends up. The trigger conditions are yours to design, and the exam phrases them as trade-offs: every rung you add buys safety and costs latency; every rung you remove buys speed and spends oversight. There is no universal right answer — there is the answer that fits the scenario’s stakes, and the questions are built so that reading the stakes is the skill.

06Agent SDK hooks: interception and normalization

Hooks are user-provided code that runs at fixed points in the agent’s lifecycle — deterministic code attached to a non-deterministic system, which is exactly why they exist. The two the architect exam cares about bracket the tool call. PreToolUse fires before a tool executes and can see the input, then approve, deny, or ask. PostToolUse fires after, sees the input and the result, and can normalise what gets recorded. Between them they implement the exam’s two favourite verbs: interception (stop or redirect something before it happens) and normalisation (clean something up after, before it enters the record).

Interception scenarios all have the same shape. A PreToolUse hook denies Bash commands that match rm -rf, denies writes outside the migration directory, forces a confirmation on anything with production in the path. The decision mechanics: a hook communicates by exit code and, for richer control, JSON on stdout — exit code 0 lets the call proceed, exit code 2 blocks it, and a JSON decision can say approve, deny (with a reason the model actually reads) or ask, and can even rewrite the tool input before it runs. That last one is worth sitting with: a hook can silently fix a path, inject a required flag, or redact a secret in flight. Denial with a reason is usually better than silent correction, because the model learns from the reason — silent fixes produce an agent that keeps trying the broken thing.

PostToolUse normalisation is where data hygiene lives: strip tokens and PII from tool output before they enter the transcript, reformat a mess into JSON the next steps can rely on, log the call to your audit trail. The framing the exam rewards: the transcript is context — anything you let into it becomes part of every future decision, so normalising tool output is context engineering, not just tidiness. Two footnotes: hook events differ between the SDK’s languages and Claude Code (not every event exists everywhere — current as of September 2026), and the full permission chain runs hooks → deny rules → ask rules → permission mode → allow rules → the SDK’s canUseTool callback. Hooks run first; nothing downstream can rescue what a hook denied.

07Task decomposition strategies

Given a coordinator and workers, how do you cut the work? The exam’s answer catalogue has four shapes, and scenarios are marked by which one fits. Map–reduce: cut the task into independent units, process them in parallel, then combine — one subagent per service for the audit sweep, results merged by the coordinator. The test for map–reduce is independence: units must not need each other’s intermediate state. Pipeline: fixed stages, each agent’s output the next one’s input — research drafts, editor rewrites, verifier checks. The test is specialisation: each stage wants a different prompt or toolset. Hybrid — pipeline of map–reduces — is real life: most production systems are a research stage that fans out, a synthesis stage, a review stage that fans out again.

The fourth shape is the one people forget: don’t decompose. A single agent with good tools beats a committee on tasks that fit one context window, because coordination is not free — every brief you write, every report you reconcile, every conflict you arbitrate is work and risk that a single-window task never needed. The two failure modes the exam tests are symmetrical: under-decomposition (one agent drowning in scope — symptoms: context exhaustion, forgotten constraints, degraded quality late in the run) and over-decomposition (a swarm whose coordination overhead and interface bugs exceed the task itself — symptoms: contradictory worker outputs, a coordinator reduced to copy-pasting). Decompose on evidence — the task genuinely exceeds a window, or genuinely needs different toolsets or permissions — not on ambition.

Two design rules make any decomposition trustworthy. Define the unit of work so it is self-contained — a worker should be able to succeed from its brief alone, because it can see nothing else. And define the interface between stages before writing any prompts — what a worker returns (format, fields, confidence) is a contract; the coordinator’s correctness can never exceed the workers’ output discipline.

08Session state, resumption and forking

Agentic work is long, and long work gets interrupted — crashes, deploys, the simple fact that a human went home. Session mechanics are how a run outlives a pause. In the Agent SDK, a session is a persisted conversation with an identifier: same session ID on your next query, and the run resumes where it left off — full history intact, no re-reading, no re-reasoning. A new session ID starts fresh. In Claude Code the same lever exists as --resume to continue a recorded session and --fork-session to resume a conversation into a new session without disturbing the original — branch, experiment, compare.

Forking is the architecturally interesting half. A fork shares the parent’s history up to a point and diverges after it — the pattern behind “try the risky fix in a branch”, A/B two approaches from one shared investigation, or re-running a review with a different checklist without paying for the exploration twice. Note what forking is not: it is not a crash-recovery mechanism. Resumption is continuity; forking is parallel experiment. The exam’s scenario verbs tell you which it wants — “continue” means resume, “compare” or “try both” means fork.

The design questions worth marks: what belongs in session state (the conversation — and that is all the platform promises you) versus what belongs outside it (anything durable your workflow needs: artifacts written to disk, results in a database, progress in your own store — because a resumed session restores the transcript, not the filesystem or your process’s memory). When a scenario’s agent resumes and “forgets” a file it created, that is not a bug to fix with cleverer prompts; it is state that should have lived in the design, not the session.

09The traps

• —“Give the agent more freedom to handle edge cases.” Freedom is a cost. The architect’s reflex is the smallest toolset and the tightest permission set that gets the job done — edge cases are handled by better tools and clearer contracts, not looser leashes.
• —“Multi-agent is the upgrade path; single agent is the starter tier.” Backwards. The simplest thing that works is the senior answer; a coordinator exists because the task exceeds one window or one toolset, not because a diagram would look better.
• —“Subagents share context, so the coordinator just points at it.” They do not. Context passes by value, by brief. Every “the worker should have known what the other worker found” scenario is a design error, and the fix is routing through the coordinator.
• —“The hook failed, but the permission mode allowed it, so it ran.” No. The chain runs hooks first; a hook denial cannot be rescued downstream. The order is hooks → deny → ask → mode → allow → canUseTool.
• —“Raise the turn limit so it stops truncating.” Budgets are backstops. A run that hits them is mis-scoped — decompose better or fix the tool results. The limit-raising answer is the trap answer.
• —“Resume restores everything after the crash.” It restores the conversation. Files, environment and your application state were never in it.