What Context Engineering Actually Means

The industry has made real progress on context. Retrieval-augmented generation pulls in external knowledge. Memory systems accumulate conversation history across sessions. Context repositories version and manage reusable prompts. Caching reduces redundant computation. Governance frameworks control what gets written to memory and when.

These are meaningful advances. But they're built on a narrow assumption about what context engineering is for.

The Chat Context Model

Most context engineering today is designed around three entities: messages, sessions, and users.

Messages belong to sessions. Sessions belong to users. The relationships are simple. Temporal ordering is linear—one message follows another. The context problem reduces to: which messages should we include in the prompt?

This is the mental model behind most of the tooling, most of the tutorials, most of the benchmarks. It works well for chatbots, copilots, support agents, writing assistants. The stakes are low. If context is slightly stale or incomplete, the response is slightly worse. Retry, rephrase, try again.

The Enterprise Context Model

Enterprise systems don't look like this.

A single decision might touch: customers, accounts, and their organizational hierarchies. Orders, transactions, and line items. Products, inventory levels, and pricing rules. Policies, permissions, and compliance constraints. Workflows, approval chains, and state machines. Derived features—risk scores, aggregates, embeddings—computed from raw data across these entities.

The relationships are complex: hierarchical, many-to-many, temporal, conditional. A customer's eligibility for an action might depend on their account status, their organization's policy tier, their transaction history, the current inventory, and a fraud score derived from behavioral signals.

And critically: this context changes independently of any conversation. An agent making a decision at 2:47pm may be acting on state that was invalidated at 2:46pm—by another agent, a policy update, an external event, a downstream system. The prompt doesn't know. The retrieval pipeline doesn't know.

Chat context is a log. Enterprise context is a domain model.

Three Kinds of Memory

Not all context is the same. There are three distinct kinds of memory, each with different characteristics and different requirements.

Episodic memory is the record of what happened. Events, logs, messages, observations. It's append-only—you don't change the past, you add to it. This is what chat context engineering primarily deals with: which past messages to include.

Semantic memory is the interpretation of what happened. Entity resolution, extracted relationships, classifications, inferred meaning. It evolves as understanding improves—the same raw event might be reinterpreted as models get better or definitions change.

State memory is what's operative now. Current balances, statuses, permissions, thresholds. It's mutable by design—state changes as conditions change. And it must be authoritative: when an agent evaluates a decision, state memory is the source of truth for what's currently valid.

Chat context engineering is mostly episodic. Retrieve the relevant messages. Maybe summarize them. Maybe store some user preferences.

Enterprise context engineering requires all three kinds—and requires that state memory be consistent, current, and coherent at the moment a decision is made. This is a different problem than retrieval. It's a problem of memory architecture.

The Broader View

Context engineering, properly understood, is not about assembling better prompts. It's the discipline of organizing memory so that agents can make coherent decisions.

This means designing the structure of memory: what's episodic, what's semantic, what's state. It means defining the contracts: what's append-only, what can be revised, what must be authoritative. It means ensuring coherence: when an agent acts, it sees a consistent representation of reality, not a patchwork of stale reads from independent systems.

For chat systems, the simpler framing is sufficient. For enterprise systems—where agents act concurrently, state is distributed, and decisions have real consequences—the broader framing is necessary.

The formal treatment of this problem is called Decision Coherence: the requirement that interacting decisions be evaluated against a coherent representation of reality at the moment they're made. The system architecture that satisfies this requirement is a Context Lake.

The paper is here: Context Lake: A System Class Defined by Decision Coherence