Context Engineering AI: How I Run It in Production

Context engineering is the discipline of deciding what goes into an AI model's context window, when it loads, and what it costs to keep it there. Prompt engineering is how you word one request. Context engineering is the whole system around it: retrieval, memory, caching and isolation. I run it in production across a 40-agent fleet.

Not as a theory. As plumbing.

Every one of my agents has a standing rule: before it answers anything substantive about my projects, my SOPs, my past decisions or the state of the fleet, it queries a semantic brain of roughly 850,000 vectors first. Then it has to cite the source and scope it found. And it's told, in writing, not to invent fleet facts from whatever scraps happen to be lying around locally.

That one rule is context engineering. A retrieval layer, a citation requirement and a staleness guard, all specified. Let me break down how the whole thing fits together.

What are the five layers of context engineering?

There's no official five-layer standard for context engineering, so be careful with any post that presents one as settled. The five layers I actually run are: standing instructions, on-demand skills, retrieval, memory, and caching with isolation. Each one controls a different question: what's always loaded, what loads when needed, what gets fetched, what persists, and what gets reused.

Here's how each layer works in my stack:

1. Standing instructions. A small set of rules loads every session. They are short on purpose, because everything in them costs context on every single turn.
2. On-demand skills. Skills use progressive disclosure. Only a name and a short description sit in context by default, reported at roughly 50 to 100 tokens per skill. The full instructions load when the skill activates. Reference files and scripts load only if the instructions reach for them. That's how a runtime can carry over a thousand installed skills without drowning.
3. Retrieval. The Master Brain query. The agent pulls only the chunks relevant to the question, not the whole library.
4. Memory. Every agent has its own memory file, read at session start, plus a memory CLI for durable writes. There's one canonical write path, and the legacy store is marked read-only so nobody writes to the wrong place.
5. Caching and isolation. Prompt caching makes the stable parts of context cheap to resend. Subagents run in their own context window, so their file reads and tool output never land in the parent's window.

Five questions, five layers. You can name them differently. What matters is that every token in the window got there on purpose.

Context engineering vs prompt engineering, stated plainly

Prompt engineering is writing a better request. Context engineering is building the system that decides what the model already knows when that request arrives.

A great prompt with the wrong context gives you a confident wrong answer. A plain prompt with the right context usually gives you the right one.

Here's the difference in my world. Prompt engineering is telling an agent "write a GMB post for this client." Context engineering is making sure that when it reads that line, the client's brand voice, their service area, their last ten posts and my GMB SOP are already sitting in the window, and nothing else is competing for space.

The second one is where the leverage is. You write the prompt once. The context system runs on every single request.

It also decides which assistant wins a given job. A model with a huge context window isn't automatically better if you fill that window with noise. That's part of how that shapes which assistant wins in my own routing.

How does Claude Code implement context engineering?

Claude Code implements context engineering through a few built-in mechanisms: skills that load in layers through progressive disclosure and subagents that each run in their own context window, with prompt caching working underneath at the API layer. The rest is on you: what you put in your standing instructions, how lean you keep each session, and how you break the work up.

The built-in pieces:

• Skills with progressive disclosure. Name and description always loaded, the body on activation, reference files on demand. The platform handles the promotion between layers, not the skill author.
• Subagents with isolated context. A subagent gets its own context window, its own system prompt, its own tool access and its own permissions. Definitions live as Markdown files with YAML frontmatter in .claude/agents/ for a project or ~/.claude/agents/ for your user. Fan a job out to five subagents and the parent only sees their conclusions, not their file dumps.
• Prompt caching underneath. At the API layer, stable prefixes can be cached so you aren't paying full price to resend them every turn.

The part on you is where most people lose. I keep a note from my own Claude Code dev work that says it better than I could now: "Code is the best context." And right under it: "Context engineering: Keep context window lean. Break features into small PRs. Plan first."

Three rules. Keep it lean. Keep changes small. Plan before you build. Every one of them is about protecting the window.

What are the best context engineering platforms?

There's no single best context engineering platform, because context engineering is a stack of parts, not one product. The real answer is the combination that covers retrieval, memory and caching for your setup. Mine is Hindsight for agent memory, the Master Brain for retrieval, and prompt caching at the model layer.

I can tell you what I tried and what I kept, which is more useful than a ranked list.

• Hindsight is my agent memory layer. The locked decision in my own notes reads: "Stack: Hindsight (self-host $0 + Cloud backup) + Master Brain + your own graph viz." Same note: "Hindsight Cloud confirmed cheap (~$2-3 full)."
• Mem0 was part of the fleet's memory inventory at one point. One of my research agents recorded that "The agent memory systems include Mem0 and Hindsight."
• Remembra was evaluated and rejected. My note says so in one line.

The design goal behind all of it, also from that note: every agent "remembers their own work, injected automatically." That's the bar. If a platform doesn't get the right memory into the window without a human pasting it in, it's not doing context engineering for you.

If you want the full memory picture, I go deeper on the memory side of context engineering, and on the Master Brain layer I run this on.

Retrieval, memory and caching as one system

Here's the thing most explainers miss. Retrieval, memory and caching aren't three separate topics. They are one system with three jobs.

Retrieval decides what gets pulled in for this question.

Memory decides what survives from one session to the next, so the agent doesn't start cold. My fleet persists session notes and a per-agent memory file on every wrap. That's what makes what survives a session restart something I can count on instead of hope for.

Caching decides what you don't pay for twice. The mechanics my team tracks are specific: a 1-hour cache TTL option exists at 2x the write cost, there are per-model token floors below which a prompt won't cache (512 tokens for Fable/Mythos 5, 1,024 for Opus 4.8/Sonnet 5, 4,096 for Haiku 4.5), and we verify cache hits through the cache_read_input_tokens field in the usage response instead of assuming they happened. That's the caching half of the same problem.

Why treat them as one? Because they trade off against each other, you know. Retrieve too much and you blow past what caching can save. Cache a prefix that changes every session and you pay the write cost for nothing. Store memory nobody retrieves and it's dead weight. Tune one layer without the others and you just move the cost somewhere else.

And there's a rate-limit angle too. On Claude plans, every prompt, tool call, file read and thinking block draws from the same allowance. A session that reads 40 files to orient itself has spent real allowance before it writes a line. Context discipline isn't only cheaper. It keeps you working longer.

How can I learn context engineering?

You learn context engineering by building it, not by reading definitions. Start with one agent and one real task, then add the layers one at a time: trim the standing instructions, move rarely used knowledge into on-demand skills, add retrieval, add memory, then add caching and measure whether it's hitting.

The order I'd give a new operator:

1. Audit what's always loaded. Everything in your standing instructions costs you on every turn. Cut it hard.
2. Move knowledge into skills. Anything you don't need every session belongs behind progressive disclosure.
3. Add retrieval with a citation rule. Make the agent say where an answer came from. You'll catch bad context fast.
4. Give each agent its own memory file. Read at start, written at wrap.
5. Turn on caching and verify it. Check cache_read_input_tokens. If the number is zero, your cache isn't working, no matter what the docs promised.
6. Use subagents for wide reads. Let them read the 40 files. Keep only their conclusions.

Do those six on one real workflow and you'll understand context engineering better than any definition can teach it. The payoff you're building toward is simple: a fresh session that picks up where the last one ended, with no pasting and no re-explaining. When that works, it's honestly the best feeling in this whole stack. That's the whole game.