Claude Certified Architect - Foundations – Prepare for and pass the exam!

Main ideas and lessons (Claude Certified Architect – Foundations)

Purpose of the certification

“Claude Architect Foundations” is an Anthropic certification focused on building and validating AI agent workflows for organizational use. It emphasizes understanding broad underlying concepts for:

• agentic architecture and orchestration
• tool use and MCP integration
• cloud code configuration and workflows
• prompt engineering (including structured output)
• context management and reliability

Transferability of knowledge

Even if learners don’t use Claude directly, the concepts are highly transferable to other AI-agent approaches.

Course approach and exam readiness

• The course is implementation-heavy: learn concepts, then repeatedly apply them through hands-on labs.
• Practical advice:
  • Do labs even if lectures help conceptually.
  • Don’t rely only on Anthropic’s free concept-based materials.
• Suggested study pace:
  • Beginner: ~30 hours
  • Experienced: ~12 hours (course timeframe mentioned)
  • Study plan: ~1 hour/day, and don’t cram into a single day (burnout risk)

Exam format and scoring

• Passing grade: 720
• Questions: 60
• You can get wrong: 17
• Question type: Multiple choice, but verbose wording makes parsing harder
• Duration: 2 hours (with a “seat time” estimate mentioned)
• Delivery platform: SkillJar

Prerequisites / eligibility

• Initially, the certification was only available to the Claude Partner Network (company requirements may block access).
• Workaround mentioned: use Exampro’s platform version until general availability.

How the labs are built

Multiple labs demonstrate that:

• docs and exam guides can be wrong or outdated
• the “real truth” comes from implementing and testing end-to-end

Learners repeatedly correct agent-generated code when errors appear (e.g., naming, SDK changes, requirements, wrong assumptions).

---

Methodologies / instruction-style content

A) Building and validating tool-use flows (including “stop reason”)

Goal: understand when the agent stops and why.

Core concepts demonstrated:

• stop reason = tool use
  • meaning: the agent intends to call a tool/external function
• stop reason = end turn
  • meaning: the agent has enough info and is returning the final result

Tool call workflow:

1. Parse tool-use request
2. Execute the tool in code
3. Append tool results back into conversation
4. Continue until stop reason becomes end turn

Implementation emphasis:

• Prefer reliable, machine-detected stop reasons rather than parsing natural language like “task complete”.

---

B) Agentic loops and orchestration phases (cloud code)

A three-phase loop is described:

• gather context
• take action
• verify results

Tools enable external actions at each stage, such as:

• read/search/query databases
• edit/write files
• execute commands
• run web search / code intelligence operations

Model choice behavior:

• default uses one main model for phases (examples include Sonnet/Opus/Haiku modes)
• special “opus plan” behavior mentioned:
  • opus during planning
  • sonnet during execution

---

C) Decision-making patterns: code-driven vs model-driven

Code-driven (preconfigured decision trees)

• Hardcoded routing/if-else/state-machine logic
• Example concept: classify requests (billing/technical/general) and route to specialized handlers

Model-driven

• Agent decides tool sequence at runtime based on context
• Both approaches are considered valid, though the content notes Anthropic’s preference toward model-driven.

---

D) Loop safety & anti-patterns (exam-oriented)

• Use stop reason “end turn” as the loop termination signal, not “sounds done” in text.
• Add a max iteration/step cap to prevent runaway loops.
• Don’t assume “text returned” means tools are done—check stop reason.

---

E) Hub-and-spoke architecture for coordinator agents

Pattern:

• a single coordinator (“hub”) routes tasks to sub agents (“spokes”)
• spokes do not communicate directly with each other

Coordinator controls:

• routing decisions
• context sharing boundaries
• aggregation and conflict resolution
• observability/error handling “choke point”

Task lifecycle responsibilities:

• decomposition
• delegation
• result aggregation
• routing based on complexity

---

F) Narrow vs better task decomposition

Problem:

• Overly narrow decomposition causes spokes to miss needed context because each spoke sees isolated context.

Remedy:

• ensure decomposition includes required dimensions and “gap” coverage
• sometimes prefer a more flexible shared evaluation perspective rather than independent narrow checks

---

G) Dynamic selection and partitioning (cost/token reduction)

Dynamic selection

• Coordinator decides which pipeline branches (“spokes”) to run instead of always running all of them.
• Can be implemented via:
  • conditional routing prompts
  • “audit gaps then delegate only relevant agents”

Partitioning

• Split work so multiple research agents don’t duplicate the same subtopic.
• Can validate non-overlapping partitions using structured JSON checks.

---

H) Refinement loops (improve output iteratively)

Strategy:

1. Run an initial system
2. Evaluate output coverage/quality
3. If insufficient, redelegate/fill identified gaps
4. Stop when coverage is “sufficient” or max iterations reached

Emphasis:

• refinement is expensive (evaluation cost + extra delegations)
• you need real evaluation criteria and reliable data

---

I) Observability improvements for multi-agent coordinators

Key target: ensure the coordinator logs:

• spoke inputs/outputs (or structured summaries)
• errors with types
• coverage/gap states
• final recommendation gating

Shortfalls acknowledged:

• sometimes logs were only printed to stdout
• recommended moving toward structured log files and persistent artifacts

---

J) Error handling and recovery across coordinated agents

Desired behavior:

• sub agents return structured error context (typed failures, attempts, partial results)
• coordinator aggregates and continues appropriately

Avoid:

• silent suppression of errors
• generic errors that hide which failure type occurred

---

K) Tool-use permissions and enforcement gates

Enforcing ordering:

• add prerequisite gates so synthesis cannot happen before research completes
• use “hooks” (where available):
  • execute checks before/after tool calls
  • block invalid sequences

Emphasis:

• prompt instructions alone are not reliable; use structural enforcement.

---

L) Handoff protocol for escalation to humans

Create a structured package before escalating so humans don’t need to scan raw conversation history.

Escalate when:

• customer requests it
• policy requires it
• agent cannot resolve after attempts
• ambiguity/gray areas exceed capabilities

---

M) Batch processing overview

Concept:

• submit many tasks to an async batch endpoint to reduce cost vs interactive use

Tradeoffs:

• no interactive tool-use loops per request
• results must be retrieved asynchronously via batch IDs

---

N) MCP: resources vs tools (read-only structured retrieval vs actions)

• Tools: actions (create/update/edit/delete), typically modeled as functions
• Resources: read-only structured access patterns (schema-defined data retrieval)
  • faster/less round-tripping vs tool-based fetching

---

O) Claude Code concepts (sessions, resume, fork, context management)

• Sessions:
  • “claude” creates a new session; web vs local sessions differ
• Resume:
  • continue a prior session with a session ID
• Fork sessions:
  • branch a session to explore alternatives without altering the original
• Context management:
  • compact reduces conversation context usage
  • clear resets conversation history (does not wipe all automemory/MD files)
  • context inspects token breakdown and headroom

---

P) Permission rules & modes in Claude Code

Permission levels: allow / ask / deny Evaluation precedence: deny > ask > allow

Permission modes:

• default: prompts for permissions on first use
• accept edits
• plan: analyze only
• don’t ask: auto-deny unless preapproved
• bypass permissions: skip prompts (dangerous)

Wildcards and path patterns for matching allowed/denied actions are described.

---

Speakers / sources featured (and what they contributed)

1. Andrew (primary narrator/instructor; course creator/Andrew Brown / Andrew Brown course host)

   • Explains course structure, exam details, and demonstrates labs/code patterns.

2. Anthropic

   • Source of the Claude Architect Foundations certification and concepts like MCP.

3. Exampro

   • Mentioned for practice exams and an alternative certification path while the official one is partner-network limited.

4. Hugging Face

   • Used for the QAD dataset in the “confidence calibration” lab.

5. SkillJar

   • Mentioned as the exam delivery platform.