Phase 2: Context Engineering for Builders · 50 min · Claude Code · MCP · Python

Building a Context Architecture for Your Product

A context architecture is where the last four lessons stop being separate ideas and become one design you can point at your own product.

Hiring signal: A documented context architecture is one of this course's three highest-leverage portfolio artifacts — it's concrete evidence you can design, not just describe, the context layer of a real AI-native product.

What you will learn

Design a complete context architecture spanning rules, skills, MCP connections, and a selection strategy for a real product
Apply the rules-vs-skill test and the four failure modes as review criteria, not just recall
Identify when live, frequently-changing data has been incorrectly hardcoded into static rules content instead of an MCP connection
Produce a context architecture document as a real, reviewable portfolio artifact for your course-long product

Introduction

Building a Context Architecture for Your Product

Marcus, still building his podcast-transcript show-notes tool from earlier in this course, sits down to write its CLAUDE.md and makes three mistakes in the first draft, each one a direct violation of something covered earlier in this phase. He pastes a snapshot of "current processing queue depth: 3 jobs" into the rules file, because that's genuinely useful context — except queue depth changes every few seconds, and by the time anyone reads this session's output, it's already wrong. He writes an 800-word section explaining a rare edge case in one specific podcast host's non-standard timestamp format, and puts it in the always-loaded rules file, even though it's relevant to maybe 2% of transcripts. And when the tool retrieves a sample transcript to show the agent an example, he concatenates it directly into the same block of text as the system instructions, with nothing distinguishing "this is an example to learn from" from "this is a directive to follow."

Every one of these is a mistake this phase already named: a stale snapshot that belongs in an MCP connection instead of static rules content, a narrow, rarely-needed section that belongs in a skill instead of the always-loaded file, and a missing isolation boundary between instructions and retrieved content. This lesson is where those four separate lessons stop being things you can recite and become one integrated design you build, for real, for your own course-long product.

The four pieces, assembled

A complete context architecture for your product needs four things, each one a direct application of an earlier lesson in this phase:

A rules file containing only what nearly every session on this product actually needs — conventions, constraints, the shape of the codebase — sized against a real token budget, not accumulated indefinitely.
Skill definitions for anything narrow, domain-specific, and only occasionally relevant — the rare timestamp format, a specific integration's quirks — loaded on demand instead of every time.
MCP connections for anything that needs to reflect live, current state — queue depth, ticket status, inventory — so the agent sees reality instead of a snapshot that ages the moment it's written.
A context selection strategy — a stated policy for what gets pulled into context for a given task (which documents, which prior decisions, which examples), so "what context does this session get" is a design decision, not whatever happened to be open.

The review question for your own architecture
For each piece of context your product could plausibly need, ask: does every session need this (rules), does only some sessions need this (skill), does this go stale quickly (MCP), and is this input trusted or retrieved (isolation)? A context architecture that can answer all four questions for every piece of context it manages isn't just documented — it's actually been thought through.

The fourth piece — a context selection strategy — is the one most teams skip writing down, precisely because it feels implicit until something goes wrong. For Marcus's tool, a real selection strategy answers concrete questions: when processing a new transcript, does the agent pull in the last three transcripts from the same podcast as style examples, or none? If a transcript matches a known edge case (the rare timestamp format), does the relevant skill get triggered automatically by a detection rule, or does it require a human to notice and invoke it? When the agent needs to check job status, does it always query the MCP connection fresh, or is there a caching layer, and if so, how stale is acceptable? None of these questions have a universally correct answer — they depend on the product — but a real architecture states the answer explicitly instead of leaving it to whatever the agent happens to do by default.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Applying the failure modes as a review lens, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

MCP (Model Context Protocol)