Claude Code: Building Production Agents That Actually Scale
How to use this course
Prerequisites
Evidence standard
Video availability
Module 1 outcome
Module 1: Foundations of a production agent
Module map
CC-001: The Agent Loop, Explained and Enforced
Learning objectives
Start with the loop, not the chat transcript
Validation is a stack of different questions
How Claude Code enforces the pre-action boundary
A worked validator for a dependency-update agent
Worked example: Evaluate one proposed Edit
Postcondition checks prove what actually happened
Stopping is part of the design
Practical lab
Design the boundary for one side effect
CC-001 knowledge check
Review notes
Key takeaway
Sources and further reading
CC-002: What a Governed Claude Code Run Looks Like
Learning objectives
First, separate the terms that teams often blur
A governed run has an execution contract
Choose the operating surface deliberately
Worked example: Evolve one dependency workflow without jumping surfaces too early
Concrete example: a reproducible headless review
Worked example: What the wrapper must decide
Concrete example: the Agent SDK as a controlled host
The run record is the operational product
Follow one governed run from acceptance to evidence
Failure is a designed state, not an exception to governance
Practical lab
Specify one governed run end to end
CC-002 knowledge check
Review notes
Key takeaway
Sources and further reading
CC-003: Choosing the Right Model Through Workload Classes
Learning objectives
There is no universal list of classes - so define yours explicitly
A practical four-class starting taxonomy
Every class needs seven contract fields
Classify on consequence and evidence, not prompt difficulty
Worked example: Classify three operations in one service assistant
Choose a model path only after the class is known
Fallback is a fresh policy decision
Practical lab
Define four routing contracts for one product
CC-003 knowledge check
Review notes
Key takeaway
Sources and further reading
CC-004: Context Is a Budget, Not Memory
Learning objectives
Context engineering is an evidence pipeline
The context window is working memory, not a database
Allocate the budget before retrieval fills it
Worked example: Budget a dependency-update run
Authority, relevance, freshness and specificity resolve conflict
Compression must preserve decisions, uncertainty and provenance
Implement the context pipeline in Claude Code
Worked example: What the assembler does before Claude sees a token
Test and observe the context pipeline as a production component
Worked example: Diagnose a context failure instead of blaming the model
Practical lab
Engineer a context pipeline for one risky decision
CC-004 knowledge check
Review notes
Key takeaway
Sources and further reading
CC-005: The Production Agent Definition
Learning objectives
A demo proves capability; production proves controlled operation
The five properties are system properties
Bounded means the blast radius is enforced before action
Worked example: Bound a dependency-update agent
Observable means reconstructable, not merely verbose
Reversible requires stop, restore and compensate
Evaluable means release thresholds cover outcomes and process
Worked example: Create a release gate that a demo cannot game
Governable means someone can authorize, change and stop the system
Turn the scorecard into a release decision
Worked example: Score the dependency-update candidate
Ship through staged exposure and operate the learning loop
Practical lab
Run an evidence-based production readiness review
CC-005 knowledge check
Review notes
Key takeaway
Sources and further reading
Module 1 Capstone - Production Agent Design Brief
Scenario
Assignment
Acceptance criteria
Rubric
Submission package
Module 1 graded assessment
Module 1 graded assessment
3 attempts allowed
Assessment review guide
Module 1 resources
Module 1 Learner Workbook
Agent Loop Canvas
Operating Surface Decision Matrix
Model Routing Policy
Context Budget Worksheet
Production Readiness Scorecard
Capstone Design Brief
Module 1 Learner README
Capstone Rubric
Capstone solution guidance
Module 1 capstone solution guidance
Loop evidence
Operating-surface reasoning
Routing evidence
Context evidence
Readiness evidence
Common weak answers
Final self-review
Module 2 overview: The primitive stack
Outcomes
Lesson path
CC-006: Tools as governed API contracts
Learning objectives
Mechanism
Implementation and configuration
Worked example: repository issue triage tool
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-006 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-007: Subagents and controlled delegation
Learning objectives
Mechanism
Implementation and configuration
Worked example: parallel repository review
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-007 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-008: Hooks as deterministic control points
Learning objectives
Mechanism
Implementation and configuration
Worked example: command policy hook
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-008 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-009: Skills as reusable operational knowledge
Learning objectives
Mechanism
Implementation and configuration
Worked example: incident triage skill
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-009 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-010: MCP as the integration plane
Learning objectives
Mechanism
Implementation and configuration
Worked example: read-only work tracking server
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-010 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-011: Plugins and trusted distribution
Learning objectives
Mechanism
Implementation and configuration
Worked example: engineering review plugin
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-011 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-012: Assembling the primitive stack
Learning objectives
Mechanism
Implementation and configuration
Worked example: dependency review agent
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-012 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
Module 2 capstone: Governed dependency review stack
Scenario
Assignment
Acceptance criteria
Rubric
Submission package
Module 2 graded assessment
Module 2 graded assessment
3 attempts allowed
Assessment review guide
Module 2 resources
Tool contract worksheet
Delegation contract
Hook test matrix
Skill authoring checklist
MCP threat model
Plugin release checklist
Primitive stack canvas
Module 2 capstone template
Module 2 capstone rubric
Module 2 capstone solution guidance
Strong control path
Expected boundaries
Weak answers
Final review
Module 3 overview: Owning the runtime
Outcomes
Lesson path
CC-013: Choosing between CLI and Agent SDK
Learning objectives
Mechanism
Implementation and configuration
Worked example: durable review queue
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-013 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-014: Building a minimal SDK agent
Learning objectives
Mechanism
Implementation and configuration
Worked example: repository evidence service
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-014 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-015: Tools, hooks and subagents in the SDK
Learning objectives
Mechanism
Implementation and configuration
Worked example: governed change reviewer
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-015 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
CC-016: Sessions, state and durability
Learning objectives
Mechanism
Implementation and configuration
Worked example: review that survives worker failure
Reading the evidence
Release reasoning
Failure modes
Practical lab
Evidence criteria
CC-016 formative exercise
Review notes
Key takeaway
Sources and further reading
Next step
Module 3 capstone: Durable review service
Scenario
Assignment
Acceptance criteria
Rubric
Submission package
Module 3 graded assessment
Module 3 graded assessment
3 attempts allowed
Assessment review guide
Module 3 resources
SDK decision record
SDK runtime contract
Message handling matrix
Custom tool schema review
SDK hook test matrix
Subagent isolation plan
Session state schema
Recovery drill
Module 3 capstone template
Module 3 capstone rubric
Module 3 capstone solution guidance
Strong architecture decision
Expected runtime design
Expected recovery design
Weak answers
Final review
Module 4: Secure and govern the agent boundary
Module outcomes
Completion route
Evidence standard
Time plan
CC-017: Enforce permissions as runtime policy
Learning objectives
Why this lesson matters
Mechanism
1. Global interaction mode and per-tool policy are separate controls
2. Default deny starts with no capabilities and adds only proved requirements
3. Path, command, method, endpoint, time and budget limits belong at execution boundaries
4. Denied actions are useful evidence when they are structured and observable
Implementation
Worked example: A release agent needs to read source, write a patch, run a fixed test command and create a draft change request
Failure modes
Operating review
Practical lab
Build and test your permissions boundary
CC-017 formative exercise
Evidence criteria
Sources and further reading
Bridge
CC-018: Contain agents with measurable sandboxes
Learning objectives
Why this lesson matters
Mechanism
1. Read, write, execute and transmit are the four blast-radius dimensions
2. Application policy, operating-system controls and infrastructure isolation must agree
3. Read-only access can still create severe disclosure risk through logs or egress
4. A sandbox is credible only after realistic escape and recovery tests
Implementation
Worked example: A document-review agent receives untrusted archives
Failure modes
Operating review
Practical lab
Build and test your sandbox boundary
CC-018 formative exercise
Evidence criteria
Sources and further reading
Bridge
CC-019: Control egress, secrets and data movement
Learning objectives
Why this lesson matters
Mechanism
1. Egress is an authorization decision, not a networking convenience
2. Credentials should be injected at the narrowest component that needs them
3. Classification must drive context, output, logging, retention and deletion rules
4. Seeded canaries make accidental disclosure detectable during tests
Implementation
Worked example: A case-triage agent calls an internal records API and a specialist reference service
Failure modes
Operating review
Practical lab
Build and test your data boundary
CC-019 formative exercise
Evidence criteria
Sources and further reading
Bridge
CC-020: Operate policy, audit and lineage as code
Learning objectives
Why this lesson matters
Mechanism
1. Policy must be versioned, reviewed, validated and pushed by deployment
2. Effective policy includes base rules plus environment and workload overlays
3. Audit records capture proposed, authorized, denied and completed actions without secret values
4. Lineage joins request, context, model, policy, tool calls, approvals and output
Implementation
Worked example: A release investigation asks why a repository write occurred
Failure modes
Operating review
Practical lab
Build and test your governance record
CC-020 formative exercise
Evidence criteria
Sources and further reading
Bridge
CC-021: Govern plugins, skills and MCP dependencies
Learning objectives
Why this lesson matters
Mechanism
1. An extension inherits the useful access of the process that hosts it
2. A friendly name and active maintainer do not establish provenance
3. Versions and transitive dependencies must be pinned by digest
4. Admission is temporary and needs expiry, monitoring and a tested revoke path
Implementation
Worked example: A team proposes an MCP server for issue search
Failure modes
Operating review
Practical lab
Build and test your supply-chain gate
CC-021 formative exercise
Evidence criteria
Sources and further reading
Bridge
Module 4 capstone: Boundary assurance packet
Scenario
Brief
Required submission
Execution requirements
Scoring rubric
Submission checklist
Module 4 graded assessment
Module 4 graded assessment
3 attempts allowed
Assessment review guide
Module 4 resources
Downloads
Visuals
Use and retention
Module 4 solution guidance
Strong submission pattern
Common weak answers
Review sequence
Model decision
Self-scoring
Module 5: Evaluate agent behavior before and after release
Module outcomes
Completion route
Evidence standard
Time plan
CC-022: Build an eval-first release system
Learning objectives
Why this lesson matters
Mechanism
1. Outcome, process and cost measures answer different release questions
2. Tasks, trials and transcripts are distinct units and must not be conflated
3. Fast pull-request gates and broader scheduled suites serve different feedback loops
4. Threshold breaches need precommitted alert, rollback or stop responses
Implementation
Worked example: A change-review agent appears accurate but doubles tool calls and sometimes reads unrelated files
Failure modes
Operating review
Practical lab
Build and test your evaluation contract
CC-022 formative exercise
Evidence criteria
Sources and further reading
Bridge
CC-023: Design trajectory evals and golden datasets
Learning objectives
Why this lesson matters
Mechanism
1. A golden case includes input, acceptable path constraints, result and expert rationale
2. The agent under test must not access labels before its run completes
3. Model, effort, tools, time, data and randomness must be pinned or recorded
4. Small sets need stratification, repeated trials and uncertainty-aware reporting
Implementation
Worked example: A code-review agent finds a real defect after reading an unrelated secret file
Failure modes
Operating review
Practical lab
Build and test your trajectory harness
CC-023 formative exercise
Evidence criteria
Sources and further reading
Bridge
CC-024: Calibrate LLM judges for production gates
Learning objectives
Why this lesson matters
Mechanism
1. A judge has no privileged ground truth and must be treated as a fallible evaluator
2. Specific criteria, anchored contrasts and evidence requirements improve discrimination
3. Agreement corrected for chance matters more than raw agreement alone
4. High-impact disagreement routes to humans and can never be averaged away
Implementation
Worked example: Three domain reviewers label fifty release summaries
Failure modes
Operating review
Practical lab
Build and test your judge gate
CC-024 formative exercise
Evidence criteria
Sources and further reading
Bridge
Module 5 capstone: Evaluation release gate
Scenario
Brief
Required submission
Execution requirements
Scoring rubric
Submission checklist
Module 5 graded assessment
Module 5 graded assessment
3 attempts allowed
Assessment review guide
Module 5 resources
Downloads
Visuals
Use and retention
Module 5 solution guidance
Strong submission pattern
Common weak answers
Review sequence
Model decision
Self-scoring
Module 6: Operate What You Ship: Observability, Reliability and Cost
Outcomes
Lesson map
Completion standard
CC-025: Instrumenting the Agent Timeline
Learning objectives
Mechanism: turn execution into correlated evidence
Implementation sequence
What to instrument
Build the trace hierarchy
Assign each observability layer one job
Instrument a tool boundary
Separate experiments from production monitoring
Add an agent-aware debugging view
Operate through a production monitoring backend
Design dashboards around operator questions
Connect service indicators to automatic responses
Page only for an actionable condition
Worked example: instrument a screening workflow
Worked example: reconstruct a failed maintenance run
Failure modes to test before release
Practical lab
Build and test an agent trace contract
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
CC-026: Reliability Engineering for Agent Failure Modes
Learning objectives
Mechanism: convert failure taxonomy into controls
Implementation sequence
The failure taxonomy
Detecting failure modes
Define service objectives around accepted outcomes
Spend an error budget deliberately
Roll back the smallest changed layer
Adapt conventional reliability practice to probabilistic behavior
Contain failures with circuit breakers and fallbacks
Run an agent incident response
Worked example: detect sycophantic screening
Defend the handoff boundary
Bound permission fan-out
Reliability review
Worked example: contain tool flailing without losing the case
Failure modes to test before release
Practical lab
Run an agent reliability game day
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
CC-027: Cost Engineering Beyond Token Spend
Learning objectives
Mechanism: optimise the accepted outcome, not the API invoice
Implementation sequence
Measure four cost types
Control token and reasoning spend
Price wall-clock delay
Measure reviewer effort
Measure re-engagement cost
Include infrastructure cost
Build the accepted-outcome cost model
Monitor cost without rewarding bad outcomes
Find the cost-quality frontier
Worked example: cost a screening workload
Cost review
Measurement notes
Failure modes to test before release
Practical lab
Build a four-cost baseline
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
Module 6 Capstone: Operate What You Ship: Observability, Reliability and Cost
Scenario
Assignment
Acceptance criteria
Rubric
Module 6 graded assessment
Module 6 graded assessment
3 attempts allowed
Review guidance
Module 6 resources
Download index
Visuals
Module 6 solution guidance
Reviewer prompts
Minimum viable solution
Common weak submissions
Module 7: Scale to a Team-Owned Agent Platform
Outcomes
Lesson map
Completion standard
CC-028: From Paired Experiments to a Team-Owned Agent Platform
Learning objectives
Mechanism: make ownership the platform boundary
Implementation sequence
Pair: prove value with one accountable builder
Pool: establish shared team operation
Platform: offer agents as a supported capability
Choose from evidence, not fleet size alone
Provision through a reviewed workload contract
Containers are cattle, not pets
Scale reasoning, execution and burst capacity separately
Many brains, many hands
Dynamic workflows and burst patterns
Make the golden path the easiest supported route
Split platform and workload ownership
Worked example: migrate from pair to pool to platform
Platform readiness review
Design notes
Failure modes to test before migration
Practical lab
Design the team-owned platform transition
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
CC-029: Reference Architectures, Shared Skills and Secure Orchestration
Learning objectives
Mechanism: distribute knowledge without distributing drift
Implementation sequence
Decompose the reference architecture
Promote one source through two deployment surfaces
Author skills once and detect drift
Centralize connector policy without centralizing credentials in agents
Treat cross-agent routing as a control-plane operation
Decide what to adopt
Choose build, configure or hybrid
Architecture review
Reference notes
Worked example: stop a poisoned handoff at the routing boundary
Failure modes to test before release
Practical lab
Package one workflow for two operating surfaces
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
Module 7 Capstone: Scale to a Team-Owned Agent Platform
Scenario
Assignment
Acceptance criteria
Rubric
Module 7 graded assessment
Module 7 graded assessment
3 attempts allowed
Review guidance
Module 7 resources
Download index
Visuals
Module 7 solution guidance
Reviewer prompts
Minimum viable solution
Common weak submissions
Module 8: Exercise Judgment: Remediate Anti-Patterns and Plan the Migration
Outcomes
Lesson map
Completion standard
CC-030: Diagnosing Anti-Patterns and Migrating Legacy Automation
Learning objectives
Mechanism: preserve deterministic strengths and isolate judgment
Implementation sequence
Diagnose a decision loop
Diagnose an inference loop
Diagnose prompt brittleness
Diagnose the tool trap
Diagnose model substitution
Diagnose context overload
Diagnose an approval bottleneck
Diagnose runaway cost
Apply the judgment test at each workflow step
Migrate one judgment seam under control
Worked example: recover from a big-bang conversion
Keep these operations deterministic
Diagnose dependency and plugin risk
Diagnosis review
Diagnostic notes
Failure modes to test before migration
Practical lab
Remediate a legacy automation slice
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
CC-031: Architecture Judgment and a No-Hype Roadmap
Learning objectives
Mechanism: turn uncertain futures into reversible bets
Implementation sequence
Separate available capability from forecast
Bound plausible but unconfirmed changes
Reject unsupported autonomy claims
Build capabilities that survive roadmap changes
Avoid irreversible bets
Review architecture readiness
Worked example: replace a platform promise with a bounded experiment
Failure modes to test before release
Practical lab
Produce an evidence-led twelve-month roadmap
Evidence criteria
Grouped formative exercise
Exercise debrief
Key takeaway
Sources and further reading
Module 8 Capstone: Exercise Judgment: Remediate Anti-Patterns and Plan the Migration
Scenario
Assignment
Acceptance criteria
Rubric
Module 8 graded assessment
Module 8 graded assessment
3 attempts allowed
Review guidance
Module 8 resources
Download index
Visuals
Module 8 solution guidance
Reviewer prompts
Minimum viable solution
Common weak submissions
Claude Code: Building Production Agents That Actually Scale
Engineer governed Claude Code agents that survive real production failures
The instructor has published 85% of this course.Last updated on 2026-09-01
Move beyond the demo and build a Claude Code agent your team can operate. You will implement tool boundaries, evaluation gates and recovery paths, then assemble the evidence for a production-readiness review.
Minimum price
$79.00
$149
You pay
Author earns
PDF
EPUB
WEB
100,926Words
About
About the Course
A Claude Code session can look successful while hiding the failures that matter in production. A tool can time out after completing a side effect. A passing test can cover the wrong behaviour. An approval can outlive the action it was meant to allow.This practical course, based on Thomas De Vos's bestselling book, shows you how to engineer agents that a team can operate and defend. You will work with the agent loop, operating surfaces, model routing, context and memory, tools, MCP, permissions, hooks, observability, evaluation, cost controls and recovery.Each lesson combines a focused video with detailed written instruction, a worked production failure, practical lab work and an assessment. You will implement controls, test failure paths and record evidence rather than simply watch someone build a demo.Across eight modules, you will build a governed agent system and a production-readiness dossier. The finished dossier covers your agent loop, routing policy, context controls, permission boundaries, evaluation cases, observability plan, recovery procedure and release evidence.This course is for software engineers, technical leads, platform engineers, solution architects and security engineers. You should be comfortable with a terminal, Git, configuration files, tests and ordinary software-delivery workflows. Prior experience with the Claude Agent SDK is not required.
Instructor
About the Instructor
Material
Course Material
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earned over $15 million writing, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
Write and Publish on Leanpub
You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!
Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.
Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.