Putting it together: a professional workflow

TL;DR. The twelve levers are not a menu you pick one from; a serious system stacks several at once. This chapter is the assembly: a reference architecture for an LLM application's context, an end-to-end scenario showing every lever firing on a real coding task over a week, and a decision playbook that maps a symptom (too big, too costly, forgets, repeats a mistake) to the lever and the tool that fixes it. Read it after the lever chapters; it is where they become a practice rather than a list.

Contents

• The mindset: four jobs, every turn
• A reference architecture
• Day one: standing up the context
• A single task, lever by lever
• Across sessions: memory and learning
• The decision playbook
• Strategies the pros use
• Common mistakes
• Further reading
• Takeaways

The mindset: four jobs, every turn

Strip away the tools and context engineering is four jobs you do on every call, in order. Chapter 1 named the four properties of a good context; here they are as verbs:

1. Assemble the right context for this turn: the instructions, the few documents that matter, the relevant memory, the user's message. Only what the task needs.
2. Compress the parts that are bigger than they need to be: long documents, tool output, code, the model's own verbosity.
3. Cache what is stable so you do not pay for it twice: the prefix across calls, the answer across similar questions, the KV blocks across concurrent requests.
4. Remember what should outlive the call: facts in a memory store, rules in an instruction file.

Every technique in this book is one of those four jobs done well. A professional does not think "which of my twelve tools do I reach for"; they think "this turn, what do I assemble, what do I compress, what is already cached, and what should I remember," and the tools fall out of the answer.

Remember. The context is rebuilt from scratch on every single call. There is no persistent session inside the model. Everything good or bad about your context is a choice your code remakes every turn, so the win compounds: a lever that saves tokens on one turn saves them on all the turns that re-send that content.

A reference architecture

Most production LLM applications, once they grow past a single call, converge on the same shape. It is worth drawing because it tells you where each lever lives.

                         user message
                              |
                              v
   +--------------------------------------------------------------+
   |  ORCHESTRATOR  (ch 13)  decide what this turn needs          |
   |    - classify the request, route to the right sources        |
   |    - spawn subagents for verbose sub-jobs (keep output out)   |
   +----+--------------------+----------------+-------------------+-+
        |                    |                |                   |
        v                    v                v                   v
   RETRIEVAL            MEMORY (ch 9,10)   TOOLS / CODE        the PROMPT
   (docs, RAG)          facts, history     (ch 5: read         (instructions,
        |               that persist        only what's        the question)
        v                    |               needed)               |
   COMPRESS (ch 3,4,5)       |                   |                  |
   shrink docs/output        v                   v                  v
        +-------------------> ASSEMBLE the context under a budget <-+
                                        |
                                        v
                        CACHE (ch 6,7,8): stable prefix cached,
                        similar answers cached, KV blocks shared
                                        |
                                        v
                             MODEL CALL (ch 14: a long-context,
                             efficient-attention model)
                                        |
                                        v
                        response  +  write back to MEMORY,
                                     learn rules (ch 12)

Read it top to bottom and the families line up: orchestration at the top deciding, compression and retrieval feeding in, assembly in the middle, caching wrapping the call, the efficient model underneath, and memory closing the loop back to the next turn. You do not need every box on day one. You add a box when its symptom appears, which is what the playbook below is for.

Day one: standing up the context

Concrete now. You are putting a coding agent (Claude Code) to work on a large repository for a week. Before any task, you spend ten minutes on setup that pays off on every turn after.

# 1. Procedural memory + a stable, cacheable prefix (ch 6, ch 12).
claude
> /init                      # writes a first CLAUDE.md by reading the repo
#   then trim it by hand to the essentials: build/test commands, conventions,
#   the rules the team keeps relearning. Keep it small; it is re-sent every turn.

# 2. Tool-output compression, automatic (ch 3).
rtk init -g                  # shell hook: git, find, test, etc. auto-compress
#   now every noisy command the agent runs is smaller before it costs context.

# 3. A leaner context layer over MCP (ch 3, ch 5).
claude mcp add lean-ctx -- lean-ctx serve

# 4. Cross-session memory over MCP (ch 9).
claude mcp add memory -- npx -y @mem0/mcp

Four commands, four of the four jobs seeded: a small stable CLAUDE.md (cached prefix plus procedural memory), RTK (compress tool output), lean-ctx (compress reads), and a memory server (remember across sessions). Prompt caching you do not configure: Claude Code caches the stable system prompt and CLAUDE.md automatically, and you confirm it with /cost (Chapter 6).

Remember. The single highest-leverage setup step is a small, stable CLAUDE.md. Small, because it is a token baseline you pay on every turn. Stable, because any edit invalidates the prefix cache and forces a full-price rewrite that turn. Get it right early and leave it alone during a session.

A single task, lever by lever

Now one real task: "the deploy job is flaky, find and fix it." Watch the four jobs fire.

• Assemble + code-aware compression (ch 5). Claude Code does not read the repo into the prompt. It greps for deploy, reads only that function and the two it calls, and stops. /context shows a few thousand tokens loaded, not the whole tree.
• Orchestration (ch 13). Running the full test suite would dump a 3,000-token log into the window. Instead the agent delegates that to a subagent (the Task tool); the subagent reads the log in its own context and returns one line: "test_retry fails, timeout too tight." The main window stays small.
• Tool-output compression (ch 3). Inside that subagent, the pytest and git log output is already shrunk by the RTK hook before the subagent even summarizes it. Two compression levers stack: RTK shrinks each command, delegation keeps it out of the main window.
• Caching (ch 6). Every turn of this task re-sends the same CLAUDE.md and tool definitions. They were written to the cache on turn one and read back at about a tenth of the price on every turn after, which /cost shows as cache-read tokens.
• Output reduction (ch 4). Your CLAUDE.md has a terse-output rule, so the agent confirms the fix in one line instead of an essay. Output is billed at five times input, so this is the cheapest big win.

One task, five levers, none of them in your way. That is the point of stacking: each lever handles a different part of the context, so they compose instead of competing.

Across sessions: memory and learning

A week is many sessions, and the model forgets everything between them. Two levers carry state across the gap.

• Memory (ch 9, ch 10). In Monday's session you tell the agent the project uses asyncpg, not psycopg2. It writes that to the memory MCP server. Thursday, a fresh window, you ask it to add a query; it retrieves that one fact and writes asyncpg without being reminded. If the fact has a time dimension (a config that changed in Q2), a temporal store (Chapter 10) answers "what was true when."
• Procedural learning (ch 12). Wednesday the agent committed without being asked. You append one rule to CLAUDE.md ("never commit or push unless asked"), or run headroom learn to mine the failed sessions and write the corrections into AGENTS.md. Every session after re-injects the rule, and the mistake stops recurring.

The difference between the two is the difference between semantic and procedural memory: memory remembers facts the agent looks up; procedural learning changes how the agent behaves. A mature setup uses both, and CLAUDE.md is where the procedural half lives.

The decision playbook

When a context problem shows up in production, name the symptom, then reach for the lever and the tool. This is the same map as the landscape chapter, arranged as a troubleshooting flow.

Don't be confused. Several rows mention "caching," but they are three different caches. Prefix caching (6) reuses input tokens when the model does run. Semantic caching (7) skips the model entirely on a similar question. KV-serving caches (8) are the engine's GPU memory shared across concurrent requests. They sit at different layers and stack.

Strategies the pros use

A handful of habits separate a tuned system from a wasteful one. None of them is exotic.

• Measure before you optimize. Price the context first (Chapter 2) with count_tokens, and watch /cost and rtk gain. You cannot improve what you do not count, and the biggest line item is rarely where you guessed.
• Stabilize the prefix. Put everything that does not change (system prompt, tools, frozen docs) first and keep it byte-stable so it caches; put the volatile parts (the question, timestamps) last. A single moving byte near the front forfeits the whole cache behind it.
• Push verbose work into subagents. The cheapest token is the one that never enters the main window. Delegate test runs, log scans, and doc fetches so their output lives and dies elsewhere.
• Compress at the source, not at the end. RTK and lean-ctx shrink tool output before it is ever read; that beats compressing a window that already filled.
• Keep the instruction file small and earned. Every line of CLAUDE.md is paid every turn, so it must earn its place: a rule the agent actually needs, not a wish list.
• Let it remember and let it learn. Wire a memory store for facts and grow CLAUDE.md from real failures. An agent that re-learns the same fact and re-makes the same mistake every session is leaving the two cheapest wins on the table.

Common mistakes

The failures are as patterned as the wins. Most production waste is one of these:

• A bloated CLAUDE.md. A 5,000-token instruction file is a 5,000-token tax on every turn. Trim it to what is load-bearing.
• A moving prefix. A datetime.now() or a per-request id interpolated into the system prompt silently breaks prompt caching; cache_read_input_tokens stays at zero and you never notice.
• Dumping instead of reading. Pasting whole files or cat-ing a directory into the prompt when the task needs three functions. The window fills, or the request does not fit at all.
• Letting tool output flood the window. Running tests and log scans inline so a 3,000-token log sits in the history and is re-sent every turn after.
• Confusing the caches. Reaching for a semantic cache when the problem was a re-sent prefix, or the reverse. Name the symptom first.
• Optimizing input while ignoring output. Output costs five times as much per token; a wordy agent is often the real bill.

Further reading

• Anthropic, "Building effective agents" and the context-engineering and prompt-caching guidance on platform.claude.com (the claude-api reference): the provider's own account of assembling, caching, and managing context.
• Claude Code documentation (code.claude.com/docs): /compact, /cost, /context, subagents, MCP, and the CLAUDE.md conventions used throughout this chapter.
• The tool docs: RTK (github.com/rtk-ai/rtk), Headroom (github.com/chopratejas/headroom), lean-ctx (github.com/yvgude/lean-ctx), Mem0 (github.com/mem0ai/mem0), LangGraph (github.com/langchain-ai/langgraph).
• Martin Kleppmann, Designing Data-Intensive Applications: not LLM-specific, but the best single source on caching, memory hierarchies, and the systems thinking this chapter applies to context.
• The landscape chapter and the references of this book: the full technique-to-tool map and the papers behind each lever.

Takeaways

• Context engineering is four jobs done every turn: assemble, compress, cache, remember. The twelve levers are those four jobs done well, and real systems stack several at once.
• A reference architecture puts each lever in its place: orchestration decides, compression and retrieval feed in, assembly is the middle, caching wraps the call, an efficient model runs underneath, memory closes the loop.
• Ten minutes of setup (a small stable CLAUDE.md, rtk init -g, a lean-ctx and a memory MCP server, automatic prompt caching) seeds all four jobs and pays off on every turn after.
• Diagnose by symptom with the playbook: does not fit (compress, externalize), too costly (cache prefix or answer, shrink output), forgets (memory), repeats a mistake (learn), pulls the wrong things (route), slow or long-context (serve efficiently, efficient attention).
• The common mistakes are as patterned as the wins: a bloated or moving prefix, dumping instead of reading, flooding the window with tool output, confusing the three caches, and ignoring the expensive output side.

👉 The plan is set; the next chapter runs it as a measured experiment, optimizing one autopilot session lever by lever until it is 7x cheaper, so you can see the compounding and the order of leverage in one table. Continue to The optimization lab.