Lesson 3 – Claude Certified Architect – Full Course

The limits of a single-agent architecture

The journey into multi-agent systems begins with a single, uncomfortable truth: one Claude agent, no matter how well-prompted, cannot solve every complex problem reliably. A single-agent architecture hits hard physical and logical walls. The context window becomes a scarce resource when an agent must juggle web research, document analysis, and final synthesis all within one thread. Long-running tasks eat into that context budget, forcing the model to compress, forget, or hallucinate details that arrived early in the conversation. Beyond memory pressure, a lone agent cannot parallelize. It must tackle each subtask sequentially, turning a five-minute orchestration job into a frustrating thirty-minute linear slog. There is also no specialization; the same system prompt that guides web scraping is supposed to guide empathetic customer support, leading to mediocre performance across the board. This lesson opens by making the pain visceral, showing logs of a single agent hitting a context limit mid-task, before pivoting to the coordinator pattern as the architectural antidote.

Inside the hub-and-spoke topology

The coordinator pattern presented in the course follows a strict hub-and-spoke topology. At the center sits the coordinator agent, the brain of the operation. It never performs the heavy lifting directly. Instead, it decomposes the user’s high-level goal into discrete, independent tasks, spawns specialized subagents for each one, and then aggregates their results into a coherent final answer. Crucially, subagents never talk to each other. The diagram drawn on the board shows a central node with arrows pointing out to Web Agent, Doc Agent, and Synth Agent, with no lateral connections between them. This enforced isolation eliminates cascading failures and keeps the communication graph simple. The coordinator becomes the single source of truth, the only component that holds the full picture. The topology mirrors battle-tested microservice patterns, adapted here for the unique constraints of large language model agents.

The four non-negotiable responsibilities

Every coordinator must memorize four core responsibilities, which form the backbone of exam questions and real-world implementation alike. The first is task decomposition, the art of breaking a vague user request into specific, parallelizable units of work. The second responsibility is spawning subagents with the correct configuration, handing each one a stripped-down goal and the precise tools it needs. The third is aggregation, collecting raw outputs from all subagents and weaving them into a single polished response. The final responsibility is error handling and fallback, because subagents will fail. A coordinator that does not gracefully handle a timed-out web agent or a malformed document parse does not pass the certification exam. The instructor drills these four points repeatedly, framing them as the "coordinator contract" that every Claude architect must internalize before writing a single line of code.

The Task tool and permission matrix

The SDK mechanism that brings the coordinator pattern to life is the Task tool. This is not a conceptual framework; it is a concrete function call that spawns a new Claude agent with its own isolated context. The lesson walks through the exact Python code, showing how to define a subagent with a system prompt, a list of tools, and a specific goal. A permission matrix is then overlaid on the screen, mapping which tools the coordinator can use, which tools the subagent inherits, and which permissions remain locked at every level. The matrix clarifies a common point of confusion: a subagent does not automatically get access to the coordinator’s memory or conversation history. Every permission must be explicitly granted. The code walkthrough shows a common bug where a subagent tries to call a tool it has not been assigned and fails silently, a trap that the exam scenario questions love to exploit.

The context isolation gotcha

The single most dangerous misunderstanding in multi-agent Claude systems is context isolation. When a coordinator spawns a subagent, that subagent starts completely blank. It does not see the user’s original message, does not inherit the coordinator’s conversation history, and has no awareness of sibling subagents running in parallel. The instructor pauses on this point for dramatic effect, calling it the "gotcha that burns every engineer." If the coordinator does not explicitly package the necessary context into the subagent’s task description, the subagent operates in a vacuum and produces irrelevant or generic output. The lesson demonstrates this failure mode live, spawning a research subagent without passing the target URL, and watching it hallucinate a plausible but entirely wrong summary. The fix is a disciplined handoff pattern where the coordinator crafts a self-contained brief for each subagent, never assuming shared state.

Prompting the coordinator effectively

Writing the coordinator’s system prompt is a different discipline from writing a single-agent prompt. The coordinator should not receive step-by-step procedures; it must receive goals. A bad prompt micromanages, telling the coordinator exactly which agents to spawn and in what order, which defeats the purpose of an intelligent orchestrator. A good prompt defines the desired outcome, lists the available specialist subagents and their capabilities, and trusts the coordinator to reason about decomposition. The video contrasts two prompts side-by-side: the first reads like a rigid SOP document, and the second reads like a high-level mission statement. The second prompt produces more flexible, robust behavior in the face of unexpected inputs. This principle ties directly into the exam’s focus on prompting best practices for multi-agent designs.

The sample question decoded

The final stretch of the lesson applies every concept to Sample Q7 from the official Claude Certified Architect exam. The question presents a scenario involving a customer support system that must pull order data, check inventory, and draft a personalized reply. The instructor builds the solution live, first identifying that the scenario demands a coordinator, then selecting the correct topology, and finally writing the minimal code to spawn the required subagents. The walkthrough highlights distractors in the multiple-choice answers, such as options that propose direct subagent-to-subagent communication or sequential spawning where parallelism is required. The lesson closes with a cheat sheet that condenses the entire session onto one screen: topology, four responsibilities, Task tool syntax, context isolation rule, and the good-prompt versus bad-prompt heuristic. This cheat sheet is presented as the ultimate last-minute study tool for Domain 1 of the certification exam.