CCA Domain 1 Study Guide: Agentic Architecture and Orchestration

Purpose and accuracy note

This guide prepares candidates to reason about agentic architecture in the Claude ecosystem. It is designed for scenario-based questions: given a task, constraint, failure, or risk, choose the simplest architecture that is safe, observable, and reliable.

Anthropic publicly announced Claude Certified Architect, Foundations in March 2026 as a technical certification for solution architects building production applications with Claude. However, a public official exam blueprint confirming that Domain 1 is exactly 27% of the score was not found during this update. Treat any domain weight, question count, or scoring detail as valid only when it appears in your current official candidate guide or partner portal.

This is an independent study guide, not an official Anthropic exam guide.

1. The central idea: workflow or agent?

A workflow follows a path defined mainly by code. An agent decides its next steps dynamically, calls tools, observes results, and continues until it reaches a goal or termination condition.

• •Choose a workflow when: the steps and order are known in advance.
• •Consistency and auditability matter more than flexibility.
• •Business rules must always be enforced.
• •The task can be expressed as a pipeline, branch, router, or fixed parallel fan-out/fan-in process.

• •Choose an agent when: the correct sequence cannot be fully predicted beforehand.
• •The system must inspect intermediate results and adapt.
• •Tool selection and investigation require judgment.
• •The problem is open-ended, multi-step, or involves exploration.

Exam rule: do not use an agent merely because the technology is available. A single API call or deterministic workflow is usually better for a simple, stable task. Extra agents add latency, cost, failure points, and coordination overhead.

2. The agent loop

• •Receive a goal and relevant context.
• •Reason about the next useful action.
• •Select a permitted tool or delegate a bounded subtask.
• •Execute the action outside the model.
• •Return the result as an observation.
• •Update state and decide whether to continue.
• •Stop when success, a defined limit, or an escalation condition is reached.

A production loop needs more than “keep going until done.” It should define a clear success condition; maximum iterations, time, tokens, and cost; tool permissions and approval rules; structured handling for tool errors; retry limits and backoff; a human-escalation path; and traceable events and outputs.

Common exam trap: retrying the same failed operation without changing anything is not self-healing. Recovery requires interpreting the error, deciding whether it is retryable, changing the approach when appropriate, and stopping safely when recovery is not justified.

3. Single agent or multi-agent?

• •Prefer one agent when: one context is sufficient.
• •The same tools and instructions apply throughout.
• •Subtasks are tightly coupled.
• •Coordination would cost more than specialization saves.

• •Use subagents when: a subtask needs a distinct role, system prompt, tool set, or model.
• •A side investigation would flood the main context with logs, search results, or files that are needed only temporarily.
• •Independent work can run in parallel.
• •Separation improves permissions, evaluation, or fault isolation.
• •The same specialist task is repeatedly delegated.

Anthropic's current Claude Code documentation describes subagents as isolated, specialized assistants with their own context window, system prompt, tool access, and permissions. They return a focused result to the main conversation.

The minimal-footprint principle: give each agent only the tools, context, and authority needed for its role. A drafting agent should not automatically receive send or delete tools. A synthesis agent should not receive unrestricted search access when its job is only to reconcile supplied findings. Smaller tool sets usually improve tool selection and reduce accidental actions.

4. Orchestration patterns you must recognize

• •Sequential pipeline: Output from one step becomes input to the next — extract, classify, analyze, write, validate. Risk: one slow or failed step blocks everything downstream. Design response: validate at boundaries, checkpoint progress, and define fallback or partial-result behavior.
• •Parallel fan-out and fan-in: Independent subtasks run concurrently and results are combined — searching multiple sources, reviewing independent document sections, obtaining separate specialist assessments. Risk: duplicate work, conflicting outputs, race conditions, difficult synthesis. Design response: non-overlapping scopes, result schemas, timeouts, and a synthesis policy that preserves attribution and surfaces contradictions instead of silently inventing agreement.
• •Router and specialists: A router classifies the request and sends it to the right specialist; use for clearly separable request types. Risk: routing errors and ambiguous requests. Design response: explicit routing criteria, confidence thresholds, a fallback route, and routing evaluated separately from downstream task quality.
• •Coordinator and workers (hub-and-spoke): A central coordinator decomposes the goal, delegates bounded tasks, tracks coverage, and integrates results. Risk: the coordinator becomes a bottleneck or decomposes too narrowly. Design response: a coverage checklist, parallel independent tasks, and iterative refinement when gaps remain.
• •Evaluator-optimizer: One component generates output; another evaluates it against explicit criteria and requests targeted revision. Risk: endless revision or vague criticism. Design response: measurable acceptance criteria, a revision limit, and a clear final decision rule.
• •Hierarchical orchestration: A top-level coordinator delegates to lower-level coordinators or specialists for genuinely large tasks. Risk: excessive layers, information loss, high cost. Design response: use only when one coordinator cannot manage the breadth; standardize contracts and retain trace IDs across levels.
• •Dynamic decomposition: The coordinator creates subtasks at runtime based on the goal and discoveries, suited to open-ended research. Risk: unbounded expansion, duplicated work, missed domains. Design response: impose budgets, deduplicate tasks, track coverage, and require termination conditions.

5. Subagent contracts and communication

• •Objective: the exact outcome required.
• •Scope: what is included and excluded.
• •Inputs: only the context needed for the task.
• •Tools: the permitted tools and data sources.
• •Output contract: structure, evidence, uncertainty, and attribution.
• •Limits: time, cost, iterations, and stop conditions.
• •Escalation: what to do when blocked or uncertain.

Prefer concise, structured handoffs over passing the entire conversation. Passing everything increases cost and may distract the specialist. However, over-compression can remove critical facts. Keep durable facts, decisions, constraints, and identifiers in a stable state block; summarize disposable history separately.

Coordinator-mediated communication is generally easier to observe and control than unrestricted peer-to-peer messaging. Direct communication may be useful in a deliberately designed distributed system, but it increases coupling and makes ownership, tracing, and failure recovery harder.

6. Parallelism: when it helps and when it hurts

• •Good candidates: search separate sources; analyze independent files or sections.
• •Run independent evaluation dimensions.
• •Generate competing solution approaches for later comparison.

• •Keep sequential: validate identity before processing a refund.
• •Extract data before enriching it.
• •Complete reversible analysis before an irreversible action.
• •Wait for a schema or plan needed by downstream execution.

For concurrent code changes, isolate workspaces or Git worktrees to prevent agents from editing the same files unpredictably. For concurrent database writes, use transactions, version checks, locks, or compensation patterns.

7. State, sessions, checkpoints, and recovery

• •Conversation state: messages and reasoning context.
• •Workflow state: current step, completed tasks, dependencies, and status.
• •Business state: durable records such as orders, approvals, and transactions.
• •Artifact state: files, code, reports, and external resources.

Do not treat conversation history as the only state store. Long-running work should persist milestones, completed units, key facts, and artifact identifiers outside disposable context.

• •Resume: when you want to continue the same session and history.
• •Fork: when you want an independent branch from a shared baseline.
• •After change: when external files or business data change, tell the resumed agent exactly what changed so it can re-check stale assumptions.

• •Checkpointing: save progress after meaningful units of work.
• •Record inputs, outputs, version identifiers, and pending steps.
• •Resume from the last confirmed state, not from the beginning.
• •Make operations idempotent so replay does not create duplicate emails, payments, records, or notifications.

For a partially failed series of writes, use a transaction when possible. If a single transaction is not available across systems, use compensating actions and a saga-like workflow. Never quietly leave inconsistent partial state.

8. Deterministic controls, hooks, and human approval

Use model instructions for judgment. Use deterministic controls for invariants.

• •Model judgment suits: choosing a research approach, classifying ambiguous material, evaluating quality against a rubric, and deciding which optional specialist can add value.
• •Programmatic enforcement suits: refund limits, identity verification prerequisites, blocking prohibited commands or data access, mandatory tests or validation, and preventing an irreversible action without approval.

Claude Code hooks run custom logic at lifecycle events and provide deterministic control for rules that must always fire. Permissions should explicitly define which tools are allowed, blocked, or require approval.

Human approval should be required before high-impact, difficult-to-reverse, or sensitive actions — for example, modifying patient data, sending a final external communication, transferring funds, deleting data, or writing to production. Complete reversible analysis first, present the proposed action and relevant evidence, then request approval at the decision boundary.

• •Human control: people can approve, pause, redirect, and stop the agent.
• •Transparency: actions, limitations, and sources are visible.
• •Alignment with expectations: behavior matches the user's reasonable intent.
• •Security: tools, data, and permissions are constrained.
• •Privacy: collect and expose only necessary data.

9. Error handling and self-healing

• •Transient: rate limit, temporary network failure, service unavailable.
• •Permanent: invalid parameters, unsupported operation, missing resource.
• •Permission: authentication or authorization failure.
• •Business rule: policy limit, eligibility failure, validation rejection.
• •Malformed output: invalid JSON or unexpected schema.
• •Partial completion: some steps succeeded before failure.

Good tool errors include the error category, a human-readable explanation, whether retrying is appropriate, a suggested recovery action, and safe details needed to diagnose the failure.

• •Transient failure: exponential backoff with jitter and a retry cap.
• •Rate limit: respect retry timing; avoid simultaneous client retries.
• •Permission failure: do not loop; request authorization or use a permitted alternative source.
• •Malformed result: validate, normalize when safe, or ask the tool to retry with a constrained schema.
• •Business-rule failure: do not retry; explain the policy and escalate if an exception process exists.
• •Repeated failure: trip a circuit breaker, degrade gracefully, or escalate.

Every agentic loop needs a maximum iteration count and a termination condition. Infinite retry is never resilience.

10. Context, latency, and cost

Subagents can protect the main context by processing verbose material in an isolated window and returning only the useful result. This improves context hygiene, but every subagent still consumes tokens and adds coordination cost.

• •Send only task-relevant context.
• •Summarize completed tool results after extracting durable facts.
• •Keep critical facts separate from progressively summarized history.
• •Run independent tasks in parallel.
• •Use a cheaper model for simple bounded work and escalate complex reasoning to a stronger model.
• •Use programmatic tool calling for many mechanical tool operations when the model does not need to inspect every raw result.
• •Cache reusable static prefixes where supported.

Do not optimize only for tokens. End-task correctness, safety, and user value are primary; latency and cost are constraints to balance against them.

11. Observability and evaluation

Trace the complete workflow, not only individual model calls. Useful fields include workflow and trace ID; agent/subagent role and version; task and parent-task ID; model and configuration; tool name, arguments classification, result status and latency; token usage and cost; retry count and error category; approval events; and final outcome and evaluation score.

• •End-task quality: did the system produce the correct, complete outcome?
• •Agent quality: did each specialist fulfil its contract?
• •Tool selection: was the right tool chosen with valid arguments?
• •Routing quality: was the request sent to the right specialist?
• •Safety: were permissions and approval boundaries respected?
• •Efficiency: were latency, tokens, and cost acceptable?
• •Recovery: did the system handle failures without corrupting state?

Use scenario-based evaluation sets and explicit rubrics. A component can have excellent tool-call accuracy while the overall task still fails; therefore, end-task quality should usually be the leading metric.

12. High-frequency exam traps

• •Trap 1: “Add a stronger prompt” for a rule that must never be violated. Better: enforce it programmatically with permissions, hooks, validation, or a prerequisite gate.
• •Trap 2: Give every agent every tool for convenience. Better: role-specific, scoped tools and least privilege.
• •Trap 3: Use multiple agents for a simple deterministic task. Better: simplify to a single call or workflow.
• •Trap 4: Run dependent steps in parallel. Better: parallelize only independent tasks.
• •Trap 5: Retry every error. Better: classify the error; retry only transient failures with limits.
• •Trap 6: Restart the entire workflow after partial failure. Better: checkpoint, resume from confirmed progress, and make steps idempotent.
• •Trap 7: Let a synthesis agent silently resolve contradictions. Better: preserve attribution, flag disagreement, and request evidence or targeted verification.
• •Trap 8: Pass the entire conversation to every subagent. Better: provide a bounded brief plus required facts and constraints.
• •Trap 9: Measure only latency or token usage. Better: prioritize end-task quality and safety, then optimize efficiency.
• •Trap 10: Assume “self-healing” means repeated retries. Better: reason over error metadata, change strategy, and escalate safely.
• •Trap 11: Allow irreversible actions early in the workflow. Better: complete reversible investigation and validation first; obtain approval immediately before the consequential action.
• •Trap 12: Use shared mutable state without concurrency control. Better: transactions, versioning, locks, immutable messages, or a single owner for state transitions.

13. Rapid scenario decision framework

• •Is the task deterministic or genuinely open-ended?
• •Does it need one agent, a workflow, or specialized agents?
• •Which steps are independent and can run in parallel?
• •Where should state live, and how will work resume?
• •What tools does each role truly need?
• •Which rules require deterministic enforcement?
• •Where is human approval required?
• •What can fail, and is the failure retryable?
• •How will partial completion be recovered or compensated?
• •How will the full path be traced and evaluated?

If two answers seem plausible, prefer the one that solves the stated failure directly, uses the least unnecessary complexity, enforces mandatory constraints deterministically, limits tools and authority, preserves data integrity, and provides bounded recovery and observability.

14. Seven-day study plan

• •Day 1 — Foundations: Learn workflow versus agent, draw the agent loop, and practise identifying where autonomy is and is not justified.
• •Day 2 — Patterns: Study pipeline, parallel fan-out/fan-in, router-specialist, coordinator-worker, evaluator-optimizer, and hierarchy. For each, write one suitable and one unsuitable use case.
• •Day 3 — Subagents and tools: Define three subagents with distinct prompts and tool sets, practise writing delegation contracts, and review least privilege and tool-selection failure.
• •Day 4 — State and reliability: Study sessions, resume, fork, checkpoints, idempotency, transactions, and compensation. Work through partial-failure scenarios.
• •Day 5 — Safety and governance: Compare prompts, hooks, permissions, validation gates, and human approval. Identify irreversible actions and approval boundaries.
• •Day 6 — Errors, observability, and evaluation: Build an error taxonomy, practise retry, backoff, circuit-breaker, fallback and escalation decisions, and design a trace and an end-task rubric.
• •Day 7 — Exam simulation: Complete timed scenario questions. For every wrong answer, record symptom, root cause, best pattern, and why the alternatives fail. Review the rapid scenario framework and exam traps.

15. Final revision checklist

You are ready when you can explain, without notes:

• •Workflow versus agent.
• •Single agent versus multi-agent.
• •Six major orchestration patterns and their trade-offs.
• •How to write a bounded subagent contract.
• •When to parallelize and when not to.
• •Resume versus fork versus restart.
• •Checkpointing, idempotency, transactions, and compensation.
• •Prompts versus deterministic hooks and gates.
• •Least privilege and human-approval boundaries.
• •Error classification and bounded recovery.
• •Context hygiene, model routing, latency, and cost control.
• •End-task evaluation and distributed tracing.
• •The twelve high-frequency exam traps.

Official sources used for this update

• •Anthropic — Claude Partner Network and certification announcement: https://www.anthropic.com/news/claude-partner-network
• •Anthropic — Claude Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk
• •Anthropic — Create custom subagents: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• •Anthropic — Automate actions with hooks: https://docs.anthropic.com/en/docs/claude-code/hooks-guide
• •Anthropic — Common Claude Code workflows: https://docs.anthropic.com/en/docs/claude-code/common-workflows
• •Anthropic — Programmatic tool calling: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/programmatic-tool-calling
• •Anthropic — Tool use implementation: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• •Anthropic — Trustworthy agents in practice: https://www.anthropic.com/research/trustworthy-agents
• •Anthropic — Long-running Claude for scientific computing: https://www.anthropic.com/research/long-running-Claude
• •Anthropic — Claude Code CLI reference (resume and fork): https://docs.anthropic.com/en/docs/claude-code/cli-reference