Agentic Architecture & Orchestration

An agentic loop is control flow you write, not something the API runs for you. You send a request, the model responds, and you inspect stop_reason to decide what happens next. When stop_reason is "tool_use" you execute the tools it asked for, append the results to the conversation, and send again. When it is "end_turn" the model has finished and you present its answer.

The division of labour is the point: the model proposes which tool to call, your code executes it and decides whether to loop. Because tool results are appended to conversation history, every iteration hands the model everything it has learned so far to reason over. That history is the loop's only memory — the Messages API is stateless, so anything you do not send back is gone.

The distinction the exam presses on is model-driven decision-making versus a pre-configured decision tree. In an agentic loop Claude reasons about the next action from context; in a fixed pipeline you have already decided the sequence. Reach for the loop when the path is genuinely open-ended, not to dress up a workflow you could have written as three function calls.

The reference architecture is hub-and-spoke. One coordinator owns task decomposition, delegation, result aggregation, and the decision about which subagents to invoke at all. Every message between subagents goes through it. That routing is not bureaucracy — it is what gives you a single place for observability, consistent error handling, and controlled information flow.

Subagents run with isolated context. They do not inherit the coordinator's conversation history, and they do not share memory with each other between invocations. Anything a subagent needs to know has to be in the prompt you send it.

The failure mode the exam highlights is not a broken subagent — it is a coordinator that decomposed the task too narrowly. If every subagent succeeds at its assignment and the final report still misses half the topic, look at what they were assigned, not at how they performed.

Subagents are spawned with the Task tool, which means a coordinator that cannot invoke subagents is usually a coordinator whose allowedTools is missing "Task". Each subagent type is described by an AgentDefinition: a description, a system prompt, and the tools it is allowed to use.

Context does not travel by itself. If the synthesis subagent needs the web search results and the document analysis output, those findings go in its prompt — complete, not summarised into vagueness. Use structured formats that keep content separate from metadata, so source URLs, document names and page numbers survive the handoff and attribution is still possible downstream.

Parallelism comes from emitting multiple Task tool calls in a single coordinator response. Spreading them across separate turns runs them sequentially. And when you write the coordinator's prompt, specify research goals and quality criteria rather than step-by-step procedure — subagents adapt better to an objective than to a script.

There are two ways to make a workflow happen in the right order: tell the model, or make it structurally impossible to do otherwise. Prompt instructions have a non-zero failure rate. That is tolerable for style preferences and unacceptable when identity verification must precede a financial operation.

Programmatic prerequisites are the answer where compliance must be deterministic. Block process_refund until get_customer has returned a verified customer ID, and the 12% of cases where the model skipped ahead stop existing rather than becoming rarer.

The other half of this objective is the handoff. When you escalate mid-process, the human picking it up has no access to the conversation transcript. A structured summary — customer ID, root cause, refund amount, recommended action — is what makes the escalation useful rather than a restart.

Hooks let you intervene on either side of a tool call. A PostToolUse hook intercepts the result before the model ever sees it, which is where data normalisation belongs: when one MCP tool returns Unix timestamps, another ISO 8601, and a third numeric status codes, normalise them in the hook rather than asking the model to cope.

Interception on the outgoing side enforces policy. A hook that blocks refunds above $500 and redirects to human escalation cannot be talked out of it by a persuasive customer or a model having an off day.

The choice between a hook and a prompt instruction is the same judgement as in 1.4, expressed in the SDK: hooks for deterministic guarantees, prompts for probabilistic compliance. Business rules belong in hooks.

Two shapes, two situations. Prompt chaining — a fixed sequential pipeline — suits predictable multi-aspect work where you know the steps in advance: analyse each file individually, then run a cross-file integration pass. Dynamic decomposition suits open-ended investigation, where each step's findings determine the next subtask.

Splitting a large review into per-file passes plus a separate integration pass is the canonical fixed decomposition. It exists to fight attention dilution: a single pass over fourteen files produces detailed feedback on some, superficial comments on others, and contradictory verdicts on identical code.

For an open-ended task like "add comprehensive tests to a legacy codebase", the plan cannot be written up front. Map the structure first, identify high-impact areas, then build a prioritised plan that adapts as dependencies surface.

Named session resumption with --resume <session-name> continues a specific prior conversation, which is how a multi-day investigation stays one investigation. fork_session does something different: it branches from a shared analysis baseline so you can explore two approaches — two testing strategies, two refactors — without either polluting the other.

Resumption has a sharp edge. If the files you analysed have changed since, the session is carrying stale tool results, and the model will reason confidently from them. Tell it what changed so it can re-analyse the specific files rather than re-exploring everything.

When prior tool results are stale enough, resumption is the wrong tool. Starting a new session and injecting a structured summary of what you learned is more reliable than resuming into contradictions.