CCA-P Domain 1: Claude Platform & Solution Design
CCA-P Domain 1: Claude Platform & Solution Design
Domain 1 of the Claude Certified Architect – Professional exam. Covers the properties Claude has as a system, the layers and primitives an architect composes with, and the sequence of decisions (decomposition → pattern → reference architecture → model/context/entry point) that produces a defensible design.
TL;DR
- Four properties architects design around: next-token prediction (fluent but imprecise on specifics), knowledge (broad but bounded by training cutoff and rarity), working memory (context window is a hard edge, not a suggestion), steerability (confidence ≠ validity — Claude can follow the letter of an instruction while missing its intent).
- Three layers must stay distinct: entry points (Claude.ai, Claude Code, custom app — chosen by user/work), build-time interfaces (API, SDKs, MCP, Agent SDK — chosen by engineering team), delivery routes (Anthropic direct, Bedrock, Vertex, Foundry — chosen by cloud commitments/compliance). Collapsing them causes muddled architecture conversations.
- Seven primitives, one job each: Tools (act), MCP (connect), Subagents (isolate/parallelize), Hooks (guarantee — deterministic, can’t be skipped), Skills (package a procedure), Agent Teams (coordinate peers), Dynamic Workflows (compose at runtime). Use the fewest necessary — heavier primitives cost latency, tokens, and operational surface.
- Decomposition asks “where do the four properties argue for Claude over the system that already does this right?” — not “where can Claude help?” Criteria: reversibility, stakes, accountability.
- Pattern selection (Augmented LLM / Workflow / Agent) is decided by five factors: predictability, error cost, observability, latency, cost. The tightest constraint wins. Rule of thumb: if you could have written the steps in code, use a workflow.
- The #1 reference-architecture mistake is using retrieval where a tool call belongs — retrieval is for stable knowledge, tool use is for live state owned by a system.
- Model default is Sonnet; every swap (up to Opus, down to Haiku) is a release gated by an eval with a pre-set delta threshold. Not choosing a model = choosing the most expensive one.
- Regulated-industry constraints (privilege, HIPAA, GDPR, FedRAMP, internal data residency) rule out entry points and routes before any other tradeoff — they aren’t one factor among many, they come first.
Core Concepts
The Four Properties
| Property | Capability | Limitation | Mitigation |
|---|---|---|---|
| Next-token prediction | Summarizing, reformatting, explaining | Precision on names, dates, stats | Citations, uncertainty signaling, generator-verifier loops |
| Knowledge | Common, recent, consistent topics | Rare, niche, fast-changing topics | Web search, RAG, tools, MCP as external source of truth |
| Working memory | Anything in the active context window | Hard edge — outside window = no access | Progressive loading, chunking, summarizing across turns |
| Steerability | Short, concrete, verifiable instructions | Abstract instructions, precise computation | System prompts, structured outputs, code execution |
A demo running cleanly five times is not evidence of determinism — evaluation frameworks exist precisely because behavior can’t be certified from one observation. At the context edge, two distinct errors occur: an oversized request (400 invalid_request_error or 413 request_too_large, rejected before generation) versus a generation ceiling (model_context_window_exceeded stop reason, truncated mid-output).
Decomposition — Claude, Systems, or Humans
| Owner | What Belongs Here | Delegation Criteria |
|---|---|---|
| Claude | Language understanding, summarization, planning, drafting, tool-mediated action | — |
| Existing systems | Anything already reliable: order-status service, policy engine, rules table, DB of record | Reversibility, stakes, accountability |
| Humans | Judgment calls, exception paths, approvals, high-stakes decisions | — |
Moving deterministic logic (a rules table) into the model trades a predictable, debuggable failure for a variable, hard-to-observe one — and the model has no reliable way to flag that its information is stale.
Pattern Selection
| Pattern | Predictability | Autonomy | When to Use |
|---|---|---|---|
| Augmented LLM | High | Low | Single bounded task, verifiable output, no branching |
| Workflow | Medium | Medium | Predictable shape, bounded model judgment per step |
| Agent | Low | High | Steps can’t be determined in advance, open-ended investigation |
Workflow sub-patterns: chaining (sequential handoffs), routing (classifier picks the downstream path), parallelization (independent sub-tasks, aggregated/voted), evaluator-optimizer (generate → evaluate → revise loop). Progression before fine-tuning: prompt → tools/retrieval → stronger pattern → fine-tuning last. In multi-agent systems, subagent failure is usually recoverable (retry, re-route, flag); orchestrator failure is usually unrecoverable — the whole run fails. The critical synthesis-step fix: a coverage check where results returned must equal units dispatched.
Reference Architectures & RAG
| Architecture | Pattern | Key Failure Mode |
|---|---|---|
| Agent | Agentic exploration | Non-deterministic trajectory failures |
| RAG | Retrieval-augmented generation | Retrieval applied to live state (#1 mistake) |
| Document processing pipeline | Evaluator-optimizer | No exception path for low-confidence extractions |
| Customer service / ticket triage | Routing | Missing escalation path, unguarded tools |
| Coding agent | Agentic + deterministic edit/test/review | — |
Retrieval principle: retrieval = stable knowledge (true yesterday, true tomorrow); tool use = live state (current value owned by a system). RAG chunking is chosen by source structure — fixed-size for homogeneous text, semantic for self-contained prose, hierarchical for structured docs (contracts, manuals). Indexing is chosen by query pattern — dense (embeddings) for semantic matching, sparse (BM25) for exact terms/identifiers, hybrid (merged via reciprocal rank fusion) for mixed patterns. The trade-off triangle is retrieval quality ↔ latency ↔ maintenance — there’s no universally right point, only the point that fits the corpus and the queries.
Model & Context Strategy
Sonnet is the default; move to Opus only when an eval says Sonnet misses the quality bar, move to Haiku only when an eval confirms the tradeoff is acceptable. An eval gate needs: a curated golden dataset covering the real distribution, a grading function, and a delta threshold set before running the eval.
| Context Strategy | What It Does | When |
|---|---|---|
| Monolithic | Everything in the prompt at once | Bounded tasks, predictable input |
| Progressive | Only what the next step needs | Most production workloads |
| Retrieval (RAG) | Fetch relevant chunks at query time | Large corpus, can’t preload |
| Compaction | Periodically summarize/compress | Long-running, context filling |
Budget for the largest realistic conversation plus retrieved context plus system prompt plus margin — the context window is a ceiling, not a target. Extended/adaptive thinking should be enabled only when a measured accuracy gap justifies the added latency and token cost — “it can’t hurt” is not a valid reason.
Entry Points, Governance & Delivery Routes
| Entry Point | Audience | Key Tradeoff |
|---|---|---|
| Claude.ai | Knowledge workers, no code | Zero build cost vs. zero integration |
| Claude Code | Engineers | Purpose-built for code, wrong for non-engineering audiences |
| Agent SDK | Product embedding an agent loop | Managed loop vs. fine-grained control |
| MCP | Same tools across multiple clients | Reusability vs. complexity — skip if only one client |
Delivery routes (Anthropic direct, AWS Bedrock, GCP Vertex, Microsoft Foundry) don’t change model behavior, prompting, eval, tool use, or context-window behavior — they change model identifiers, regional availability, and CSP-side features. CSP routes lag first-party by weeks. Regulated-industry constraints rule out options before other tradeoffs: attorney-client privilege rules out consumer Claude.ai; HIPAA requires a per-configuration BAA; GDPR requires region pinning; FedRAMP requires an authorized cloud environment.
Common Pitfalls
- Pitfall: Framing decomposition as “where can Claude help?” Why: this framing over-assigns work to Claude by default. Fix: ask “where do the four properties argue for Claude over the system that already does this right?”
- Pitfall: Choosing an agent because the task “feels” open-ended. Why: many tasks that feel open-ended actually decompose into a small, knowable number of branches. Fix: if you could write the steps in code, use a workflow — reserve agents for genuinely undeterminable trajectories.
- Pitfall: Using RAG to answer questions about live state. Why: retrieval reflects the index at refresh time, not the system of record right now. Fix: call the system that owns the live value directly; reserve retrieval for stable knowledge.
- Pitfall: Swapping models without an eval gate. Why: “the newer model is probably better” isn’t evidence; a 7× cost overrun or an unnoticed quality regression can follow. Fix: every swap is a release — curated dataset, grading function, pre-set delta threshold.
- Pitfall: Choosing an entry point before naming the audience. Why: putting Claude Code in front of non-engineering staff, or Claude.ai in front of a privilege-bound workflow, collapses the entry-point/build-time/delivery-route layers into “it’s all Claude.” Fix: name the audience and the governance constraint first; let them select the entry point.
Interview Questions
Q — Why is “a demo running cleanly five times” not evidence of determinism, and what’s the architectural consequence? Claude is a non-deterministic system — the same input can produce different outputs across runs, and five clean passes are a small, non-representative sample. The architectural consequence is that evaluation frameworks exist precisely because you can’t certify behavior from a handful of observations; every meaningful change (prompt, model, retrieval config) needs a golden dataset and a repeatable grading method before it ships.
Q — A partner wants Claude to “decide claim priority.” Why should that go to an existing system instead? Priority is typically a deterministic rule the partner already defines and maintains in a rule engine — it’s not knowledge Claude was trained on, and routing it to Claude introduces an unnecessary knowledge-boundary risk for a decision that should be traceable and debuggable every time. Claude should call the rule engine and act on its answer, not re-derive the rule itself.
Q — What’s the difference between the Anthropic SDK and the Agent SDK, and when would you reach for each? The Anthropic SDK is a convenience wrapper over the API — it handles auth, streaming, and retries but does not run an agent loop. The Agent SDK is a managed runtime that runs the same iterate/tool-execute/terminate loop that powers Claude Code, embeddable inside a partner’s own product. Reach for the Anthropic SDK when you’re making direct calls and own the loop yourself; reach for the Agent SDK when you want a managed multi-turn agent without building the loop from scratch.
Q — Walk through why Option D is the only defensible answer in the contract-review assembly exercise (five decisions: entry point, pattern, decomposition, model, human-in-the-loop). Option D holds because every decision satisfies the binding constraint: entry point is direct API/SDK behind SSO and an approved gateway (privilege requires the firm to own the audit trail, ruling out Claude.ai); pattern is a parallelized workflow because the contract’s sections are independent, not open-ended; decomposition keeps the playbook as a versioned, retrieved source of truth rather than frozen in the system prompt (so it doesn’t go stale); the model is Sonnet by default with progressive context and extended thinking gated by eval, not Opus everywhere; and a senior associate signs off with low-confidence clauses flagged. Every other option violates exactly one governing constraint — Claude.ai fails privilege, a frozen playbook fails the knowledge boundary, and an open-ended agent with Opus-everywhere fails both the pattern-fit and cost disciplines.