Building AI Agents with Claude: Orchestration Patterns That Actually Work

Building agents with Claude is not the same as writing a chatbot. An agent operates in a loop — it receives a task, reasons about it, takes actions using tools, observes results, and continues until the task is complete or a stopping condition is met. Getting this loop right is the foundation of Domain 1 of the Claude Certified Architect exam, which carries a 27% weighting.

The Agentic Loop Lifecycle

Every Claude agent follows the same basic cycle: perceive → reason → act → observe. Claude receives context (the task, memory, tool results), produces a response, optionally calls tools, receives tool outputs, and loops until it generates a final response with stop_reason: "end_turn".

The most common architectural mistake is treating this loop as a black box. Architects need to understand the signal that terminates it. When stop_reason is "end_turn", Claude has decided it is done. When it is "tool_use", Claude needs a tool result before it can continue. Building on content analysis instead of reading stop_reason directly is one of the eight architectural judgment traps the exam specifically tests.

Single-Agent vs Multi-Agent Architectures

For most tasks under moderate complexity, a single agent with well-designed tools is the right choice. Multi-agent architectures add operational overhead — network latency, context propagation, error surface — and should only be introduced when a single agent genuinely cannot handle the scope.

The CCA-F exam tests your ability to choose correctly. Key signals that multi-agent is appropriate include: parallelisable subtasks, domain separation requirements, trust boundary needs (different agents with different permission levels), or tasks that exceed a single context window.

The Coordinator/Specialist Pattern

The most commonly tested multi-agent pattern is the coordinator/specialist architecture. A coordinator agent receives the high-level objective, breaks it into subtasks, routes them to specialist agents, aggregates results, and returns a final answer. Specialist agents have narrow, deep toolsets focused on a single domain (e.g., a code-writing agent, a web-search agent, a data-analysis agent).

Important implementation detail: specialists should not have access to the coordinator's full context. They receive only what they need. This reduces prompt token cost and limits the blast radius of errors.

How Many Tools Per Agent?

The exam tests a specific numeric threshold: assigning more than 4–5 tools to a single agent degrades tool-selection reliability silently. Beyond this threshold, Claude begins selecting suboptimal tools or conflating similar ones. The correct pattern is to keep tool counts low per agent and introduce specialisation instead.

The Claude Agent SDK

The Claude Agent SDK provides higher-level abstractions for managing agent state, tool calls, and conversation history. It handles the loop execution, tool dispatch, and error propagation automatically. Key concepts for the exam:

• Agents are instantiated with a system prompt and a tool list
• The SDK manages the message array internally between turns
• Subagents can be spawned as tools from a parent agent
• Interruption and human-in-the-loop checkpoints are built into the SDK lifecycle

Common Exam Traps in Domain 1

The exam is designed around architectural judgment, not recall. Watch for these recurring traps:

• Self-review by the same session: An agent reviewing its own output cannot provide genuine critique. Independent instances are required for meaningful quality gates.
• Over-orchestrating before simplifying: Multi-agent is not always better. The exam will present scenarios where a single agent with a good tool description solves the problem more reliably than a complex orchestration.
• Checking content instead of stop_reason: Always read the stop_reason signal to determine loop state — never parse the model's text output to infer whether it is done.