Why this session exists
Everything so far ran inside one Claude conversation. Real systems need more: parallel work without context collisions (subagents), connections to YOUR databases and tools (MCP), and programmatic building blocks (the API and platform). This session is the map plus the first hands-on mile; the deep-dive track below is the full engineering curriculum, one 45-minute page at a time.
The platform map: from chat to production 7 min live
One mental model explains every Claude product: an agent loop with tools, bounded by a context window. Chat hides it, Claude Code exposes it, the API hands you the parts.
LivePlatform 101 in one card4 min▶
- Your first API call is ~10 lines (Demo 3). Everything else - models, tools, thinking - is parameters on that call.
- Choosing models: the capable one for hard reasoning, the fast one for volume; price and latency scale accordingly. Rule: prototype on the best, optimize down once quality is proven.
- Tool use = you describe functions, Claude decides when to call them, you execute and return results - the agent loop with YOUR tools. (Deep dive 6.3)
- Extended thinking: a budget for the model to reason before answering - buy accuracy on hard problems with tokens. (6.5)
- Built-in tools, skills, MCP: web search, code execution and files come managed; your Session 3 skills and MCP servers plug into the same loop.
- Context management: the window is finite; production systems curate what's in it every turn - that discipline is half of platform engineering. (6.1, 6.5)
- Managed agents: the newest layer - define an agent (instructions + tools) and run it as a service without owning the loop yourself.
For the executives in the room: this is the layer where "Maria's clever workflow" becomes "a company capability". The chief-of-staff briefing from Session 2, rebuilt on the platform, stops depending on Maria's laptop - it becomes a governed service with logs, access control, and an owner. That's the strategic point of everything on this page.
Subagents: delegation with clean context 5 min live
Session 1's working-memory lesson, weaponized: long sessions drift because everything shares one context window. Subagents give each task its OWN window - they work in isolation and return only the summary.
LiveWhat they are, when to use them, how to build one5 min▶
- What: a named assistant with its own system prompt, tool permissions, and context window. Your main session delegates ("review this diff"), the subagent works separately, only its conclusion returns - your context stays clean.
- Create: the
/agentscommand in Claude Code scaffolds one interactively; it lives as a markdown file in.claude/agents/- committed to the repo, shared like a skill. - Design rules: one job per agent (a reviewer that also fixes is neither) · write the description like a skill trigger (when to invoke it) · give it the MINIMUM tools (a read-only reviewer cannot delete data - that's governance by construction) · tell it what to return (a verdict format, not a transcript).
- Use well: delegate self-contained work with a summarizable result: reviews, research sweeps, test triage, doc generation. Don't delegate work needing YOUR conversation's context - it doesn't have it.
- Pitfall #1: vague agents ("helper") that do everything badly. Pitfall #2: forgetting the subagent can't see your chat - brief it like an email to a colleague, complete and standalone.
MCP: the port that connects Claude to everything 5 min live
Model Context Protocol is the open standard behind every connector you've used since Session 2. One protocol, three primitives - learn it once, plug in anything.
LiveThe three primitives + why this matters to us5 min▶
- Tools - actions the server exposes ("query_warehouse", "create_ticket"). Claude calls them in the agent loop.
- Resources - data the server offers (a schema, a config, a report) that the client can load into context.
- Prompts - reusable prompt templates the server ships ("analyze this table properly").
- Client/server: Claude (Code, app, or your API program) is the client; the server wraps your system. Anthropic and vendors ship servers for hundreds of tools; a custom one for YOUR internal API is an afternoon of Python (deep dive 6.6).
- The connective insight: the Gmail connector (Session 2), Claude Code's tool integrations (Session 5), and your future warehouse hookup are ALL this one protocol. Approve once, reuse everywhere - which is also why sys-admin governance lives at the MCP layer.
The first MCP server most data teams add: their warehouse (read-only credentials). From then on, "which tables feed the exec dashboard, and when did revenue_daily last refresh?" is a chat message - in Claude Code, in the app, everywhere the server is connected. Second one: the ticket system, so "file the data-quality issues you just found" closes the loop.
Build the data-QA subagent and delegate to it ★ 8 min · everyone in terminal
In the claude-data-lab repo from Session 5, run /agents → create → paste the data-qa definition (Part 2), or write your own reviewer for your stack.
Make a deliberately sloppy change to the cleaning script (add a join without dedupe). Then: "Use the data-qa agent to review my uncommitted changes."
Watch the handoff: your session stays clean while the subagent works; only the verdict returns. Check it caught the fan-out.
Note the governance angle: the reviewer has read + pytest only. It CANNOT modify anything - by construction, not by promise.
Connect an MCP server and use it ★ 7 min · everyone connects
Add a safe, useful server to Claude Code - the filesystem server on a data folder: claude mcp add datafiles -- npx -y @modelcontextprotocol/server-filesystem ~/work/claude-data-lab/data
Restart claude, then ask: "Using the datafiles server, list what's in data/processed and summarize the newest file." Watch the tool calls appear - that's MCP in the loop.
Inspect what you just trusted: claude mcp list, then review what tools the server exposes. The habit of auditing a server before granting it is THE security habit of this layer.
Map your next one: which internal system would pay off most as a server? (Warehouse read-only is the usual answer - take it to the deep dives.)
Your first API call ★ 5 min · everyone runs it
Grab the team's dev API key from the password manager (or console.anthropic.com if you're key-holder). pip install anthropic, export ANTHROPIC_API_KEY.
Run the ten-liner:
Change the model name, run again, compare. Congratulations: every parameter you'll ever tune is now visible in one file - and the whole deep-dive track builds on these ten lines.
Eight pages replacing 24 hours of lectures ◐ self-paced or optional sessions
The three 8-hour platform courses (Building with the Claude API, Claude with Amazon Bedrock, Claude with Vertex AI) share ~85% of their curriculum. The track teaches that shared core once, properly, plus the platform deltas - each page is also runnable as an optional 45-minute DS&AI session. Recommended order below; 6.1 → 6.3 → 6.7 is the minimum path to building real agents.
This week, and where the series lands ◐
- Ship one subagent your team actually needs (reviewer, researcher, test-triager) into a real repo.
- Propose your first real MCP server (warehouse read-only) to the sys admin - the Session 2 request template extends naturally.
- Start the deep-dive track: 6.1 this week; 6.3 and 6.7 unlock agent-building.
- The series close: Session 1 taught you to talk to Claude; 2-4 automated your day and your team's creative work; 5-6 gave you hands and infrastructure. What remains is what was never Claude's job: choosing what's worth building. See you in #learn-claude.
Official courses covered
From claude.com/resources/courses - this session live, plus four more via the deep-dive track:
Three questions before you go 🎯 ◐ 90 seconds
1 · A subagent's superpower is...
Session 1's working-memory lesson, weaponized: your context stays clean, the verdict comes back. And give it MINIMUM tools - governance by construction.
2 · MCP's three primitives are...
Actions the server exposes, data it offers, templates it ships. Every connector you've used since Session 2 is this one protocol.
3 · Which model do you prototype on?
Never the reverse: if the best model can't do the task, no cheaper one will - and you'll blame the wrong thing.