Architect Foundations: the complete course
Six modules covering the architecture decisions the exam tests: API design, prompts in production, tool use and MCP, context budgets, evaluation and operations.
Built for architects who will be asked to defend their design choices. Every module pairs a pattern with the trade-off it costs you and the failure it prevents, and finishes with a short exercise. Includes lifetime updates when the material changes.
Course outline
25 lessons · 9h 54m · v1
01Architecture foundations with ClaudeWhat the API gives you, how to choose a model, and the shape of a production integration.4 lessons
- The Claude API in one diagramFree preview22 min
- Choosing a model deliberatelyFree preview18 min
- Caching and batching as first-class design choices20 min
- Failure modes of naive integrations24 min
02Prompt engineering for productionPrompts as versioned artefacts with tests, not strings buried in code.4 lessons
- From prompt to specification26 min
- Structured output you can trust24 min
- Few-shot examples that earn their tokens20 min
- Versioning prompts and models together18 min
03Tools, MCP and retrievalGiving Claude access to systems and knowledge without giving it a blank cheque.5 lessons
- Designing tool definitions that models use correctly28 min
- Tool orchestration and loops24 min
- Model Context Protocol: clients, servers and transports30 min
- Retrieval-augmented generation that survives real corpora32 min
- Grounding and citation strategies22 min
04Context engineeringThe context window is your scarcest resource. Treat it like a budget.3 lessons
- Budgeting the context window22 min
- Summarisation and compaction strategies24 min
- Multi-turn state without a chat log20 min
05Evaluation, safety and guardrailsHow you know the system still works, and what stops it doing harm.5 lessons
- Building an evaluation set before you need it28 min
- Regression testing non-deterministic systems24 min
- Prompt injection and data exfiltration30 min
- Guardrails, moderation and human-in-the-loop22 min
- Privacy, retention and data handling obligations20 min
06Operations, cost and scaleRunning it: observability, cost control, and a migration plan you can defend.4 lessons
- Observability for LLM systems24 min
- Cost and latency engineering26 min
- Reliability patterns and graceful degradation24 min
- Deploying on your cloud of choice22 min
What this covers
You will be able to
- Choose a model and caching strategy with a stated rationale
- Design tool schemas that models use correctly and safely
- Budget a context window and compact long sessions
- Build an evaluation set that catches regressions
Included
- 25 lessons across 6 modules
- Downloadable architecture decision records
- Prompt and tool-definition templates
- Lifetime access, including future updates
Preview: The Claude API in one diagram
The first two lessons of the course are free to read, so you can judge the material before buying.
Every Claude integration, however elaborate, reduces to one request shape. If you can describe the Messages API precisely — what goes in, what comes back, and what the stop reason means — most architecture questions become answerable.
The request
A Messages request carries a model identifier, a max_tokens ceiling, a top-level system prompt, and an array of messages alternating between user and assistant roles. The system prompt is not a message: it is a separate field that frames the whole conversation, which is why instructions placed there survive turn boundaries while instructions buried in the first user message can be diluted later.
max_tokens caps generated output. It is a ceiling, not a target, and it does not reserve billing — you pay for what is generated. Because the cap is also part of the cached prefix in some caching configurations, changing it can invalidate a cache entry.
The response
The reply is a list of content blocks (text, tool_use, and other block types) plus a stop_reason. Architect around the stop reason, never around the text: end_turn means the model finished, max_tokens means you truncated it, stop_sequence means a configured stop string matched, and tool_use means the model is waiting for you to run a tool and return a tool_result.
Token accounting appears in usage: input tokens, output tokens, and — when caching is active — cache creation and cache read counts. Those four numbers are the basis of every cost model you will build later in the course.
Why the diagram matters
- Stop reason drives control flow: loop, retry, escalate, or return.
- Content blocks drive rendering: text and tool_use need different handling.
- System prompt placement drives instruction persistence.
- Usage fields drive cost and context budgeting.
Checkpoint
Given a response with stop_reason 'tool_use', what must your application do before it can show the user anything?