- 01. How to design a complete context assembly pipeline using everything from Topics 1-9.
- 02. Why Claude Code is the reference implementation that shows how all CONTEXT layers work together in production.
- 03. The specific sequence of operations that runs before every inference call — and why that sequence matters.
- 04. The exact 10-step sequence that runs before every single inference call — with a real production trace you can lift into your own product.
- 05. The single most consequential reason most AI products that work in a notebook fail when they hit production.
The Story
Every Claude Code request triggers a 14-step context-assembly pipeline that runs in under two seconds — and that pipeline, not the model, is why Anthropic's coding assistant became one of the most-used AI dev tools within months of its January 2025 launch. The model is the same model the competitors use. The information environment around it is what's different.
When a developer types a request — say, "fix the authentication bug in the login module" — what the user experiences as a simple conversation is actually a 14-step context assembly process that runs in under 2 seconds. The model doesn't just receive the request. It receives a carefully assembled information environment.
The system loads a CLAUDE.md file from the project directory — a constitution that defines how to work in this specific codebase. It reads relevant source files — not all of them, but the ones most likely to contain the bug. It checks for project-specific memory. It loads tool definitions — read file, write file, run tests, search codebase — but only the tools relevant to the current task. It applies output formatting rules.
The result: when the model generates a response, it knows the project's conventions, has seen the relevant code, remembers past decisions, and has the right tools available. The developer gets an answer that's specific to their codebase, not generic coding advice.
Here's what made Claude Code's approach distinctive: when the context accumulated too much information, the system spawned a sub-agent with a fresh context window rather than compressing the existing one. Reset, not compress. Exactly the principle from Topic 4.
The Core Idea
A context pipeline is the automated system that assembles the complete context window before every inference call. It's the operational implementation of everything this Level has taught — from context as a system (Topic 1), through the seven CONTEXT layers (Topic 3), to structure as control (Topic 9).
Here's the sequence that runs before every inference call in a production AI product:
Step 1: Load Constitution. The system prompt goes in first — at the beginning of the context window where attention is strongest. Identity, rules, constraints, priority hierarchies. Fixed per release. ~2,000-4,000 tokens.
Step 2: Classify Intent. Before loading anything else, determine what the user is asking about. This classification drives everything that follows: which knowledge to retrieve, which memory to load, which tools to make available.
Step 3: Retrieve Knowledge. Based on the classified intent, the RAG pipeline runs: embed the query, search the knowledge base, rerank the results, select the top chunks. ~4,000-8,000 tokens.
Steps 4-10 continue through loading memory, selecting tools, injecting examples, applying templates, appending the user message, validating the token budget, and generating the response.
A context pipeline is the automated system that assembles the complete context window before every inference call — the pit crew for every inference call.
— The working definitionThink of it like the pit crew at a Formula 1 race. When the car pulls in, every crew member has a specific role in a specific sequence — tires, fuel, adjustments, checks — executed in under 3 seconds. The driver doesn't coordinate the pit stop. The pit crew does. The context pipeline is the pit crew for every inference call.
The shift from Topics 1-9 to this foundation topic is the shift from understanding individual layers to designing the system that orchestrates them. And that shift reveals several principles that only become visible when you think about the pipeline as a whole.
The order matters. The constitution loads first because it needs to occupy the high-attention beginning of the context. Knowledge loads near the end because it needs to be close to the user's question. Memory loads in the middle because it's supporting context, not the primary signal.
Classification is the first gate. If the intent classifier is wrong, the wrong knowledge gets retrieved, the wrong tools get loaded, and the wrong template gets applied. Some production systems invest in a dedicated classification step — even if it adds 100-200ms of latency — because a correct classification with the right context dramatically outperforms a fast response with the wrong context.
The pipeline IS the product. Two companies using the same model, the same retrieval technology, and the same tool integrations will build completely different products based on their pipeline design. The pipeline decisions are product decisions. The model is one API call inside that pipeline.
Where This Hits in Production
The "works in notebook, fails in production" gap. The most common failure pattern: the product works in a Jupyter notebook where the developer manually assembles context. In production, context assembly is automated — and the automation misses nuances the developer handled intuitively. The pipeline is where the notebook prototype becomes a production system, and it's where most AI products fail.
Framework independence. The pipeline design should be framework-agnostic. Whether you implement it in LangChain, LlamaIndex, or custom code, the DESIGN is the same. The framework is the implementation detail. The pipeline design outlives any specific framework — and frameworks in this space change every 3-6 months.
The monitoring surface. A well-designed pipeline creates a natural monitoring surface: you can measure the quality and latency of each stage independently. That specificity turns "the AI gives bad answers sometimes" into "the retrieval service returns stale documents for 3.2% of queries in the billing category."
Different Product.
What the model sees decides what the product does.
The Trap
Building the pipeline before understanding the layers.
Teams hear "context pipeline" and jump to implementation. They choose a framework (LangChain, usually), connect a vector database, wire up some tools, and start iterating on output quality. The framework becomes the architecture instead of the architecture informing the framework choice.
Six months later, they've built a pipeline deeply coupled to the framework's abstractions, with no observability into what's happening at each stage. Debugging means reading logs. Improving means trial-and-error on the prompt.
The fix: design on paper first. Seven questions (one per CONTEXT layer, plus budget and reset strategy) define the pipeline architecture. Then implement with whatever framework fits. The design outlives the framework.Connecting the Dots
This topic is the foundation bridge between Level 1 (Context Engineering) and Level 2 (Harness Architecture). The context pipeline is the simplest form of a harness — an automated system that does something useful before and after the model generates.
The CONTEXT framework — a proprietary mnemonic I created — is the foundation for everything that follows. In production AI systems, these seven layers have a complex, dynamic interplay across multiple turns, multiple agents, and multiple sessions. Understanding each layer individually was the necessary first step. Understanding how they interact — how they reinforce each other, conflict with each other, and compound their effects — is what the rest of this deep dive covers.
One last insight: the best context pipelines feel invisible. The user types a question, gets a good answer, and never thinks about the 10 steps that ran in 1.5 seconds. That invisibility is the sign of good engineering.
In Practice — End-to-End Pipeline Trace
Here is what a context pipeline looks like when traced end-to-end for a single user query in a production customer-success AI. A CSM types: "What's the renewal risk for the Acme Corp account?"
PIPELINE TRACE — Query #847291
Timestamp: 2026-04-12T14:23:01Z
User: csm-jennifer@company.com
Query: "What's the renewal risk for the Acme Corp account?"
STEP 1: LOAD CONSTITUTION 48ms
├── System prompt v4.2 loaded 2,800 tokens
├── Priority hierarchy: accuracy > actionability > speed
└── Refusal rules: never predict churn probability > 6 months
STEP 2: CLASSIFY INTENT 62ms
├── Intent: account_risk_assessment
├── Confidence: 0.94
├── Account identified: Acme Corp (acct_12847)
└── Tools needed: [account_lookup, usage_metrics,
support_tickets, renewal_history]
STEP 3: RETRIEVE KNOWLEDGE 340ms
├── Query embedded: 12ms
├── Vector search: 89ms → 18 candidate chunks
├── Rerank: 142ms → top 5 selected
├── Chunks loaded: 4,200 tokens
│ ├── [1] Renewal playbook — high-risk signals (rel: 0.92)
│ ├── [2] Acme Corp contract terms (rel: 0.89)
│ ├── [3] Industry benchmark: SaaS renewal (rel: 0.84)
│ ├── [4] Escalation protocol for at-risk accts (rel: 0.81)
│ └── [5] Pricing flexibility guidelines (rel: 0.77)
└── Freshness check: all docs < 30 days old ✓
STEP 4: LOAD MEMORY 87ms
├── Account profile (always loaded): 420 tokens
│ ├── Acme Corp, Enterprise plan, $180K ARR
│ ├── CSM: Jennifer, since 2024-Q2
│ └── Health score: 62 (declining trend)
├── Recent interactions (last 2): 680 tokens
│ ├── Mar 28: QBR — CFO expressed budget concerns
│ └── Apr 3: Support escalation — API latency issue
├── Episodic retrieval (risk-relevant): 540 tokens
│ └── Jan 15: Champion (VP Eng) left company
└── Semantic facts: 180 tokens
├── "Price-sensitive since Q3 2025"
└── "Competitor eval mentioned in QBR"
STEP 5: SELECT AND LOAD TOOLS 15ms
├── account_lookup (loaded): 180 tokens
├── usage_metrics (loaded): 200 tokens
├── support_tickets (loaded): 170 tokens
├── renewal_history (loaded): 160 tokens
└── 30 other tools: NOT loaded (intent filtering)
STEP 6: INJECT EXAMPLES 12ms
├── 1 example of excellent risk assessment: 380 tokens
└── Shows format, depth, and tone expected
STEP 7: APPLY TEMPLATE 5ms
├── Template: renewal_risk_assessment (JSON + narrative)
└── Schema: 100 tokens
STEP 8: APPEND USER MESSAGE 2ms
└── "What's the renewal risk for the Acme Corp 45 tokens
account?"
STEP 9: VALIDATE TOKEN BUDGET 3ms
├── Total assembled: 10,072 tokens
├── Budget: 24,000 tokens
├── Utilization: 42%
└── Status: WITHIN BUDGET ✓
STEP 10: GENERATE 1,840ms
└── Model generates response using full context
─────────────────────────────────────────────
TOTAL PIPELINE: 2,454ms (latency budget: 3,000ms ✓)
TOTAL CONTEXT: 10,072 tokens (budget: 24,000 ✓)
TOTAL COST: $0.030 input + $0.045 output = $0.075
─────────────────────────────────────────────
What the CSM sees. A risk assessment that references Acme's specific contract terms, mentions the champion's departure, flags the CFO's budget concerns from the QBR, notes the unresolved API latency issue, and provides recommended actions based on the company's renewal playbook. It takes 2.5 seconds. It feels like the AI deeply understands this account.
What actually happened. Ten steps. Seven CONTEXT layers. Five external service calls. 10,072 tokens assembled in 614ms of pipeline time, plus 1,840ms of model generation. The AI does not understand anything. The pipeline assembled the right information in the right structure, and the model reasoned over it. The illusion of understanding is the design choice. Make it deliberately, every step.
Remember This
1. A context pipeline is the automated system that assembles the complete context window before every inference call. It's where Topics 1-9 become a running system — and it's the simplest form of a harness (Level 2).
2. Design on paper before coding. Seven questions (one per CONTEXT layer, plus budget and reset strategy) define the pipeline architecture. Then implement with whatever framework fits. The design outlives the framework.
3. The pipeline IS the product. Same model, different pipeline = different product. Pipeline decisions are product decisions — not engineering implementation details.
References
1. Building Effective Agents — Anthropic Engineering Blog
2. Context Engineering for AI Agents — Anthropic Engineering Blog
3. Claude Code Engineering Notes — Anthropic