Context engineering: why it will survive the agent marketplace

The three layers — and which ones get commoditized

Every enterprise AI system lives across three layers. Until now we talked about all three as if they were the same thing, blurred together in the sales narrative. April's consolidation forces us to pull them apart.

Why the context layer isn't sold in a marketplace

Three operational reasons, not philosophical ones:

1. It's the customer's property by definition. Curated data is your data. Documented relationships are your domain knowledge. Operational instructions are your policies. A marketplace can sell templates, examples, frameworks — it can't sell what's specific to your company, because it doesn't have it. If someone offers you an agent "already trained on your industry's context," then either (a) they're selling a generic you'll have to customize anyway, or (b) they're selling you a competitor's context, harvested as data on a previous engagement — which is a legal problem before it's a technical one.

2. It isn't standardizable. The difference between two companies selling insurance is exactly what each one considers a "premium customer": the threshold, the criteria, the exceptions, the retention policies. That definition isn't in any industry handbook. It's in how your company actually operates. A pre-built agent with standardized context can cover the generic 20% — the 80% that decides your profitability is still yours. And building that 80% is engineering, not configuration.

3. It requires specific engineering discipline. This is where context engineering ≠ prompt engineering, nor data engineering, nor MLOps. There are concrete technical decisions — what information is retained, when it expires, what gets pulled in on demand, what is deliberately left out, what gets invalidated when the business changes — that have direct operational impact (latency, cloud cost) and business impact (which automated decisions are possible). Those decisions are an engineering discipline of their own, with its own anti-patterns, its own cost of error, its own learning curve.

We call that discipline context engineering. We develop it as a concept in another piece; here we take on its architecture. What follows is how it's designed.

The 5 layers of context engineering

When someone says "context engineering," they're usually thinking about RAG. RAG is one technique within layer 4. Context engineering, seen as architecture, has five layers — and designing all five explicitly is what separates an agent that works in production from one that stalls in pilot.

Layer 1: curated instructions

These are the operational policies encoded in natural language — the equivalent of the employee handbook. What it does, what it doesn't do, what tone it uses, which cases it escalates, which decisions it never makes without a human. It is not the big system prompt. It's a curated body of content, versioned, with a maintenance owner, with a change process.

The operational difference: when legal changes a data-retention policy, you know exactly which document in the curated body to update and which tests to pass before redeploy. Without this, policies live in the system prompt as a single, unreviewable block, and every change breaks three things nobody had tested.

Layer 2: working memory

This is the context of the current session — what the agent remembers within a conversation. Bounded by turns or by minutes, not by months. It's the layer that decides when the agent "forgets" what you just told it four messages ago.

Badly designed, this layer either blows up the bill (the whole history on every call) or loses critical information (aggressive summarization that drops the datum that matters). Well designed, it has an explicit policy for what's kept verbatim, what's summarized, what's discarded — and that policy is reviewable.

Layer 3: episodic memory

This is the context across sessions — what the agent remembers from past interactions with the same customer, the same project, the same dossier. Days, weeks, months.

This is where most companies get it wrong: either they don't implement it (every conversation starts from scratch, frustrating the user) or they implement it without TTL or invalidation (the agent keeps using six-month-old, outdated information). The retention and invalidation policy is the heart of this layer.

Layer 4: retrieval policy

This is the policy of "what gets pulled into context when it's needed" — over which corpus, with what relevance criterion, with what limit. This is where RAG lives, but RAG is an implementation, not a policy.

The policy decides real questions: do you pull the most recent document, the most semantically relevant one, or both with a weighting? Do you prioritize a signed document over a draft? What do you do when two sources contradict each other? Without an explicit policy, RAG works for the first three months and starts failing once the corpus grows and the update cadence shifts.

Layer 5: invalidation and expiration

This is the policy for when context stops being valid. The most forgotten layer, and the one that causes the most production failures.

A customer policy changed in March: is the agent still quoting the December version? A product was pulled from the catalog: is the agent still offering it? An employee left the company: is the agent still naming them as a contact?

This layer requires explicit TTL by information type, an on-demand (push) invalidation mechanism when something changes, and auditing of what's being served in production. Without this layer, all the rest of the work degrades over time, silently.

The cost-per-request contract

The five layers above are connected by one decision that determines whether your cloud bill grows linearly with usage or explodes: which layer pays for what, with what limit per request.

A typical request to a well-designed agent activates: a slice of curated instructions (layer 1), the relevant extract of working memory (layer 2), a bounded slice of episodic memory (layer 3), one or two retrieved documents (layer 4), all under TTL policies (layer 5).

The math that scares the CFO: if each layer can consume 10,000 tokens, a single request can easily reach 50,000 tokens — and at 50,000 requests a day that's 2.5 billion tokens per day. Multiplied by the model's price, those are figures that show up at the Q3 committee with an exclamation mark.

The cost contract forces you to decide, before you implement: how much each layer may consume per request, when you'd rather truncate than pull in more, when you'd rather drop to a cheaper model in exchange for more context. These decisions are made when you design the architecture — they're not discovered when the bill arrives. It's the angle we develop in the real cost of AI in production: the gap between pilot and scale isn't linear.

Three anti-patterns we see over and over

How to introduce it into a brownfield

You don't have to throw anything away. A four-week migration plan, executable without stopping production.

By week four: an agent with documented architecture, a predictable bill, and a real ability to iterate. It's not the final destination — it's the point you can build from.

What the marketplace can't buy

When the executive committee receives the integrator's proposal with the catalog of 1,000+ pre-built agents, the right question isn't "does this agent cover our case?" It's: "if we buy this agent, who is going to build the five layers of context on top of our data? With what methodology? Who owns the context layer in year 3?"

If the answers are "the integrator, their methodology, they own it," what you're buying isn't an agent. It's a dependency.

What the marketplace sells — accessible cognitive models, standardized control planes, pre-built agents — is valuable and cheap. What the marketplace can't sell is your company-specific context, designed with architectural discipline. And that's 80% of the work and 100% of the differentiation.

If your next AI RFP helps you tell the one from the other, we've already published the next step: Context engineering: 7 questions for your AI RFP — the buyer's brief that applies this criterion at the evaluation table.