N-0284 / NOTE / UPDATED 2026.08.25

Context Engineering Is Becoming Infrastructure.

LLM
AGENTS
MEMORY
RAG

Prompt engineering optimizes a message. Context engineering designs the information environment in which a model has to reason, act and recover.

01 / The shift

For the first generation of language-model applications, the prompt was treated as the primary unit of system intelligence. The basic engineering question was simple: what should we ask the model?

That framing works when a request is short, stateless and self-contained. It becomes weaker as soon as the model is expected to remember prior decisions, inspect tools, retrieve documents, obey product rules, carry structured state and produce work that can survive retries.

The problem is moving from writing better instructions to constructing better information environments.

In that environment, the prompt is only one stream among many. Tool descriptions, retrieved passages, memory summaries, user state, system constraints, intermediate results and task history all compete for limited attention.

02 / Context as runtime

A useful mental model is to treat the context window as a runtime address space. The system is responsible for deciding what enters it, when it enters, what gets compressed, what gets evicted and what must remain stable across steps.

CONTEXT RUNTIME = instructions + state + evidence + memory + tool interfaces + intermediate results + output constraints

This leads to a design discipline closer to operating systems and databases than copywriting. Every token has a provenance, a cost and a reason to exist. Some context is trusted, some is user-controlled, some is generated by models, and some is derived from external systems.

Context should be typed

When all information is flattened into prose, the model must infer structure that the application already knows. Typed blocks, explicit provenance and clear temporal boundaries reduce ambiguity before the model sees the task.

03 / Retrieval is a policy

Retrieval-augmented generation is often described as “search, then paste.” In practice, retrieval is a decision policy: choose a corpus, choose operators, select evidence, resolve conflicts, control redundancy and decide when retrieval is unnecessary.

A system that retrieves the ten nearest vectors for every request is not really doing context engineering. It is performing a fixed heuristic that happens to add text.

GOOD RETRIEVAL IS SELECTIVE. More evidence is not automatically better context.

04 / Memory is context delayed in time

Agent memory can be viewed as a persistence layer for future context construction. The important question is not only what to save, but what future decision would justify retrieving it.

Working memory keeps the immediate task coherent. Episodic memory preserves meaningful events. Semantic memory condenses durable facts and learned relationships. The application still needs policies that determine which memory form is consulted at each step.

05 / Engineering implications

Once context becomes infrastructure, observability must capture more than the final prompt. We need to know which sources were considered, which were selected, what was compressed, what was omitted, and which tool result caused the state transition.

This also changes testing. A “prompt test” is insufficient when failures can originate in retrieval, stale memory, schema drift, missing tool metadata, context overflow or incorrect state reconstruction.

The durable unit is therefore not the prompt. It is the context assembly pipeline: a reproducible mechanism that converts system state into the smallest useful information environment for the next model decision.