Context From First Principles
Chapter 03 of 24

The Context You Didn't Type

By AI, Software Engineering

Explain this chapter with AI

Copy this prompt into ChatGPT, Claude, Gemini, a local model, or another AI.

Apply this chapter with AI

Copy this prompt into ChatGPT, Claude, Gemini, a local model, or another AI.

The mental model most users carry looks like this:

user
 ↓
model
 ↓
answer

A message goes in, intelligence happens, an answer comes out. Everything in the previous chapter says this picture is false, but the previous chapter showed the falsity as accounting tables. This chapter shows it as machinery. Behind a production assistant stands a runtime that assembles a layered stack of instructions, definitions, state, history, and observations, and the user’s message arrives near the bottom of that stack, not the top of it.

We study this stack through one principal case: Claude and Claude Code. The choice is methodological, not tribal. No vendor chapter follows; the book is organised by mechanism. Claude earns the slot because its context machinery is unusually inspectable: Anthropic officially publishes chat-app system prompts per model, documents its context-engineering practices in engineering writing, and distributes Claude Code as software whose prompt material can be examined, supplemented by a meticulous third-party extraction that must be handled with provenance care. Where other vendors’ machinery is equally inspectable on some point, later chapters will use them. Here, one worked case examined honestly teaches more than five vendors surveyed loosely.

What we can know, and how we know it

Provenance first, because everything else in the chapter depends on it. Claims about Claude’s context stack come from three sources of very different standing, and they must never be blended.

First, Anthropic officially published material. Anthropic maintains public release notes publishing the core system prompts for the claude.ai web interface and mobile apps, per model, and states explicitly that these prompts apply to those surfaces and not to the API. Separately, Anthropic’s engineering publications describe practices in general terms: the context-engineering essay defines context as the tokens included when sampling, advocates the smallest high-signal set, and describes compaction, structured note-taking, and sub-agent architectures as the long-horizon techniques, including the detail that Claude Code drops CLAUDE.md files into context up front while leaving file discovery to just-in-time tool use. The tools essay describes how tool definitions and responses consume context and reports design choices such as token-efficient responses. These sources carry first-party authority for exactly what they state and no further.

Second, material visible in officially distributed Claude Code software. Claude Code ships as installable software, and prompt strings, tool definitions, and harness behaviours observable in that distribution are first-party artefacts. They show what the software contains, though interpreting why a string is present, when it is conditionally included, and what it does in combination with server-side behaviour requires care. This book treats distributed-software observation as evidence about the client’s contribution to assembly, not as a complete account of the invocation.

Third, third-party extraction and reconstruction. The repository Piebald-AI/claude-code-system-prompts extracts prompt strings from Claude Code’s compiled source and tracks them across releases (at the time of verification, 515 prompts tracked across 296 versions up to v2.1.280, 22 September 2026). This is diligent, useful, third-party work, and it must be labelled as such. It is not an Anthropic publication. Its contents shift with every release, its token counts are estimates against a particular build, and no prompt text found there should be quoted as Anthropic doctrine. What it legitimately teaches is structural: the order-of-magnitude size of the prompt surface, its conditional and compositional character, and the categories into which the pieces fall.

The rule for the chapter: every claim about Claude internals names its tier. Official publication, distributed-software observation, or third-party extraction. Anything else is speculation and is marked as such.

The stack

With provenance established, the conceptual model. A production coding assistant’s invocation is assembled from layers accumulated in roughly this precedence order:

vendor/model instructions
          ↓
product instructions
          ↓
project instructions
          ↓
environment state
          ↓
tool definitions
          ↓
tool schemas
          ↓
conditional reminders
          ↓
conversation
          ↓
summarised/compacted history
          ↓
retrieved files
          ↓
tool observations
          ↓
current user input
          ↓
        MODEL

Read top to bottom as decreasing generality and increasing volatility. Vendor instructions change with model releases. Product instructions change with harness versions. Project instructions change when the repository’s rule files change. Environment state (working directory, platform, date) is re-rendered per session. Tool definitions are stable within a version but numerous. Conditional reminders appear only when triggered. Conversation grows every turn. Summaries replace what they compress. Retrieved files and tool observations are the most volatile of all, arriving mid-task and expiring in relevance within turns.

Two warnings accompany the diagram. First, it is a conceptual decomposition, not a wire protocol. No claim is made that any particular invocation orders these layers exactly so, byte for byte; harnesses differ, versions differ, and server-side assembly is not fully visible from outside. The diagram’s purpose is to name the categories so they can be observed, which is exactly what the Chapter 2 schema’s source, type, authority, and scope fields were designed to record. Second, the stack is not universal. A bare API call carries a fraction of these layers; a multi-agent research harness carries more. The lesson is not the list. The lesson is the sentence:

The effective context is assembled by a runtime.

The following table summarises each layer’s placement, volatility, and the authority it claims. It is the same information as the prose, rearranged for the reader who wants the whole stack on one page.

Layer Placed by Volatility within a session Authority claimed
Vendor/model instructions Model provider Version changes only Highest; defines identity and defaults
Product instructions Harness authors Harness updates; conditional branches per turn High; governs agency and tool use
Project instructions Repository authors, via harness injection File edits Project-wide; standing conventions
Environment state Runtime Re-rendered per session None; locational fact
Tool definitions and schemas Tool/Harness authors Stable within a version Descriptive; defines capabilities
Conditional reminders Harness triggers Fires only when conditions match Situational; easily mistaken for standing rules
Conversation Participants, via harness Grows every turn Mixed; each turn carries its own
Summarised history Runtime summariser Rewritten at compaction events Derived; inherits whatever the summary preserved
Retrieved files Retriever or agent, via tools Loaded and superseded mid-task Evidential; grounds factual claims
Tool observations Tools Largest and most volatile Data; must not be read as instruction
Current user input User New every turn Highest for intent; narrowest in scope

Nobody typed most of it. Every layer was placed by software pursuing some design goal (safety, helpfulness, capability, continuity), and every layer costs tokens, attention, and cache stability whether or not it earns them on this particular turn.

Layer by layer

Vendor and product instructions sit at the top and carry the highest claimed authority. The officially published chat-app prompts show the genre: identity, date awareness, formatting conventions, behavioural defaults. They are the only layer whose exact text, for the chat surfaces, can be quoted from a first-party source, and even there the per-model release-notes pages remind us that prompts are versioned artefacts, not timeless truths. The harness-level product instructions, the ones steering agentic looping, tool choice, and compaction behaviour, are where third-party extraction becomes structurally informative: hundreds of distinct strings for sub-agents, slash commands, summarisation, and evaluation utilities show that “the system prompt” is a composed assembly with conditional branches, not a paragraph. The engineering significance is that the top of the stack is itself a program with versions and conditions, and debugging agent behaviour without knowing which branches fired is guesswork.

Project instructions are the first layer the user controls without realising they are programming context. Files such as CLAUDE.md or AGENTS.md, checked into the repository, written in prose and edited like documentation, are injected into the invocation by the harness. Anthropic’s engineering writing confirms the mechanism in general terms for CLAUDE.md. From the context-engineering viewpoint, project files are remarkable objects: durable session-external state that becomes per-invocation context by rule, carrying project authority into every turn at a standing token cost. A twenty-line project file is cheap. A two-thousand-line one, accumulated across teams and quarters, is a standing tax on every computation the agent performs, and it is edited with none of the measurement discipline the book demands. Chapter 19 will ask who gets to be right when project rules conflict with user instructions; here the point is simpler: the file is in the bundle, and the bundle is bigger because of it.

Environment state is the layer nobody writes and everybody pays for. Working directory, operating system, tool versions, date, sometimes directory listings or shell context. Individually trivial, collectively a few hundred tokens of near-zero volatility within a session, which makes them ideal stable-prefix citizens and poor suspects for removal. Their interest for this chapter is as an example of context that exists outside any user message and outside any instruction hierarchy, placed by the runtime because the agent cannot act in a world it cannot locate.

Tool definitions and schemas are the chapter’s most underappreciated cost. Before any tool is invoked, every available tool’s name, description, and parameter schema occupies context. Anthropic’s tools essay states the mechanism plainly: tool descriptions are loaded into agent context and collectively steer behaviour, and bloated or overlapping tool sets distract agents and waste the limited budget. Good tool design (distinct purposes, descriptive parameters, minimal overlap) is therefore context engineering, not just API design. The structural evidence from extraction repositories reinforces the scale: built-in tools with large descriptions, utility prompts for dozens of commands, and sub-agent definitions each contribute standing tokens. A harness offering fifty tools has spent a significant fraction of its budget before the user asked anything, and adding “just one more tool” is a context decision wearing a product disguise. Chapter 17 will treat tools as first-class context in full; here they enter as the layer that converts capability into cost.

Conditional reminders are instructions injected when triggered: a nudge about test discipline after file edits, a formatting rule when a certain output is expected, a policy reminder in a sensitive domain. They are the most dynamic instruction layer, and therefore the most dangerous to cache layouts and the hardest to debug from transcripts, because the transcript rarely marks which reminders fired. Their existence is well attested in the structural record of hundreds of conditional prompt strings; their exact behaviour in any build is version-specific. The measurement lesson is that “the system prompt” is not constant across turns even within one session, which is why the Chapter 2 schema records per-invocation position and stability rather than assuming a fixed preamble.

Conversation, summaries, files, and observations form the growing middle and bottom. Conversation history accumulates turn by turn. Summarised history replaces raw turns with model-generated condensations. Retrieved files arrive through just-in-time mechanisms, loaded at runtime through tools rather than up front. Tool observations (command outputs, search results, file contents, error traces) land directly above the current user input and are typically the largest and most volatile category in a working session.

Two of these lower layers deserve closer attention because later chapters will operate on them directly. Compaction, as described in Anthropic’s engineering writing, passes message history back through the model to preserve decisions, unresolved bugs, and implementation details while discarding redundant tool outputs, then continues with the compressed context plus recently accessed files. The same essay names the lightest-touch variant: clearing old tool results while keeping the surrounding structure. Both are lossy transformations applied to the only record of what happened, and both illustrate the chapter’s theme at a different scale: a runtime rewriting history the user will never re-read, trading information survival against budget. Whether the trade was fair can only be judged by measuring what survived, which is Chapter 11’s problem; that the rewriting happens outside the user’s view is this chapter’s.

Just-in-time retrieval is the complementary mechanism. Rather than loading everything retrievable up front, the agent holds lightweight identifiers and loads contents at runtime through tools, which makes identifiers cheap and contents expensive. A well-organised environment lets the agent spend its budget on what it actually opens; a poorly organised one forces broad, wasteful reads. Either way, retrieved contents land in the bundle as tool observations, and from that moment they are context like any other: costed, competing, and positional.

The ordering of these lower layers matters behaviourally. Tool outputs adjacent to the current request compete most directly with it; summaries of old decisions sit far from the decision point they describe. Position effects are established background: the peer-reviewed finding that models use information at context boundaries more reliably than information buried mid-context, which is why the instrument records position from the start. But ordering mechanisms belong to Chapter 6. This chapter’s claim is only that the layers exist, that a runtime placed them, and that the user typed almost none of them.

Authority and scope: why the schema records them

Two schema fields have waited for their justification: authority and scope. Consider what happens when layers disagree. The project file says “never modify migration files.” The current user says “just edit the migration directly, I’ll be careful.” A tool result pastes a README that says “always run with –force.” Three instructions, three claimants, one bundle. Rendered as tokens they are indistinguishable; recorded with authority (project, user, tool-output text) and scope (project-wide standing rule, single-turn request, third-party document of unknown standing) they are adjudicable. The v0 record does not resolve the conflict. It preserves the metadata without which no later policy layer could resolve it consistently. Chapters 19 and 22 will inherit these fields; this chapter banks them.

The same fields discipline a subtler problem: tool output masquerading as instruction. Tool results are data, but they arrive as prose, often imperative in mood (“to fix this, delete the cache directory”). An agent that treats pasted text as orders is the prompt-injection failure in miniature, and the bookkeeping that distinguishes “the user instructed” from “a tool result contained the words” starts at capture time. Authority is not a solution to injection. It is the record that makes solutions testable.

What extraction legitimately teaches

Return to the question of what the third-party record can and cannot support. It cannot support claims about what any particular invocation contained: assembly is conditional on environment, configuration, and version, and server-side contributions are not in the extracted corpus at all. It cannot support quotation of prompt text as representing Anthropic’s considered guidance: strings in shipped software include experiments, fallbacks, legacy branches, and scaffolding. Treating all of it as doctrine would be like treating every commented-out line in a repository as architecture.

What it can support is structural. First, scale: the prompt surface numbers in the hundreds of strings with per-string token counts, which establishes that standing instruction overhead is a budget line item, not a rounding error. Second, conditionality: large portions are included only under certain configurations, which establishes that the top of the stack varies across installations and sessions. Third, categorisation: distinct families for sub-agents, slash commands, summarisation, and evaluation utilities, which establishes that the harness programs many roles, each with its own context needs. These three structural facts transfer across vendors and versions even as every string changes. They are the reason the chapter leans on the extraction without quoting it: the shape is the evidence.

The cost of every layer

Each layer was added for a reason, and most reasons were good. Vendor instructions align behaviour. Product instructions enable agency. Project files carry hard-won conventions. Tools enable action. History enables continuity. Files ground claims. None of this justifies any particular layer’s presence in any particular invocation. Justification is per-computation, and the stack makes visible what must be justified: every layer costs tokens against capacity, competes for the model’s finite attention, and where it shifts position or content across turns it disturbs the stable prefixes that caching economics depend on. OpenAI’s caching documentation gives the mechanism its sharpest statement: reuse requires the entire rendered prefix to match, so a volatile layer placed early can invalidate the stability of everything after it.

This is the observation with which the chapter ends and the next begins. The hidden stack is not free. It is a budget allocation performed implicitly by many hands: vendor engineers, harness authors, tool designers, past selves who wrote project files, and the agent’s own earlier turns, none of whom saw the final total. Chapter 4 makes that allocation explicit:

The context window is a budget.

Proposed experiment: adding layers one at a time

The chapter’s hypothesis needs a controlled form. Build a tiny synthetic assistant over a fixed model and task: a simple multi-step task with an externally checkable outcome, such as editing a small repository to satisfy a specification. Define six cumulative conditions:

condition A   one system instruction
condition B   + project rule file
condition C   + tool definitions
condition D   + environment state
condition E   + previous history (a fixed prior transcript)
condition F   + retrieved information (fixed excerpts)

Hold model, version, settings, and task constant across conditions. Run each condition multiple times. Measure total rendered input tokens, task outcome, tool-call sequences and tool choice, and instruction adherence scored against a fixed rubric (including at least one deliberately checkable project rule, so that adherence is measured, not impressionistically judged).

Pre-register the reading of the results. The experiment tests two predictions: that token cost grows monotonically across conditions A to F, and that behaviour changes non-monotonically, improving where a layer supplies genuinely needed information, degrading or destabilising where a layer adds distraction, conflict, or sheer volume. Any condition whose removal leaves behaviour unchanged names a layer that cost without earning on this task. Do not claim these outcomes now. The design is the contribution of this chapter; the results belong to frozen runs that do not yet exist.

References