Context From First Principles

A context window tells us how much a model can receive. Context engineering decides what it should receive, in what form, in what order, and what must be left out.

Imagine an AI coding agent working inside a mature project.

It can see the conversation. The repository contains thousands of files. The project has instructions, architecture notes, tests, issue history, tool definitions, previous attempts, summaries, memories, search results, plans, and state accumulated over hours of work.

The model can technically accept a very large prompt.

What should the system send?

One implementation keeps adding material until the window is nearly full.

Another identifies the current task, preserves what must survive, removes stale and duplicated material, externalizes bulky state, recalls only what becomes relevant, orders the surviving information deliberately, and records exactly what the model received.

Both systems may use the same model.

Both may have access to the same information.

They do not have the same context.

That difference is the subject of this book.

The window is not the context

A production AI system can draw from far more information than one model call should contain:

• system and developer instructions,
• conversation history,
• project rules,
• files,
• retrieved passages,
• tool definitions and results,
• execution traces,
• plans and hypotheses,
• summaries,
• memories,
• external documents,
• policies,
• cached state,
• and artifacts generated by the agent itself.

A context window defines capacity.

It does not decide which information deserves admission.

It does not decide what can safely be removed.

It does not decide whether a summary preserved the fact that later becomes decisive.

It does not decide whether an old plan is stale.

It does not decide which source wins when two sources disagree.

And it does not tell us whether the resulting context improved what the model did.

Those are context-engineering problems.

A stricter definition

This book keeps several ideas separate.

Available information is everything the system could potentially access.

Context is the bounded information and state actually made available to one execution.

Context capacity is how much the model can receive.

Context selection decides which candidate information enters.

Context representation decides the form in which admitted information appears.

Context assembly turns admitted information into an ordered, policy-compliant bundle.

That separation matters because a larger window solves only one problem.

A system can have abundant capacity and still build poor context.

It can include the wrong evidence.

It can preserve stale instructions.

It can bury decisive information inside thousands of merely related tokens.

It can compress away a contradiction.

It can retrieve something useful and fail to admit it.

It can admit the right information in a representation the model does not use effectively.

It can let an untrusted source appear more authoritative than a project rule.

So the central question becomes:

Given more potentially useful information than a model can or should consume, what should it see right now?

Four dimensions instead of one

The book begins with three dimensions that are often collapsed:

capacity        content         representation
how much?      which bits?     in what form?

Then it adds time:

time
when is this information valid, useful, or worth keeping live?

Context grows.

It goes stale.

It is duplicated.

It is summarized.

It leaves the live window.

It may be externalized into files, caches, memory, databases, or derived state.

Later, some of it returns.

The agent also creates future context through plans, notes, summaries, tool traces, critiques, and intermediate artifacts.

Context is therefore not a static prompt.

It is a changing working set.

Seven questions instead of a bag of tricks

The investigation is organized around seven practical questions:

1. What did the model actually receive?
2. What information matters to this task?
3. What must survive exactly, and what may be transformed?
4. What can leave the live window?
5. What should come back, and when?
6. How should the surviving information be ordered and represented?
7. Did the resulting context improve behaviour enough to justify the machinery?

The sequence matters.

Before changing context, observe it.

Before compressing information, decide what must survive.

Before adding retrieval, memory, or external storage, identify why information left the live window.

Before optimizing token count, check whether the cheaper context still supports the same behaviour.

And before adding a sophisticated mechanism to the architecture, demonstrate a failure that the simpler system could not solve.

The book is an experiment

The method is deliberately conservative.

Build the strongest simple baseline.

Measure it.

Stress it.

Find the failure.

Diagnose where the failure occurred.

Add only the mechanism that the diagnosis requires.

Then rerun the same cases and check that the repair did not break what already worked.

OBSERVE
   ↓
BASELINE
   ↓
STRESS
   ↓
MEASURE
   ↓
DIAGNOSE
   ↓
EARN
   ↓
VALIDATE

Context engineering is full of plausible mechanisms.

Longer windows sound useful.

Caching sounds useful.

Pruning sounds useful.

Summaries sound useful.

Retrieval sounds useful.

Memory injection sounds useful.

Structured state, tiered fidelity, externalization, graphs, and policy layers can all sound useful.

But usefulness is conditional.

A mechanism belongs in the final architecture only if it repairs a demonstrated problem at an acceptable quality, cost, latency, and complexity price.

Negative results stay in the argument when they remove unnecessary machinery.

The final Context Compiler should be smaller than the investigation that produced it.

More is not automatically better

One of the book’s central claims is intentionally simple:

Making more information available to a model does not guarantee better behaviour.

Additional context can help.

It can also distract.

Duplicate evidence consumes budget without adding information.

Old plans can compete with current plans.

Failed attempts can look like instructions.

A retrieved passage can be topically relevant but operationally useless.

Important content can become harder to notice when surrounded by a larger amount of merely related content.

Ordering can change which instructions or evidence dominate.

A summary can preserve the theme while deleting the exception that matters.

So token count is not a proxy for useful context.

The important test is behavioural:

Hold the task and model fixed. Change the context. Does the model behave differently, and is the difference useful?

That becomes the eventual test for every major mechanism in the book.

The context window is a budget

A context window is not merely a size limit.

It is a budget.

Every admitted item consumes some combination of tokens, attention, latency, provider cost, cacheability, and competition with other information.

Inclusion therefore has an opportunity cost.

Adding one item may force another out.

Preserving raw evidence may cost more tokens than a summary but protect a distinction that matters.

Inlining a large tool result may simplify access but crowd out source material.

Keeping a stable prefix may improve cache economics while constraining how volatile material is arranged.

The engineering problem is not to maximize occupancy.

It is to maximize useful behaviour under a bounded budget.

Remove before you compress

When context becomes too large, summarization is an attractive first response.

This book treats it as a later response.

Before rewriting information, ask whether some information should remain live at all.

Duplicate content may be removable.

Completed work may be retired.

Failed branches may be externalized.

Stale observations may be invalidated.

Bulky artifacts may be replaced by stable references.

Only then does lossy compression become the obvious next step.

That ordering matters.

Removing irrelevant material can be lossless for the current task.

Compression is a claim about what can disappear without changing future behaviour.

That claim should be measured.

Compression is information selection

A shorter summary is not automatically a better representation.

Compression can preserve the gist while deleting:

• a contradiction,
• a numerical constraint,
• an exception,
• an unresolved question,
• a failed attempt that must not be repeated,
• or the evidence that licences a conclusion.

So the question is not simply:

How many tokens did we save?

It is also:

Which information survived, which information disappeared, and did the loss change behaviour?

Some information may tolerate aggressive reduction.

Some may need structure.

Some may need a pointer back to the source.

Some may need to remain verbatim.

Not all tokens are equal.

Context can leave without being forgotten

A bounded model input does not require a bounded system.

Information can leave the live context while remaining available elsewhere.

That creates an important distinction:

Live context is temporary. Accessible state can be durable.

A system may externalize bulky or lower-priority information into files, stores, caches, indexes, memory systems, or other representations.

But externalization creates a second problem.

Once information has left the working set, how does the system know when to bring it back?

That is why retrieval appears in this book.

Not as the definition of context.

Not as the definition of memory.

But as one possible admission mechanism for information that is no longer live.

The question is whether the right material returns at the right moment, in the right form, under the available budget.

Memory is a context source

This book follows Memory From First Principles, but the two problems are different.

Memory asks how retained past experience remains capable of changing present behaviour.

Context asks which information and state are actually made available to one execution.

A memory system may retain years of project history.

A context system decides whether any of it should enter this model call.

Memory can therefore be a source of context.

So can retrieval.

So can the conversation.

So can tools.

So can files.

So can policy.

So can state the agent generated five seconds ago.

Context engineering sits at the boundary where those sources compete for admission.

The agent writes its own future context

Agentic systems have an unusual property: the model is both a consumer and a producer of future context.

A plan written now may become input later.

A summary may replace the messages from which it was derived.

A hypothesis may persist across tool calls.

A critique may alter the next attempt.

A tool trace may become evidence.

An intermediate artifact may become a dependency.

context
   ↓
model action
   ↓
generated artifact / state
   ↓
future context candidate
   ↓
later model action

Poor context can therefore reproduce itself.

A mistaken summary can survive longer than the raw evidence it replaced.

A speculative plan can acquire authority through repetition.

A stale derived artifact can remain in circulation after the source changed.

Generated context needs the same scrutiny as retrieved context.

Tools produce context

Tool use is often described as something outside the prompt.

From the model’s perspective, it creates context.

Tool definitions consume tokens.

Arguments encode intent.

Outputs may be large, noisy, or partially relevant.

Errors become state.

Repeated observations accumulate.

A long-running agent may spend more context on tool interaction than on the original request.

The system may therefore need to decide which tools to expose, how much schema detail to include, which outputs remain live, what can be reduced, and when the source should be reread rather than trusting an earlier summary.

Tools do not merely act on the world.

They reshape what the model knows about the world.

Representation is part of context

The same information can appear as raw prose, quoted evidence, a table, typed state, a graph edge, a structured record, a summary, a diff, or a compact reference.

Those forms are not interchangeable.

Representation changes token cost.

It changes what relationships are explicit.

It changes how easily provenance survives.

It changes what can be omitted accidentally.

And it may change what the model notices.

Context engineering is therefore not finished when the correct source has been selected.

The representation itself has to earn its place.

Authority, freshness, and scope

Once several sources are assembled together, new failures appear.

A project rule may conflict with an old conversation.

A tool result may conflict with a cached summary.

A memory may preserve a decision that has since been reversed.

A user may change direction.

A dependency version may move.

A plan may complete.

A retrieved document may be relevant to the topic but belong to the wrong project or authority domain.

The context system needs enough provenance and policy to ask:

Where did this claim come from?

Is it raw evidence or a derived interpretation?

Is it still valid?

What scope does it belong to?

Which source has standing when two claims conflict?

Can the original source be reopened?

Relevance is not enough.

Context also needs authority, freshness, and boundaries.

From information to a context bundle

By the later chapters, the central pipeline becomes explicit:

AVAILABLE INFORMATION
        ↓
SOURCE-SPECIFIC CANDIDATES
        ↓
RELEVANCE + VALIDITY + AUTHORITY
        ↓
ADMISSION
        ↓
REPRESENTATION
        ↓
BUDGETING + ORDERING
        ↓
CONTEXT BUNDLE
        ↓
MODEL / AGENT
        ↓
OBSERVABLE BEHAVIOUR
        ↓
EVALUATION

Every arrow can fail.

Useful information may never become a candidate.

A good candidate may be rejected.

A stale candidate may be admitted.

The right source may be represented badly.

Budgeting may evict something decisive.

Ordering may weaken an instruction.

The model may ignore information that survived every earlier stage.

The final answer may even look correct while depending on the wrong evidence.

That is why the book measures the path rather than scoring only the final output.

The Context Compiler

The destination of the investigation is a Context Compiler.

The name is deliberate.

A compiler does not dump its entire input universe into the target representation.

It parses.

It resolves.

It transforms.

It enforces constraints.

It emits a specific artifact for a specific execution.

Conceptually:

task
+ model
+ policy
+ budget
+ available sources
+ current state
        ↓
CONTEXT COMPILER
        ↓
ordered context bundle
+ source lineage
+ admission decisions
+ transformations
+ budget accounting
+ exclusions
+ trace

The compiler is not assumed at the beginning of the book.

It must be earned piece by piece.

If pruning is sufficient, compression should not be mandatory.

If raw excerpts outperform summaries, summaries should not replace them by default.

If a larger window removes the need for a mechanism, the architecture should become simpler.

If a transformed representation cannot preserve its source lineage, it should not silently become source truth.

The current investigation

The working chapter sequence moves from observation to control.

Chapters 1–3 define context and expose the real payload behind an AI interaction.

Chapters 4–7 establish the budget, measure interference and order effects, and classify what different kinds of information are allowed to lose.

Chapters 8–14 investigate the main responses to bounded context: larger windows, caching, pruning, compression, progressive fidelity, externalization, and selective recall.

Chapters 15–21 expand the problem to agent-generated state, memory, tools, representation, authority, freshness, and isolation.

Chapters 22–24 bring the pieces together: assembly for a task, behavioural evaluation, and the Context Compiler.

The outline is intentionally provisional.

Chapters may merge, split, move, or disappear when experiments show that a supposed mechanism does not earn its place.

Two things are being built

The book builds a context runtime, but it also builds the instrument required to distrust that runtime.

The instrument begins before the advanced architecture does.

It should observe:

• the actual payload sent to the model,
• where each context item came from,
• how many tokens each source consumed,
• which items were transformed,
• which items were omitted,
• where admitted items appeared,
• what the model did,
• what the execution cost,
• and what changes when context is removed, restored, reordered, compressed, or replaced.

The system and the instrument grow together.

When pruning appears, the instrument measures what disappeared.

When compaction appears, it measures information survival.

When externalization and recall appear, it measures whether decisive information returns.

When authority appears, it records why one source outranked another.

When assembly appears, it records the final bundle and the exclusions.

When the book eventually claims that a context mechanism helps, that claim should be tied to behaviour rather than token count alone.

What you should be able to do after reading

By the end of the book, a reader should be able to ask much harder questions than how large is the context window?

What did the model actually receive?

What information was available but excluded?

Why did one item enter and another stay out?

Which content had to survive exactly?

Which content was transformed?

What did the transformation lose?

What left the live context but remained recoverable?

Why did a particular item return?

Which context was generated by the agent itself?

What became stale?

What crossed a scope boundary?

Which source had authority when two items disagreed?

How much did the final bundle cost?

Did changing the context change the behaviour?

Did that change help?

And which parts of the final architecture were measured results rather than attractive ideas?

Those questions turn context engineering from prompt craft into systems engineering.

The larger idea

The deeper argument is not that prompts should be shorter.

It is not that prompts should be longer.

It is not that every system needs retrieval, memory, summaries, or a giant context window.

It is that context should be treated as a controlled compilation of a larger information world into the bounded working state of one execution.

That compilation has to decide what enters.

It has to decide what stays out.

It has to preserve distinctions that matter.

It has to keep stale or out-of-scope information from acquiring accidental influence.

It has to move information out of the live window without making it irrecoverable.

It has to bring information back without flooding the model.

It has to preserve provenance and authority when sources compete.

It has to respect a budget without mistaking fewer tokens for better context.

And finally, it has to show that the resulting context made the model behave better.

The destination is a system that can answer a more demanding question:

What is the smallest, safest, most useful representation of what this model needs to know right now?

That answer will sometimes be a raw source passage.

Sometimes a structured record.

Sometimes a tool result.

Sometimes a memory.

Sometimes a compact reference.

Sometimes a summary.

Sometimes an instruction.

Sometimes nothing at all.

The value is not in giving the model everything.

It is in giving it the right information, in the right form, with the right standing, at the right moment — and being able to prove why.

Context engineering begins when a larger window stops being an answer.

Continue with What Context Means.