Claude Certified
Architect
Everything developers need to know to pass the Foundations exam — 5 domains, 40 slides, zero fluff.
The exam doesn't test API syntax. It tests whether you'd make the right call in a production failure.
Know these numbers before you sit the exam
Allocate your study time by domain weight
Every question follows the same anatomy
Agentic Architecture & Orchestration
The heaviest domain. Covers loops, multi-agent topology, hooks, decomposition patterns, and error handling. Win this and you're most of the way there.
Memorise these before anything else in Domain 1
When unsure, apply the rule that matches the stakes and the failure type.
- Deterministic beats probabilistic when stakes are real. Financial, security, compliance, safety → hooks or programmatic gates. Style and formatting → prompts.
- Trace failures to their origin. Scope problems live upstream (decomposition, partitioning, context-passing). Don't blame the subagent that faithfully executed a bad brief.
- Proportionate fixes. Single agent beats multi-agent when single suffices. Prompts beat hooks when stakes are low. Never over-engineer.
stop_reason is the ONLY authoritative termination signal
tool_use → execute tools, append tool_result blocks as role: "user", loop back. end_turn → done.Hub-and-spoke. Always.
Coordinator at centre. Subagents are spokes. ALL communication routes through the coordinator. Subagents never talk to each other — ever.
- Enables observability and consistent error handling
- Coordinator's 7 jobs: decompose → select → partition scope → pass context → aggregate → refine → route
- Missing
"Task"from allowedTools → coordinator physically cannot delegate
Subagents start with nothing.
Subagents do NOT inherit coordinator history. Do NOT share memory across invocations. Every byte they need must be in their prompt.
- Missing topics → decomposition too narrow
- Duplicated work → scope partitioning sloppy
- Shallow on every topic → subagent prompts or tool budgets
- Missing source attribution → context-passing destroyed metadata
High-stakes enforcement requires hooks. Prompts are not enough.
PreToolUse — fires BEFORE tool executes
Gates, authorisation, prerequisite checks, financial limits, capturing prior state hash for audit. The only hook that can prevent an action from happening.
Keyword triggers: "prior state," "pre-condition," "before X happens," "must not proceed unless," "refund verification," "trade limits," "compliance check," "age gate."
The decision rule: if a single failure causes financial loss, security breach, regulatory violation, or safety harm → programmatic enforcement. If it causes only bad-but-recoverable UX → prompts.
PostToolUse — fires AFTER tool, before model sees result
Normalisation (timestamps, currencies, field names), redaction (PII), truncation, enrichment, result logging. The model never sees the raw tool output — only the post-processed version.
Keyword triggers: "heterogeneous formats," "normalise," "redact," "model confused by varying outputs," "strip PII before model sees it."
Hooks vs subagents: rule that must be enforced → hook. Capability that needs different reasoning/prompt/tools → subagent. Hooks don't rank tools — use prompts + tool descriptions for preference.
Match the pattern to the task structure — not the task complexity
Pattern 2 vs Pattern 3 discriminator: typed roles → dynamic decomposition; uniform clones → orchestrator–worker.
- Fixed Sequential Pipeline — stable structure, each step consumes prior output. Tell: "every email follows the same flow."
- Dynamic Decomposition (typed subagents) — varying requests, role-typed subagents (search / doc / synth). Same types, scope varies per query.
- Orchestrator–Worker — uniform workers differentiated only by prompt-supplied scope. N research workers each handling a different sub-topic.
- Evaluator–Optimiser — explicit checkable quality criteria, first pass often inadequate. Iterate until coverage / citations / format pass. Fails when criteria aren't objectively checkable.
Classify before acting — never blanket retry
- Transient (429, 503, network blip) → retry with exponential backoff + jitter, capped
- Permanent (400, 401, 403, 404, malformed input) → don't retry — feed back to model or escalate
- Logical (tool returned empty/irrelevant) → feed back to model with context, model changes strategy
Silent error swallowing (returning empty string) = model produces confident wrong answers. Always surface errors.
Double-charge protection and circuit breakers
- Idempotency key: generate UUID / hash of {operation + customer + amount} on first attempt, pass on every retry. Without this, a transient retry can double-charge.
- Paired-fix pattern: broken retry policy AND duplication? Need both error classification AND idempotency keys. Either alone is insufficient.
- Circuit breaker: N failures in window → stop calling for cooldown
- Per-tool timeouts: no tool blocks the loop indefinitely. Timeout + fallback, not prompt instruction.
Tool Design & MCP Integration
Misrouting, structured errors, tool_choice, MCP credential safety, Grep vs Glob. The layer-awareness rule matters here more than anywhere else.
Misrouting is always a description problem first
Tool descriptions ARE the routing layer. The model has nothing else when choosing between similar tools.
- 1st — Expand descriptions (correct): low effort, high leverage, fixes root cause
- 2nd — Few-shot in system prompt: treats symptom, token overhead every call
- 3rd — Merge tools: loses useful semantic distinction, high refactor cost
- 4th — Train classifier: extra model call, latency, new failure point
What a production-grade tool description contains
- Primary purpose — one sentence
- Input contract — formats, types, constraints
- Example queries it handles well — concrete strings
- Edge cases and limitations — what it won't do
- Explicit boundaries vs similar tools — "Use this for X. For Y, use other_tool." ← the one most teams skip
Code smell: "or" / "depending on" in a description → split the tool into purpose-specific ones.
isError: true means the tool couldn't look. isError: false + empty means it looked and found nothing.
Four error categories — memorise the table
Transient (network timeout, 503, rate limit) — retryable with same input. Backoff + retry, then escalate.
Validation (wrong format, missing field) — retryable only after correcting input. Correct and retry.
Business (refund exceeds limit, account locked) — NOT retryable. Switch workflow; surface description to user.
Permission (401, 403, missing scope) — NOT retryable by this agent. Escalate or request elevated creds.
The most-tested 2.2 trap
Returning [] for both "no such customer" AND "database unreachable" is the canonical exam trap. The agent retries endlessly and escalates with a misleading description when the real answer was "this customer doesn't exist."
Access failure (tool can't reach source) → isError: true, decide whether to retry.
Valid empty result (tool queried successfully, found nothing) → isError: false, empty array/null. Tell user "no results."
In multi-agent systems: subagents handle local recovery. Only propagate what they cannot resolve. Coordinator evaluates partial results rather than aborting on one failure.
Prompts request. tool_choice requires.
- "auto" (default) — model may or may not call a tool
- "any" — model MUST call some tool, of its choice
- {"type":"tool","name":"X"} — model MUST call this specific tool
15% of messages skip a mandatory first step despite a system prompt instruction? Fix: tool_choice: {"type":"tool","name":"extract_intent"}. Miss rate → 0%.
Tool overload rule
4–5 tools per agent is the production sweet spot. Reliability degrades sharply past 7–10 — softmax over descriptions thins probability margins.
Scope tools to roles: synthesis agent should NOT have web_search. Web search agent should NOT have document analysis tools.
For high-frequency simple operations: give consuming agent a constrained version of the capability. Complex cases still escalate to the owner.
Shared config, personal credentials — always
- Project: .mcp.json (repo root) — version-controlled, committed, shared with team
- User: ~/.claude.json — personal, experimental, across all projects
- Credential leak fix: use
${JIRA_API_TOKEN}expansion, NOT the literal token in the file - Don't relocate to fix a leak — parameterise. A team integration belongs in .mcp.json. Also rotate the leaked token — git history is forever.
Build vs use decision: evaluate community MCP server first. Fork or post-process before building from scratch.
MCP resources vs tools
Tools = actions the agent can take.
Resources = content the agent can read (catalogues, schemas, summaries).
"Agent makes many exploratory tool calls at conversation start to discover available data" → expose resources that catalogue what's available. Agent reads catalogue once, then queries precisely.
MCP tool losing to built-ins → enhance the MCP tool's description with examples and explicit boundary clauses.
Grep searches content. Glob searches paths. Wrong choice = failed task.
Edit fallback ladder: expand anchor → Read+Write → replace_all. Never sed, never delete-and-recreate.
- Grep — searches file contents, returns matching lines. Use for: function callers, error messages, import statements, identifier occurrences. "What does the code say?"
- Glob — searches file paths, returns paths matching pattern. Use for: all test files (**/*.test.tsx), all configs. "What files exist?"
- Grep → Glob sequence: content-seeded discovery (find usages → find their tests). Glob → Grep: path-seeded check (known files → check contents).
- Anti-pattern: read everything upfront. Load entry points via Grep → Read selectively → Grep for next identifiers. Context budget killer otherwise.
Claude Code Configuration & Workflows
CLAUDE.md hierarchy, path-specific rules, skills, plan mode, CI/CD. The core rule: path prefix is the whole answer. ~/.claude/ is personal. .claude/ is shared.
Two devs, same repo, divergent behaviour → user-level config that was never committed
Universal standards. Ambient. Not opt-in.
Everything that needs to happen every interaction. British English in comments, testing frameworks, code style, security requirements.
- Project: .claude/CLAUDE.md or root CLAUDE.md
- Split into .claude/rules/ with paths: frontmatter when it gets large
- Never put on-demand workflows here — bloats every interaction
Task-specific workflows. Invoked when needed.
Skill frontmatter options to memorise verbatim:
- context: fork — verbose output stays in fork, only summary returns. Trigger: "clutters main conversation," "keep main context clean."
- allowed-tools: [Read, Grep] — restricts destructive actions. Trigger: "analyse only, must not modify."
- argument-hint: <feature-name> — prompts developer for required parameter when invoked without args.
- Personal customisation: create ~/.claude/skills/review-strict/ — different name, personal location, no impact on team.
"Pattern of files spread across the codebase" → path-specific rules
- Files in .claude/rules/ with YAML frontmatter declaring a glob pattern
- Loads ONLY when Claude Code is about to work on a matching file
- One rule file covers **/*.test.tsx everywhere — no N copies that drift
- Token efficient: not loaded for non-matching files
Why beats directory CLAUDE.md: glob patterns match files scattered anywhere. Directory CLAUDE.md cannot — you'd need copies in every directory.
Decision table
Always relevant → Project CLAUDE.md
One specific subdir → Directory CLAUDE.md
Pattern across codebase → Path-specific rules
On-demand workflow → Skill or command
Personal only → Same but in ~/.claude/
Use when approach is still open
- Large-scale changes (library migration across 45+ files)
- Multiple valid approaches exist — evaluate before committing
- Architectural decisions required (service boundaries, abstractions)
- Unfamiliar codebase needs exploration before design
- Trap: "mechanical" migration when libraries have different APIs — scale + interface differences = plan mode regardless
Explore subagent: isolates verbose discovery output. Search results stay in subagent, returns summaries to main conversation.
Use when approach is already decided
- Well-understood, narrow scope (single-file bug fix with clear stack trace)
- Mechanical changes (add a validation conditional, rename a variable)
- Correct approach already known
Valid hybrid: Plan mode → explore → produce concrete plan → exit plan mode → implement directly. Not a wrong answer — the exam tests this combination.
Five CI/CD failure patterns. The -p flag is the single most-tested detail.
Symptom → Fix mapping (memorise)
CI job hangs indefinitely → Claude Code waiting for interactive input → add -p flag. Never "increase timeout" or "redirect /dev/null."
PR comments need inline posting → output is narrative prose → --output-format json --json-schema together.
Duplicate comments on every new commit → no context about prior review → include prior findings + instruct "report only new or unaddressed issues."
Test generation + review isolation
CI generates duplicate tests → doesn't know what's already covered → provide existing test files in context alongside source file.
Low-quality CI tests → no test-value criteria → strengthen .claude/CLAUDE.md with testing standards and fixtures.
Session isolation: same Claude session that generated code is LESS effective at reviewing it — retains reasoning context, biased toward prior decisions. Use an independent review instance — fresh session, no prior context.
Prompt Engineering & Structured Output
Explicit criteria, few-shot, tool_use schemas, validation-retry, batch API, multi-instance review. The retry-vs-schema boundary is tested in almost every form.
Match mechanism to failure mode. Don't cross layers.
Most wrong answers in D4 apply the right idea at the wrong layer.
- Specific categorical criteria beat vague confidence adjectives. "Flag X, report Y, skip Z" beats "be conservative." Options containing "conservative," "careful," or "high-confidence" without categorical definition → almost always a distractor.
- Match the mechanism to the failure mode. Few-shot for inconsistent judgement. Schema design for fabrication. Validation-retry for output errors. Multi-instance for self-review limitations. Wrong-tool answers are the dominant distractor shape.
- Retry fixes output errors. Schema design fixes source gaps. Information genuinely absent from the source document is not recoverable through retry — only through nullable fields, "unclear" enums, or "other" categories.
Adjectives without categories drift across runs
- "Be conservative."
- "Only report high-confidence findings."
- "Use careful judgement."
- "Lower the confidence threshold for the noisy category" → keeps noise flowing
- "Add more instructions to the prompt for that category" → keeps noise flowing
- "Lower the temperature" → deterministic bad criteria is still bad criteria
High false-positive rate in one category destroys trust in ALL categories — including accurate ones. The fix: disable that category entirely while improving its prompt.
Three categories: what to flag, report, skip
- "Flag comments only when claimed behaviour contradicts actual code behaviour."
- "Report bugs and security vulnerabilities. Skip minor style preferences."
- Severity levels anchored with actual code examples per level — not prose descriptions that drift
- Example: Critical = SQL injection from unvalidated input + code snippet showing it
Noisy category: disable entirely → restore trust in remaining categories → improve prompt for disabled category → re-enable. Don't tighten in place.
"Inconsistent output despite detailed instructions" → few-shot examples, not more instructions.
Three deployment triggers — memorise verbatim
1. Detailed instructions alone produce inconsistent formatting.
2. Model makes inconsistent judgement calls on ambiguous cases.
3. Extraction tasks produce empty/null fields for information that exists in the document.
Construction rules: 2–4 targeted examples for ambiguous scenarios (not 10, not 1). Each example shows the reasoning for why one action was chosen over plausible alternatives. Purpose: generalisation to novel patterns, not matching pre-specified cases.
Hallucination reduction — exam favourite
Documents vary in structure: inline citations vs bibliographies, narrative prose vs structured tables. Few-shot examples covering varied structures dramatically reduce hallucination because the model learns the shape of valid extractions across formats.
Wrong distractors: "Add more detailed instructions covering all edge cases" (instructions grow linearly, edge cases grow combinatorially). "Add 10 diverse examples" (wrong count — 2–4 targeted on ambiguous cases beats 10 on solved cases). "Lower temperature to 0" (determinism isn't a judgement problem).
tool_use eliminates syntax errors. That's it. Not semantics. Not fabrication.
What tool_use does NOT prevent
Semantic errors — line items don't sum to stated total. Schema doesn't check arithmetic.
Field placement errors — right value, wrong field. Schema validates types, not meaning.
Fabrication — model invents values for required fields when source lacks information. All-required schemas are fabrication factories.
tool_choice reminder: "auto" for optional, "any" for must-call-something, named for must-call-this specific tool.
Anti-fabrication toolkit
Optional / nullable fields — source legitimately lacks info → prevents fabrication. "Add 'do not fabricate' while keeping field required" = prompt cannot override structural pressure.
"unclear" enum value — ambiguous cases → lets model express uncertainty within the schema.
"other" + freeform detail string — categories outside the enum → captures reality instead of forcing wrong-bucket.
Format normalisation rules — schemas validate types; prompts specify formats (ISO-8601 dates, currency format, etc.)
Output errors — things the model got wrong that it could get right
- Format mismatches (date format wrong)
- Structural output errors (object vs array)
- Misplaced values (value in wrong field)
The mechanism: send back original document + failed extraction + specific validation error message. Model uses error to self-correct. Dramatically more effective than naive retry.
detected_pattern field turns a black-box bot into a measurable system — analyse dismissal patterns, improve based on evidence.
Source gaps — information absent from the document
- 15% of documents lack a field → retry produces fabrications, not corrections
- The correct fix: nullable field in schema
- "Increase retry limit from 3 to 10" → more fabrications, not more accuracy
Self-correction patterns: extract calculated_total AND stated_total — disagreement flags OCR errors, fraud, or model arithmetic mistakes. Add conflict_detected boolean for internally inconsistent source data.
Blocking → synchronous. Latency-tolerant → batch. Never "everything to batch."
- 50% cost savings vs synchronous
- Up to 24-hour processing window — no faster, no slower-bounded
- No guaranteed latency SLA — could return in 10 min or 23 hours
- Does NOT support multi-turn tool calling — single-shot completions only. Agentic loops must be synchronous.
- Uses custom_id — correlating request/response pairs. Resubmit failures by custom_id, not the whole batch.
Blocking vs latency-tolerant
Blocking (→ synchronous): pre-merge CI checks, IDE inline suggestions, customer-facing chat
Latency-tolerant (→ batch): overnight test generation, weekly compliance audits, monthly competitive intelligence
Manager proposes "switch everything to batch": always the mixed strategy. Batch the latency-tolerant, keep blocking synchronous.
Iterate on prompts synchronously before batching. Don't iterate inside a 24h loop.
Context Management & Reliability
Smallest domain by weight — but cascades into every other domain. Summarisation traps, escalation logic, error propagation, codebase exploration, provenance. These patterns appear everywhere.
Summarisation compresses high-value tokens first
- Numbers: "$247.83 refund" → "a refund"
- Dates: "March 3rd" → "recently"
- IDs: "#8891" → omitted entirely
- Expectations: "by Friday" → vanished
Lost-in-the-middle: transformer attention biased toward beginning and end. Not fixable with a better model — structural. Put key findings summaries at the beginning, use explicit section headers.
Extract transactional facts, inject verbatim forever
- Structured block with Customer ID, Order #, amounts, dates, expectations
- Injected verbatim into every prompt — summarisation never touches it
- Conversation history above and below can compress; the facts block is sacred
- Trim tool results before they hit context — 40 fields when you need 5 = 35 fields of noise per turn, accumulating
Upstream fix: modify subagents to return structured key facts and citations — not verbose prose, not reasoning chains. Cheapest place to fix downstream context bloat is upstream.
Explicit "I want a human" = escalate now, do not investigate first
Multiple customers match search? Ask for an additional identifier. Never pick by heuristic (most recent, most active, geographical proximity).
- Valid: Customer explicitly requests a human — escalate immediately, no investigation. Not "confirm they really want a human" — explicit means explicit.
- Valid: Policy exception or gap — request outside documented policy. Agent cannot invent policy.
- Valid: Inability to make meaningful progress — after legitimate avenues tried.
- Unreliable: Sentiment (customer is frustrated) — frustration does not correlate with case complexity. Acknowledge frustration, offer resolution, escalate only if reiterated.
- Unreliable: Self-reported model confidence — model is often incorrectly confident on hard cases and uncertain on easy ones. Escalate on calibrated thresholds only.
Both destroy recovery
- Silent suppression — return {"results":[],"status":"ok"} on tool failure. Orchestrator believes no data exists. Zero recovery path. The worst answer in any 5.3 question.
- Workflow termination — kill entire pipeline on single tool failure. Throws away partial results from subagents that succeeded.
- Access failure ≠ valid empty result. Retry only the former. Conflating them causes either endless retry or accepting false "no data" as truth.
Give the model enough context to recover
- Failure type — transient / validation / business / permission
- What was attempted — specific query, parameters, endpoint
- Partial results — anything gathered before the failure
- Potential alternatives — retry, fallback path, narrower query, cached endpoint
Coverage annotations: "Section on geothermal limited due to unavailable journal access (3 of 7 sources unreachable)." Better than silently omitting. Consumer can decide whether to act or wait.
When model says "typical patterns" instead of specific findings — degrade has begun
- Scratchpad files — write key findings to file, reference for subsequent questions. Survives compaction and crashes.
- Subagent delegation — coordinator receives distilled result only. Parallel deep dives without bloating coordinator context.
- Summary injection — summarise findings from one phase before spawning next-phase subagents.
- /compact — recovery valve when verbose output fills the window. Trade-off: loses fidelity.
- Manifest pattern — export structured state to known file location at checkpoints. On resume: load manifest, inject into prompts. Source of truth, not conversation history.
Provenance (TS 5.6)
Every finding carries: claim + URL + doc name + excerpt + publication date. Attribution dies the moment any agent summarises without structure.
Two credible sources report different numbers? Annotate both with full attribution. Let the consumer decide. Never average (fabricates a number neither source reported). Never silently pick one.
28% (2022) vs 32% (2024): not a conflict — a trend. Include publication dates to distinguish.
Match rendering to content: tables for financial data, prose for narrative, structured lists for technical findings.
The agent that produced the output should not review that output. Use an independent instance.
These appear in every domain as plausible-looking wrong answers
The exam is testing whether you can distinguish the right mechanism from a superficially similar one.
- "Add a stronger system prompt instruction" — probabilistic. Doesn't enforce. Use hooks (high-stakes) or tool_choice (mandatory first step).
- "Use a larger model" / "increase temperature" — almost never the right answer. Address the structural problem, not the model size.
- "Retry on every error type" — blanket retry is always wrong. Classify first: transient / permanent / logical / business.
- "Return empty results with status=ok on failure" — silent suppression. The worst pattern in the exam. Zero recovery path.
- "Reuse the code-generating session for review" — motivated reasoning. Use a fresh independent session.
- "Use a larger context window to prevent attention dilution" — attention dilution is structural, not a token-count problem.
The morning of the exam — review these five things
Now rehearse it.
3 full-length mock exams in real exam mode · study notes for all 5 domains · 100 flashcards
Hamza Farooq · hamza@traversaal.ai · boringbot.substack.com
Independent study material · not affiliated with or endorsed by Anthropic