Context Engineering Is Runtime Engineering

A language model’s weights define capabilities and tendencies, but the weights do not uniquely determine what an AI application does in a particular moment. The application assembles instructions, retrieved documents, memories, tool definitions, permissions, conversation history, summaries, environment state, and intermediate outputs. The model then acts from that assembled state.

Context engineering is the deliberate design of the information and constraints available to an AI system at runtime, including how that state is selected, ordered, transformed, validated, and updated.

Context engineering vs. prompt engineering

Context engineering is broader than prompt engineering because “prompt” is too narrow for many production systems. A system prompt may be one element, but a long-running agent also inherits repository instructions, user corrections, tool schemas, policy rules, retrieved evidence, state from earlier actions, and a compressed account of what happened before. Those elements participate in the execution path. Practitioners increasingly call this surrounding machinery the agent’s harness: the tools, persistent instruction files, permissions, and feedback loops around the model, as distinct from the model itself. Prompt engineering tunes one artifact; context engineering designs the whole assembled state.

This is not a niche framing. OpenAI’s write-up of its in-house data agent describes six explicit layers of context — table usage, human annotations, Codex-derived enrichment, institutional knowledge, memory, and live runtime context. Separately, its harness-engineering work treats repository knowledge, instruction files, feedback, and environmental information as part of the agent harness rather than as optional prose around the model.

The practical implication is direct: changing the model is only one way to change the system. Changing which evidence is retrieved, which instruction wins a conflict, which memory is treated as current, or which tool description is visible can change the outcome without altering a single model parameter.

A large context window is a capacity limit. Context engineering is a state-design problem.

The distinction becomes clearer in a software task. An agent may have access to the complete repository, but the current decision may depend on five narrower facts: the user’s requested behavior, the relevant service boundary, the current test failure, a documented architectural constraint, and the changes already attempted. Adding the entire repository to the prompt does not guarantee that those five facts will control the next action. More text can compete with the task, duplicate rules, introduce obsolete documentation, and make important constraints difficult to distinguish from background material.

OpenAI reports exactly this failure with a single giant AGENTS.md instruction file: “a giant instruction file crowds out the task, the code, and the relevant docs” — when everything is marked important, nothing is. The resulting problem was not insufficient token capacity. It was weak information architecture.

A useful runtime context therefore needs at least four properties:

Relevance. The state must contain what the current decision needs.

Authority. The system must distinguish binding instructions from examples, suggestions, retrieved claims, and untrusted input.

Freshness. The system must know when stored context is stale and when live inspection is required.

Continuity. The system must preserve the dependencies, decisions, corrections, and unfinished obligations that connect one step to the next.

These properties cannot be reduced to semantic similarity. A retrieved passage may be topically relevant while missing the decision or dependency that makes the passage actionable.

Context failures often look like model failures because the model is the component that produces the visible response. The causal problem may have occurred earlier.

A system may retrieve an outdated policy because the outdated document is semantically similar to the query. A memory layer may preserve that a customer requested a refund while dropping the fact that the request was denied pending identity verification. A summary may accurately list all major topics while removing a prohibition that matters only at the next tool call. A tool description may be syntactically valid but too vague to distinguish one action from another.

Research has started naming these mechanisms. A 2026 study of agent memory found that organizing memory by similarity “fragments decision trajectories and mixes valid and erroneous traces.” Work from Stanford, SambaNova, and UC Berkeley names context collapse: the detail that erodes when context is repeatedly rewritten into concise summaries.

Anthropic’s work on long-running agents makes a related distinction between compaction — compressing the context in place — and a full context reset. Compaction preserves some continuity but can carry accumulated confusion forward. A reset creates a clean context but requires a sufficiently complete handoff artifact. Neither mechanism is inherently safe: each changes what the next agent or generation step can know.

The engineering question is therefore not simply, “Did the system retain context?” The stronger question is: did the system preserve the state required to make the next decision correctly? That question shifts attention from token retention to state integrity.

Hermes Labs defines context integrity as the degree to which relevant meaning, qualifiers, and constraints stay intact as context is retrieved, summarized, stored, transformed, and reused. The term does not mean that context must remain verbatim at all times. It means that transformations must preserve what later decisions depend on.

Consider an illustrative procurement agent:

A policy states that purchases above a threshold require two approvals. The agent summarizes the policy as “large purchases require management approval.” The summary enters long-term memory. A later transaction exceeds the threshold. The agent obtains one manager’s approval and proceeds.

The summary is not obviously nonsensical. It preserves the general topic and an important requirement. It fails because it removes the cardinality of the requirement: two approvals. A conventional quality check might label the summary relevant and fluent. A context-integrity check asks whether the summary preserved the condition that controls the downstream action.

The practical takeaway: every place context gets transformed needs a check that the decisive part survived. Concretely —

• Retrieval should keep where a piece of evidence came from and its status.
• Summaries should keep qualifiers, negations, quantities, and open questions.
• Memory should keep corrections, not just the latest version.
• Handoffs should keep what was done, what failed, and what remains.
• Instruction systems should make conflicts and precedence explicit instead of leaving the model to improvise a hierarchy.

Figure 1, at the top of this page, marks where these boundaries sit in the runtime stack.

A production team can treat context engineering as a pipeline with five explicit stages.

Stage 1 — Acquire. Inventory available instructions, evidence, memory, user input, tool state, and environmental data. Record provenance — where each item came from — and timestamps where they affect trust or freshness.

Stage 2 — Select. Choose the material relevant to the present decision. Selection should consider task dependency and authority, not only semantic similarity.

Stage 3 — Structure. Order the context so that binding constraints, current state, evidence, and supporting detail are distinguishable. Avoid presenting every item as equivalent prose.

Stage 4 — Validate. Check for conflicts, missing dependencies, stale sources, ambiguous tool descriptions, dropped null results, and transformations that altered decisive meaning. Static instruction analysis, schema checks, retrieval inspection, and task-specific evaluations operate at different points in this stage.

Stage 5 — Update. Write the outcome back to memory or state without silently overwriting correction history, unresolved uncertainty, or the evidence supporting the decision.

The five-stage context pipeline does not require a large platform. A small application may implement it with structured records and a few deterministic checks. A complex autonomous agent may need context stores, state machines, evaluators, and forensic traces. The important move is to stop treating the prompt presented to the model as an unexplained final artifact. The context should be a constructed runtime object whose sources and transformations can be inspected.

Hermes tools address different parts of this pipeline. LintLang, a static linter for agent instructions, checks the instruction text before the model runs. Fidelis, a memory layer, stores evidence verbatim so retrieval returns exactly what was stored. Hermeneutic mines the corrections users make to find where a system repeatedly misreads them, and Agent Gorgon enforces runtime rules deterministically and keeps the forensic record. These tools are examples of boundary-specific controls, not proof that the entire runtime is reliable.

Context engineering cannot make a probabilistic model infallible. Correct context can still produce a bad inference. A complete state record can still be misunderstood. A deterministic linter can detect a missing termination condition but cannot prove that the agent will terminate correctly in every environment.

Context engineering also cannot replace domain review. A system can preserve a medical statement verbatim while the statement itself is clinically wrong. Fidelity and truth are related but different properties.

The purpose of context engineering is narrower and more useful: make the runtime conditions of AI behavior deliberate, inspectable, and testable. The working test is whether your team can answer, for any given step:

• Which instructions were active, and which evidence was retrieved?
• What had been summarized or transformed along the way?
• Which corrections were still binding?
• Which state did the next step inherit, and what was unavailable?

When those questions cannot be answered, the application does not merely have a prompt problem. It has an unengineered runtime.