Domain 1 — Agentic Architecture & Orchestration — carries more weight than any other section of the CCA Foundations exam: 27% of your final score, more than the next two domains combined would need to add up to match it. If you're going to over-invest your study time anywhere, this is where the math says to do it. It's also, not coincidentally, the domain that tests the kind of judgment that's hardest to fake: not "do you know what an agent loop is" but "can you tell when a sophisticated-sounding architecture is the right call, and when it's expensive overkill."
This domain sits inside our full breakdown of all five exam domains — here we go one level deeper into what it actually tests, how it shows up in scenario questions, and where candidates lose marks they should have kept.
What This Domain Actually Tests
Strip away the terminology and Domain 1 is asking one core question, repeatedly, from different angles: given this task, what is the simplest architecture that reliably gets it done? The topics it draws on to ask that question include:
- The agent loop — gathering context, taking action, checking the result, and deciding what happens next
- Single-agent designs versus orchestrator-and-subagent patterns
- When running work in parallel actually helps, and when it just adds coordination cost
- Reliability mechanics: retries, checkpoints, and human-in-the-loop gates for high-stakes actions
- Scoping autonomy — minimal footprint, reversible actions, and clear escalation boundaries
Orchestrators and Subagents: A Pattern, Not a Default
The orchestrator/subagent pattern — one coordinating agent that delegates focused pieces of work to specialised subagents — is one of the most useful architectures in this domain, and one of the most over-applied the first time you encounter it. It earns its complexity when subagents genuinely benefit from an isolated context (so a long research detour doesn't pollute the main conversation), when separate permission boundaries matter (a billing-lookup subagent shouldn't carry the same authority as the agent that issues refunds), or when independent pieces of work can run concurrently without stepping on each other.
It does not earn its complexity just because a task involves "multiple steps." Plenty of multi-step tasks are best served by a single agent working through a sequence of tool calls — orchestration adds latency (agents have to hand off and wait on each other), cost (more model calls), and failure surface (more places for a handoff to go wrong). The exam consistently rewards candidates who can recognise when a single, well-equipped agent is the correct, boring, reliable answer.
Worked Scenario: Designing a Support-Ticket Triage System
Imagine a SaaS company wants to automate the first pass of its support queue. Incoming tickets need to be classified by topic and urgency, matched against account and billing records, drafted a response, and — for billing disputes above $500 — routed to a human for review before anything goes out. How would you architect this?
A reasonable first instinct is "one agent, several tools": a classification step, an account-lookup tool, a drafting step, all run by a single agent in sequence. For a low-volume queue with simple disputes, that's often exactly right — it's simpler to build, easier to debug, and has fewer places to fail.
The case for an orchestrator with subagents strengthens as the scenario does. If tickets need to be processed concurrently at real volume, an orchestrator can dispatch independent tickets to parallel subagent runs without their contexts colliding. If the billing lookup touches sensitive financial data, scoping it to a subagent with narrowly-permissioned, read-only tools — rather than handing those same tools to the agent that also drafts customer-facing replies — is a meaningful security improvement, not just an architectural nicety.
And the $500 escalation threshold is the detail that separates a correct design from an almost-correct one: that check has to be enforced in code, at the orchestration layer, as a hard gate the agent cannot route around — not as an instruction in a prompt asking the agent to "escalate disputes over $500." A prompt is guidance. A threshold that protects customers and the business from the wrong message going out needs to be a guarantee.
Traps That Catch Candidates in This Domain
- Reaching for multi-agent because it sounds more sophisticated. The exam rewards matching architecture to actual task complexity — not the most elaborate-sounding option on the answer list. If a single agent with the right tools gets the job done reliably, that's the correct answer, even when a fancier-looking alternative is sitting right next to it.
- Treating "parallel" as a synonym for "faster." When step B genuinely depends on the output of step A, running them in parallel doesn't speed anything up — it produces wrong answers, race conditions, or work that has to be redone once the dependency is discovered. Look for the dependency in the scenario before reaching for concurrency.
- Skipping the verification step to save a round trip. An agent loop that acts without checking whether the action actually achieved its goal compounds small errors into large ones across a long run. Scenario questions often present the "fast" answer as one that skips verification — and the correct answer puts it back in.
- Putting safety-critical control flow in the prompt. Escalation thresholds, approval gates, and irreversible-action checks belong in code the model cannot talk its way around — a theme this domain shares with several others, and one we cover in more depth in our anti-patterns guide.
Domain 1 rewards pattern recognition built through repetition more than memorised definitions — which is exactly what scenario practice is for. Work through our free practice question bank (400 scenario-based questions across all five domains, each with a full explanation) to build that instinct, or take the free 10-question diagnostic to see how your Domain 1 judgment scores right now, before you commit a study plan to it.