Studying Agentic Architecture and Orchestration: the CCA Exam's Largest Domain

Agentic Architecture & Orchestration is worth 27% of the CCA Foundations exam, more than any other domain.

It covers how you design systems where Claude doesn't just answer one question, but plans, calls tools, hands work to other agents, and decides when it's done.

This article walks through the orchestration patterns that show up most often in exam scenarios, with runnable Python illustrations built on the anthropic SDK.

Summary

Multi-agent systems trade simplicity for capability, and the exam tests whether you know when that trade is worth making.

A single well-scoped agent with good tools beats a poorly decomposed multi-agent system almost every time.

The core patterns worth knowing are sequential pipelines, supervisor-worker topologies, and parallel fan-out with a merge step.

Every pattern needs an explicit termination condition, or it risks looping past the point of being useful.

Orchestration questions on the exam usually hinge on picking the smallest architecture that solves the problem, not the most sophisticated one.

Recipe

Quick-reference recipe card - the minimal shape of a supervisor-worker loop.

from anthropic import Anthropic
 
client = Anthropic()
 
def run_worker(task: str, model: str = "claude-sonnet-5") -> str:
    """A single-purpose worker agent that does one job and returns."""
    response = client.messages.create(
        model=model,
        max_tokens=1024,
        system="You are a focused worker agent. Do exactly the task given. Return only the result.",
        messages=[{"role": "user", "content": task}],
    )
    return response.content[0].text
 
def run_supervisor(goal: str, max_steps: int = 5) -> str:
    """A supervisor that decomposes a goal into worker tasks and stops on completion."""
    completed_work = []
    for step in range(max_steps):
        plan_prompt = f"Goal: {goal}\nCompleted so far: {completed_work}\nNext single subtask, or DONE if finished:"
        plan = run_worker(plan_prompt, model="claude-sonnet-5")
        if plan.strip().upper().startswith("DONE"):
            break
        result = run_worker(plan)
        completed_work.append({"task": plan, "result": result})
    return "\n".join(w["result"] for w in completed_work)

When to reach for this:

• The goal decomposes naturally into a small, bounded number of independent subtasks.
• Each subtask benefits from a narrower system prompt than the overall goal would need.
• You need an explicit stop condition rather than an open-ended conversation.
• You're willing to pay the latency and cost of multiple model calls for better task isolation.

Working Example

from anthropic import Anthropic
from dataclasses import dataclass
 
client = Anthropic()
 
@dataclass
class AgentResult:
    agent_name: str
    output: str
 
def draft_agent(topic: str) -> AgentResult:
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=512,
        system="You draft a short technical outline. Return only the outline, no preamble.",
        messages=[{"role": "user", "content": f"Outline: {topic}"}],
    )
    return AgentResult("draft", response.content[0].text)
 
def critic_agent(draft: str) -> AgentResult:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=512,
        system="You critique a technical outline for gaps and factual risk. Be terse. Return only the critique.",
        messages=[{"role": "user", "content": draft}],
    )
    return AgentResult("critic", response.content[0].text)
 
def reviser_agent(draft: str, critique: str) -> AgentResult:
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=768,
        system="You revise a draft outline given a critique. Return only the revised outline.",
        messages=[{"role": "user", "content": f"Draft:\n{draft}\n\nCritique:\n{critique}"}],
    )
    return AgentResult("reviser", response.content[0].text)
 
def orchestrate_draft_critique_revise(topic: str) -> str:
    """A three-agent sequential pipeline: draft -> critic -> reviser.
 
    Each agent has one job and a narrow system prompt, which is the
    pattern the exam calls 'single-responsibility agent design.'
    """
    draft = draft_agent(topic)
    critique = critic_agent(draft.output)
    final = reviser_agent(draft.output, critique.output)
    return final.output
 
if __name__ == "__main__":
    result = orchestrate_draft_critique_revise("Zero-downtime database migration strategy")
    print(result)

What this demonstrates:

• A sequential pipeline where each agent's output becomes the next agent's input, with no shared mutable state.
• Deliberate model mixing: a stronger model (Opus 4.8) for the critique step, where judgment quality matters most, and a faster model (Sonnet 5) for drafting and revision.
• Single-responsibility system prompts per agent, which the exam tests as a design principle distinct from prompt engineering itself.
• No loop or termination logic needed here, because the pipeline has a fixed, known length, which is itself a design choice worth recognizing.

Deep Dive

How It Works

• A sequential pipeline passes output forward through a fixed chain of agents; it's the right shape when the number of steps is known in advance.
• A supervisor-worker topology has one agent plan and dispatch, and one or more worker agents execute; it's the right shape when the number of steps is not known until runtime.
• A parallel fan-out dispatches the same or related subtasks to multiple agents concurrently, then merges results; it's the right shape when subtasks are independent and latency matters more than sequencing.
• Every non-trivial orchestration needs an explicit termination condition: a step budget, a "DONE" signal the supervisor can emit, or a validation check that confirms the goal is met.
• Context handoff between agents is a design decision, not a given: pass only what the next agent needs, not the entire conversation history, or you inflate every downstream call's token cost.

Orchestration Patterns at a Glance

Termination and Loop Safety

MAX_STEPS = 8
 
def safe_supervisor_loop(goal: str) -> str:
    step = 0
    history = []
    while step < MAX_STEPS:
        step += 1
        next_action = run_worker(f"Goal: {goal}\nHistory: {history}\nNext step or DONE:")
        if "DONE" in next_action.upper():
            break
        history.append(next_action)
    else:
        # Loop exhausted MAX_STEPS without a DONE signal - treat as a failure, not a success.
        raise RuntimeError(f"Supervisor did not terminate within {MAX_STEPS} steps for goal: {goal}")
    return "\n".join(history)

A hard step budget combined with an explicit failure path (rather than silently returning a partial result) is the pattern the exam rewards: an agent that can't tell you it failed is worse than one that raises.

Python Notes

# Prefer typed dataclasses or TypedDicts for inter-agent payloads over raw dicts,
# so a schema mismatch between agents fails fast instead of surfacing as a
# confusing downstream prompt-formatting bug.
from typing import TypedDict
 
class SubtaskResult(TypedDict):
    agent: str
    task: str
    output: str

Gotchas

• Adding a second agent when a bigger tool would do. A single agent with a well-designed tool often replaces a whole "helper agent." Fix: try expanding the tool surface before you reach for orchestration.
• No termination condition on a supervisor loop. Left unbounded, a planning loop can run until it exhausts budget or context. Fix: always set a hard step ceiling and treat exceeding it as a raised error, not silent truncation.
• Passing full conversation history to every worker. This multiplies token cost linearly with pipeline depth for no benefit. Fix: pass only the specific fields the next agent actually needs.
• Using the same model and system prompt for every agent in the pipeline. This wastes the chance to match model strength to task difficulty. Fix: reserve a stronger model for judgment-heavy steps like critique or synthesis.
• Treating parallel fan-out as free. Concurrent calls still consume rate limits and cost the same per-call price; fan-out reduces latency, not cost. Fix: size the fan-out to actual independent subtask count, not for its own sake.
• No merge strategy defined before fan-out starts. If you don't know how you'll reconcile conflicting worker outputs, you'll improvise it badly under pressure. Fix: design the merge (for example, "supervisor arbitrates," "majority vote," "concatenate") before dispatching.

Alternatives

FAQs

Related

• What the Claude Certified Architect Exam Actually Tests - the overall exam mental model this domain fits into.
• CCA Foundations Exam Domains at a Glance - where this 27% domain sits relative to the other four.
• Tool Design, MCP Integration, and Context Management: CCA Domain Checklist - the tool-design decisions that often determine whether orchestration is even necessary.
• Case Study: Building a Production Customer Support Agent End to End - these orchestration patterns applied to a full production build.
• CCA Foundations Best Practices - practical guidance for applying orchestration patterns to real builds.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, pricing, exam format, and SDK versions move quickly - verify current specifics at platform.claude.com/docs and the official CCA exam guide before relying on them.