Context Engineering

When Prompting Became Systems Engineering

The hard part of an AI application is rarely finding one more clever sentence for its prompt. The harder problem is deciding what the model should be allowed to see at the exact moment it must make a decision.

That decision may depend on the user’s request, system instructions, a few examples, recent conversation, retrieved documents, tool definitions, tool results, application state, identity, policy, and the outcome of earlier steps. All of those inputs compete for a limited working set. Some are authoritative. Some are stale. Some are untrusted. Some are useful only if the model asks for them at the right time.

This is the problem now commonly called context engineering.

Context engineering is not a replacement for prompting. It is the larger systems problem that appears when a prompt becomes one component of a runtime-managed context. The durable question is not how to put more text in front of a model. It is how to assemble the smallest useful working set, preserve its meaning and authority, and observe what the model actually received.

This is Post 06 in The Abstraction Shift: How Software Keeps Moving Up.

In One Sentence

Context engineering is the design of the information, instructions, state, capabilities, and constraints assembled for a model at each decision point, with explicit attention to relevance, authority, freshness, cost, security, and evaluation.

The distinction from prompt engineering is one of scope.

Prompt engineering asks:

What instructions and examples should we write?

Context engineering asks:

What should be in the model’s working set for this decision, where did it come from, how much should be included, and what should happen when it is missing or conflicts?

The first question still matters. The second question becomes unavoidable once the system has multiple turns, tools, retrieval, memory, changing data, and meaningful side effects.

Why This Exists

A one-shot model call encourages a simple mental model:

user request + prompt
          |
          v
        model
          |
          v
        answer

That model is useful for a narrow task. It becomes incomplete when the application can search, inspect files, call APIs, remember earlier work, or delegate to another process.

The possible information available to the system is much larger than the information sent to the model:

enterprise data, documents, tools, history, state, policy
                         |
                         v
              context selection and assembly
                         |
                         v
                model-facing working set

The system therefore has two different spaces:

1. The information space, which contains everything the application could retrieve, calculate, or expose.
2. The context space, which contains the selected material included in the next model input.

The model does not reason over the whole information space. It reasons over the context it receives, plus whatever it can obtain through the capabilities made available to it. An important architectural consequence follows:

If a fact is not in the current context and the model has no reliable way to obtain it, that fact is effectively absent from the decision.

This is why a retrieval system, an MCP server, a memory store, or a tool catalogue does not automatically become useful context. Availability is not selection. Selection is not trust. Trust is not authority.

As AI applications moved from single-turn generation toward agents and longer workflows, engineers needed a name for the broader work of managing this changing working set. Anthropic describes context engineering as the curation and maintenance of the tokens available to an agent during inference, including system instructions, tools, protocol information, external data, and message history. The term is useful because it makes the runtime context a design object rather than an accidental concatenation of strings.

What We Did Before

Software engineers have always assembled working inputs for computation. The names were different because the caller and the computation behaved differently.

Configuration and dependency injection

An application starts with configuration, credentials, feature flags, environment variables, and dependencies. The runtime assembles those values before a component executes.

This is a useful analogy for context engineering because it makes assembly and ownership visible. It is incomplete because a model does not reliably interpret every configuration value as a deterministic parameter. It may misunderstand a value, give too much weight to a less authoritative instruction, or act on content that was never intended to control behavior.

Request context

Web frameworks and service runtimes carry request context: identity, locale, correlation identifiers, deadlines, cancellation state, and tracing information. A handler receives only the context relevant to that request.

This is closer to the runtime problem. Context is scoped, assembled, and propagated. But model-facing context usually mixes operational metadata with natural language, examples, documents, and proposed actions. The result is not a typed call frame unless the application makes it one.

Working sets and caches

Operating systems and databases avoid treating all available data as equally active. They maintain a working set of information likely to be needed soon and move information in and out as access patterns change.

The analogy helps explain why more context can make a system worse. It breaks when tokens are mistaken for addressable memory. A model does not perform a deterministic lookup against a token list. Position, wording, repetition, ambiguity, and relationships between items affect how the input is interpreted.

Retrieval pipelines

Search systems retrieve candidate records, rank them, and return a limited result set. Retrieval-augmented generation extended that pattern by placing selected records beside a user’s request before generation.

Context engineering includes retrieval, but it is broader. It also governs instructions, examples, tools, history, identity, policy, observations, and the decision to retrieve more information later. Retrieval is one source of context, not the whole context architecture.

Prompt templates

Prompt templates made a model call repeatable. They separated stable instructions from changing values and allowed teams to test variants.

That remains valuable. The shift is that the changing values are no longer only form fields or database rows. They can include a model-selected tool, an observation from the last step, a retrieved document, a summary of an earlier context window, or a policy decision. The template has become a runtime assembly boundary.

The Abstraction Shift: How Software Keeps Moving Up

Prompt engineering treats the prompt as the main artifact. Context engineering treats the model-facing working set as a system projection.

The difference can be stated as a progression:

write a prompt
  -> assemble a request
  -> select a working set
  -> manage context across decisions
  -> evaluate the resulting behavior

The shift changes what engineers design:

Earlier emphasis	Context-engineering emphasis
Write clear instructions	Decide which instructions apply now
Add more examples	Select a small, representative example set
Retrieve relevant documents	Retrieve, filter, annotate, and order evidence
Send conversation history	Maintain the smallest useful history and durable state
Expose every available tool	Expose a legible, bounded capability set
Increase the context window	Spend the context budget where it improves the decision
Inspect the final answer	Trace the context, decisions, tool calls, and outcome

The application is no longer only a caller of a model API. It is a context compiler. It gathers inputs from different owners, applies selection rules, renders them into a model-facing representation, and carries the model’s result into the next cycle.

That compiler analogy is also incomplete. A conventional compiler transforms a defined source language according to rules that are intended to be stable and reproducible. A context assembler prepares an input for a probabilistic interpreter whose behavior can vary even when the rendered input is identical. The right lesson is not that context engineering makes model behavior deterministic. It is that it gives the system an explicit place to manage the inputs that shape that behavior.

Context engineering expands the design problem from writing instructions to assembling a useful working set for each model decision.

What’s Actually New?

Several parts of this practice have familiar relatives. The combination creates a different engineering boundary.

The model becomes a consumer of a designed working set

Traditional software also consumes configuration, data, and state. The difference is that a model can interpret the combined natural-language and structured input semantically and use that interpretation to choose what happens next.

The system must therefore design not only the values it provides, but also their framing, order, scope, provenance, and relationship to other values.

Relevance becomes an operating concern

In a deterministic query, a missing row, a wrong filter, or a malformed parameter can often be detected through explicit checks. In a model context, an item can be technically present and still fail to influence the result, or influence the result in an unintended way.

Context quality has at least four dimensions:

• Relevance: Is this useful for the current decision?
• Authority: Is this allowed to define what the system should do?
• Freshness: Is it current enough for the decision?
• Legibility: Can the model and the runtime distinguish it from surrounding material?

These dimensions are not interchangeable. A highly relevant document can be untrusted. An authoritative policy can be stale. Fresh telemetry can be difficult to interpret without a schema. A useful tool result can be too large to fit into the next decision.

Context is a control surface

Context does not only provide facts. Instructions, tool descriptions, examples, retrieved content, and previous observations can influence which operation the model proposes next.

That makes context part of the control surface of the application. A retrieved document may contain an instruction that attempts to redirect the model. A tool result may include data that looks like a policy. A stale example may teach behavior the current system no longer permits.

The system must distinguish information that should be considered from instructions that should be obeyed. That distinction cannot be delegated to the model alone when the model can affect external systems.

Context becomes a lifecycle

In an agent loop, context is assembled repeatedly:

goal
  -> context
  -> model proposal
  -> tool or human observation
  -> updated context
  -> next proposal

The context is therefore not a static prompt. It is a projection that changes as the system learns, acts, summarizes, retrieves, fails, and recovers. The lifecycle needs ownership, versioning, expiration, compaction, and auditability.

Limits become part of the architecture

Context has a finite window, a cost, a latency, and a quality curve. More available space does not remove the need for selection. Research on long-context behavior has shown that relevant information can be used less reliably when it is buried among large amounts of other material. Anthropic calls the resulting degradation context rot.

The durable engineering response is not to assume that a larger window solves the problem. It is to treat context as a budget and to test how the system behaves when relevant information is moved, omitted, summarized, duplicated, or contradicted.

Where the Analogy Breaks

Historical analogies make the topic accessible, but each one fails at a different boundary.

Analogy	What it explains	Where it breaks
Configuration	Inputs can be assembled before execution	Model interpretation is probabilistic, and natural-language values can compete with one another
Working set	Only a subset of available information should be active	Tokens are not addressable memory, and attention is not deterministic lookup
Retrieval pipeline	Candidate information can be found and ranked	Context includes instructions, tools, state, identity, and observations, not only documents
Application state	The system carries information across steps	Model-facing context is a projection, not the authoritative source of truth
Compiler	A runtime can transform inputs into an execution representation	Equal context does not guarantee equal behavior, and the model is not a deterministic target language
Conversation history	Earlier turns can preserve continuity	History accumulates noise, stale assumptions, secrets, and untrusted instructions

The important break is this:

Context is not truth, memory, permission, or a complete description of the world. It is a deliberately constructed view of what a model may consider for one decision.

The application must keep authority elsewhere. The model can interpret the projection and propose a next step. Deterministic systems must still own validation, authorization, execution, persistence, and outcome reporting.

Under the Hood

A useful context architecture separates the world of possible inputs from the projection sent to the model.

1. Establish scope

Start with the task, user identity, tenant, permissions, deadline, risk level, and required outcome. The same question can require different context for different users or actions.

2. Gather candidates

Collect only from owned and observable sources: authoritative records, approved retrieval indexes, tool descriptions, current state, prior observations, and explicit user input. Keep stable identifiers for large objects so the system can load details progressively.

3. Filter and rank

Apply deterministic scope, policy, data-classification, freshness, and size filters before semantic ranking. Relevance should not override authorization. A document should not enter context merely because it matches the words in the question.

4. Annotate meaning

Preserve source, owner, timestamp, freshness, scope, confidence, and trust classification. If two sources disagree, make the disagreement legible rather than silently merging them into one fluent paragraph.

5. Allocate the budget

Reserve space for the user’s goal, required instructions, tool schemas, evidence, observations, and the expected response or next action. Do not spend the entire budget on retrieved material and leave no room for the model to reason or act.

6. Render the working set

Use stable sections, clear labels, explicit boundaries, and structured output requirements. A context item should have a reason to be present. The renderer should be versioned so a behavior change can be traced to a change in the assembled input.

7. Trace and evaluate

Record what candidates were considered, what was selected, what was omitted, which policy decisions applied, the exact model-facing context or a privacy-safe equivalent, the model proposal, tool calls, observations, and final outcome. Evaluation must test context assembly as well as the final answer.

The application should make context assembly explicit, bounded, and observable before the model proposes its next step.

This design makes an important separation visible:

authoritative systems
  -> candidate context
  -> model-facing projection
  -> model proposal
  -> deterministic validation and execution
  -> observed outcome

The projection may be incomplete. It may contain uncertainty. It may need to be rebuilt. None of those properties grant the model authority to make an unvalidated change.

A Concrete Example

Consider an incident-triage assistant asked:

Why did the checkout service’s 5xx rate increase after the last deployment, and what should we do next?

A weak implementation might place a runbook, a large log export, a deployment record, and the full conversation into one long prompt. The response may sound plausible, but nobody can tell which evidence was selected, whether the logs were in scope, or whether the recommended action is authorized.

A context-engineered implementation builds the working set in stages.

Initial context

The first model turn receives:

• the user’s goal and requested output;
• the user’s identity, team, environment, and read-only scope;
• the current service and deployment identifiers;
• a concise runbook section for elevated 5xx errors;
• a metrics summary with time range, baseline, and freshness;
• read-only tool definitions for deployment, logs, dependencies, and metrics;
• an explicit instruction that tool outputs are evidence, not policy;
• an output contract requiring hypotheses, supporting evidence, uncertainty, and next diagnostic step.

It does not receive every log line or every document that mentions checkout.

Progressive disclosure

The model proposes a read-only query for errors in the deployment window. The runtime validates the service scope, time range, query cost, and data classification before execution.

The tool returns a compact result:

• query identifier;
• time range and scope;
• error-group counts;
• representative trace identifiers;
• source and freshness;
• a pointer for retrieving full details.

The result is added to the next context. If the model needs more detail, it can request specific traces rather than forcing the entire log stream into working memory.

Decision and action boundary

The model may identify a likely regression and propose rollback or traffic mitigation. It does not execute that action merely because the proposal is coherent. A deterministic policy checks whether the service, environment, change window, and approval requirements permit the action. A human may need to approve it. The runtime records the proposal, evidence, policy decision, execution result, and final state.

The same pattern applies outside incident response. A compliance analyst, researcher, support agent, or internal knowledge assistant also needs a context projection that is relevant, scoped, attributable, and safe to act upon.

Context is a projection of a larger system state, rebuilt and evaluated as the work progresses.

What Changes Because of It?

Architecture

Context becomes a first-class application concern rather than an unexamined string concatenation step. Teams need explicit components for retrieval, selection, policy filtering, provenance, rendering, budgeting, and trace capture.

The source of truth remains in owned systems. The model-facing context is a projection with a defined lifetime and purpose. This makes it possible to rebuild the projection, compare versions, and remove information when its scope expires.

Engineering

Engineers need to test the context path independently from the model response. Useful cases include:

• required evidence omitted from the working set;
• stale or contradictory sources selected together;
• a relevant record outside the user’s scope;
• a tool result that exceeds the token budget;
• a prompt injection embedded in retrieved content;
• a summary that drops a safety-critical constraint;
• a context change that alters tool selection or stopping behavior;
• identical context rendered with a changed order or label.

Version system instructions, schemas, selectors, ranking logic, redaction rules, and rendering formats. Without that versioning, a model-behavior change becomes a mystery blamed on the model.

Product and user experience

Users need to know what the system can access, what it used, how fresh the important information is, and when a recommendation is a proposal rather than a completed action. Citations and evidence views help, but they do not replace authorization or domain validation.

The product should make missing context visible. Asking a clarifying question or requesting access can be more reliable than silently filling a gap with a guess.

Operations and economics

Context affects token cost, latency, caching, throughput, and retention. A document update, a larger tool schema, or a longer conversation can change system behavior without a code deployment.

Monitor context size, source mix, retrieval quality, selection decisions, cache behavior, truncation, model latency, tool latency, and downstream outcomes. Keep privacy and retention rules explicit because traces can contain sensitive data even when the final answer does not.

Security and governance

The context path is a trust boundary. Separate user instructions, developer instructions, retrieved content, tool output, memory, and policy decisions. Label their roles, limit their authority, and assume that external content may attempt to influence the model.

When a model can call a capability, the context should describe what the capability can do without becoming the permission to do it. Authorization belongs to the runtime and the domain system.

Failure Modes

Context overload

The system includes everything that might be relevant. Important constraints become difficult to find, costs rise, and the model follows a locally persuasive detail instead of the governing instruction.

Context omission

The system keeps the context small but drops the one policy, dependency, or exception that changes the answer. A compact context is not automatically a good context.

Stale or contradictory context

A current metric is paired with an obsolete runbook. Two sources describe different ownership or policy. A fluent model response hides the conflict unless the system preserves timestamps and provenance.

Authority collision

A document, tool result, user request, and system instruction appear in the same natural-language stream. The model cannot reliably infer which one is allowed to control behavior unless the application makes the hierarchy explicit and enforces it outside the model.

Indirect prompt injection

An attacker places instructions in a document, web page, issue, email, or tool result that later enters context. Filtering known phrases is not enough. The architecture must constrain what the manipulated model can access and do.

Context drift

The prompt template stays unchanged while tools, policies, retrieval indexes, examples, memory summaries, or source documents evolve. The system changes behavior without a single obvious code change.

Truncation and silent loss

The context exceeds a limit and the runtime removes history, tools, evidence, or instructions. If the omission is not traced, the resulting behavior looks like random model failure.

False memory

A summary or persisted note is treated as fact even though it was an earlier model inference. Memory must preserve source, confidence, time, and ownership rather than turning every previous statement into truth.

Context cost spiral

Longer histories, broad tool definitions, and repeated retrieved material consume more tokens and increase latency. The system adds more context to repair quality, then creates new quality problems because the working set is too large.

KNOW / UNDERSTAND / BUILD

KNOW

Know that a prompt is only one part of a model-facing context. Know that context includes selected instructions, data, tools, state, history, and observations. Know that more context can reduce quality and that retrieved content can be untrusted.

UNDERSTAND

Understand context assembly as an application architecture. Understand the difference between information availability, context selection, provenance, authority, and execution permission. Understand how retrieval, memory, tool design, model inference, evaluation, cost, and security interact at the context boundary.

You should be able to draw the path from authoritative systems to candidate context, model-facing projection, model proposal, deterministic validation, execution, and observed outcome.

BUILD

Build a context assembly experiment if you design AI systems, retrieval systems, agents, or production controls. The goal is not to train a model. It is to make the input path inspectable.

Use one task with a small set of sources and compare:

1. a static prompt with all available material;
2. retrieval with a fixed top-k result;
3. a bounded context assembler with scope, provenance, freshness, and progressive disclosure.

Measure answer quality, evidence use, omitted constraints, token count, latency, cost, and behavior under injected or stale content. Save the exact candidate and selected context for each run.

Recommended depth: UNDERSTAND

Build It Once

Build a narrow context envelope for a read-only workflow before introducing autonomous actions. Each context item should carry enough metadata for a reviewer to understand why it was included:

{
  "kind": "evidence",
  "source": "deployments/service-checkout",
  "scope": "production / checkout",
  "observed_at": "2026-09-12T14:00:00Z",
  "freshness": "current",
  "authority": "operational-record",
  "selection_reason": "deployment overlaps incident window",
  "token_budget": 900,
  "trust_note": "data to consider, not instructions to obey"
}

Then add a context ledger with:

• candidate sources and why they were considered;
• selected and omitted items;
• source owner, scope, and freshness;
• policy and redaction decisions;
• context-renderer version;
• model and tool definitions exposed;
• model proposal and validation result;
• tool observations and final outcome.

The ledger turns context from hidden prompt plumbing into an inspectable part of the system. It also creates material for evaluation: not only whether the answer was good, but whether the system assembled the right evidence and respected the right boundary.

Will This Term Survive?

The phrase context engineering is useful and likely to remain recognizable for a while because it names a real expansion beyond prompt wording. Its exact boundary may shift. Some teams may prefer context management, context orchestration, context design, or a term tied to a particular runtime.

The underlying practice is more durable than the label. Any system that asks a model to make decisions over changing information needs to manage a bounded working set, preserve provenance and authority, and evaluate what was made available at each step.

The phrase may fade. The responsibility will not.

Where It Fits in the Map

Context engineering sits between the information and capability layers of the AI-native application:

• Post 01, Timed Multi-Round Web Lookup: retrieval becomes one way to discover and refine the next useful context.
• Post 02, Agent and Agent Design Patterns: the agent loop rebuilds context after each proposal, tool call, observation, and stopping decision.
• Post 03, The Application Boundary Is Weakening: shared enterprise context needs meaning, authority, scope, and provenance when many consumers use it.
• Post 04, Tool Calling: tool definitions and tool results are part of context, but a description is not permission and a result is not truth.
• Post 05, Model Context Protocol: MCP can expose resources, prompts, and tools. Context engineering decides what should enter the next model-facing working set and how it should be labeled.
• Future retrieval and memory topics: retrieval quality, context rot, memory, durable execution, evaluation, and prompt injection extend the same lifecycle.

The abstraction shift is from treating the prompt as the application boundary to treating context as a governed runtime projection. That boundary is where relevance, freshness, provenance, cost, security, and model behavior meet.

Sources

• Effective context engineering for AI agents, Anthropic: context as the curated set of tokens available to an agent, including instructions, tools, history, and external data; context rot; just-in-time retrieval; compaction; and progressive disclosure.
• Writing effective tools for AI agents, Anthropic: tool descriptions, token-efficient results, clear boundaries, and the relationship between deterministic tools and nondeterministic agents.
• Introducing Contextual Retrieval, Anthropic: the effect of preserving context around retrieved chunks and the importance of retrieval quality beneath RAG systems.
• Harness engineering, OpenAI: repository maps, context scarcity, stale guidance, and the need to make agent environments legible and enforceable.
• From model to agent: Equipping the Responses API with a computer environment, OpenAI: context growth, intermediate state, tool use, execution environments, and the operational problems of longer workflows.
• Designing AI agents to resist prompt injection, OpenAI: prompt injection as manipulation through external content and the need to constrain impact through system design.
• Lost in the Middle: How Language Models Use Long Contexts: research on how language models use information placed at different positions in long contexts.