Overview

All readers — reverse-engineer Claude Code as a reference agent harness; extract design principles that transfer to your own agent.

Why dedicate a chapter to Claude Code

Harness Engineering covers “how to build an agent harness” and Context Engineering covers “how to manage context.” Both are product-neutral theory.

This chapter is different — this chapter covers one product: Claude Code.

Why a product-specific chapter is worth it: Claude Code is the agent harness Anthropic builds for itself and uses internally. Every decision in its design embodies Anthropic’s answers to the harness and context engineering questions they write papers about. Studying it gives you two things at once:

  1. A production-grade engineering reference — CLI + Desktop + Web + IDE plugins, with millions of hours of real usage
  2. Observable evidence of what Anthropic actually believes about progressive disclosure, context rot, and the attention budget — not just what they publish in papers

So this chapter isn’t a product manual. It’s a case study. We reverse-engineer, then redirect the findings into design principles you can apply to your own agent.


What makes Claude Code distinctive

Compared to agent products that stop at the surface layer (Cursor / Windsurf / Devin / Aider), Claude Code makes several decisions that others don’t make — or make in a much shallower form:

DecisionWhat Claude Code doesWhy it’s worth studying
Layered system promptStatic skeleton + project-level CLAUDE.md + user-level ~/.claude/ + auto memory + session-level guidance, all injected in separate layersTurns “prompt cache hit rate” and “personalization” into primary design constraints, not afterthoughts
Context compactionAuto-triggered compaction that preserves semantic scaffolding and discards re-derivable contentMakes “which tokens have long-term value” an explicit strategy
Memory systemThree tiers (project / user / auto memory) + MEMORY.md always-loaded index + individual files loaded on demandA textbook application of progressive disclosure
Sandbox and permissionsPermission modes as a per-turn user-visible state machine, hooks as event-level interceptionTrust boundaries become a product surface, not a hidden config
Subagents (Agent tool)Main agent delegates sub-tasks via the Agent tool; sub-agent context is fully isolatedContext firewall — the value of multi-agent isn’t parallelism, it’s isolation
Hookspre/post tool, stop, prompt-submit event hooks guaranteed by the harnessSeparates “prompt-level” from “process-level” requirements; admits that prompts can’t do everything

Each row unpacks into its own chapter below.


8 Chapters · 3 Axes Static composition → dynamic runtime → security boundaries. Each axis independent, cross-referenced throughout. 1 · Overview where to start AXIS 1 · Static Composition How the agent's input is assembled — prompt, memory, compaction. The parts that don't move per turn. 2 · System Prompt 7 static + 13 dynamic sections 3 · Compaction 5-tier pipeline 4 · Memory 6 file types × 4 content types AXIS 2 · Dynamic Runtime What actually happens per turn — the loop, the streaming, the tool dispatch. 5 · Agent Loop 14-step pipeline · 6 terminal reasons AXIS 3 · Security Boundaries Trust decisions + physical isolation. Two orthogonal layers, both required. 6 · Permissions 7 modes × 8 sources × 10 hooks 7 · Execution Environment 3 isolation modes + process sandbox 8 · Design Lessons 10 principles, source-grounded Read top-to-bottom for narrative, or pick an axis for deep-dive. Chapter 8 redirects principles back to practice. All claims bound to Claude Code source paths.

Reading order

#TopicWhat you’ll be able to answer
1This page (Overview)Why study Claude Code, what to read
2System Prompt AssemblyHow static skeleton + CLAUDE.md + session guidance get assembled; why it’s layered that way
3CompactionWhen compaction fires, what gets kept, how cross-session handoff works
4Memory System6 memory types, MEMORY.md index design, subagents as context firewalls
5Agent Execution LoopWhat a single turn actually runs: query async generator, 14-step pipeline, streaming tool executor, full-chain abort
6PermissionsThe trust decision layer: 7 modes × 8 sources × 11 reasons × 10 hook events
7Execution Environment3 isolation modes (none / worktree / remote), cross-platform process sandbox, CCR cloud architecture
8Design LessonsCross-cutting principles extracted (abstract)
9Applying to Your Agent (AI SDK)Principles landed in AI SDK’s 8 embedding points, 3 traps, MVP blueprint (executable, cut by hook)
10Lifecycle State FlowHow state flows across the 8 points in one conversation · 4 state buckets · R/W matrix (cut by state)

The first seven chapters describe what Claude Code does. Chapter 8 extracts abstract principles; chapter 9 lands them in specific AI SDK code (hook-cut); chapter 10 traces state flow across the 8 points (state-cut) — 9 and 10 are complementary views of the same code.

Chapter organization: 2-4 cover static composition (prompt, compaction, memory); 5 covers dynamic runtime (the turn loop); 6-7 cover security boundaries (trust + physical isolation); 8-10 are the theory → applied triplet — chapter 8 states abstract principles, chapter 9 is the hook-cut code map, chapter 10 is the state-flow dynamic walkthrough.


What this chapter is not

  • Not a user manual. For installing, configuring MCP, or writing slash commands, the official docs are thorough: docs.claude.com/claude-code.
  • Not guesswork about internals. This chapter discusses only observable behavior — what the system prompt looks like, what tool error strings say, how UI responds to permission-mode switches, the order in which CLAUDE.md files are loaded. Specific algorithms (compaction trigger thresholds, memory ranking) are not asserted unless Anthropic has published them.
  • Not a feature matrix vs Cursor / Devin. Comparison tables tend to read like marketing copy. We’ll cite occasional contrasts to explain “what Claude Code decided that others didn’t,” but we don’t build a full matrix.
  • Not an official Anthropic position. This is a third-party synthesis. Some design lessons are inferences from observable behavior, not quotes from Anthropic docs.

Methodology: observable vs inferred

Two kinds of claims are strictly separated in this chapter:

  • Observable: things any Claude Code instance can see — text in the system prompt, tool schemas, CLAUDE.md loading behavior, wording of error messages, UI behavior on permission-mode switch
  • Publicly documented: docs.claude.com, Anthropic blog posts, the official changelog
  • Inferred: design intent inferred from the above two — explicitly labeled “inferred” or “likely

Anything not labeled as inferred is supported by observation or public documentation.


Who should read this

  • Builders actively designing an agent product who want to know which decisions in a mature harness are worth copying
  • Claude Code users who want to understand why it’s designed the way it is, not just how to use it
  • Anyone doing context engineering who wants to see whether the principles in Context Engineering have a full engineering instance somewhere

Not a good fit: readers new to AI who haven’t started building agents yet. Start with Agent = Model + Harness instead.


Further reading

Was this page helpful?