Context Engineering: The Whole Idea In Plain English.

Ryan “RyMac” McKinney · USMC · 15 August 2026 · 7 minute read

Context engineering is deciding what information your AI has in front of it at the moment it does a job. That is the entire concept. Everything written about it after that sentence is either implementation detail for developers, or somebody selling you a framework for a filing problem.

Why the name changed

For 2 years everybody said prompt engineering. The idea was that if you phrased the request well enough, you got a better answer.

That was true, and it stopped being the bottleneck.

Models got good enough that the phrasing stopped mattering as much as what they could see while they answered. A perfect prompt against an empty folder still gives you a confident guess.

So the field renamed itself around the thing that actually moves the result.

The 3 parts, and there are only 3

What it can see. Your instructions, the conversation so far, and any files it opened. This has a hard limit, and when it fills, older things drop out of view without warning. That is the context window.

What you choose to put there. This is the actual work. Not everything. The right things, for this job, right now.

How it finds the rest. Whatever you did not put on the desk has to be findable, or it does not exist as far as the model is concerned.

That is context engineering. A person, a desk, and a filing cabinet the person knows how to use.

What it looks like when it is done badly

You paste the same background into a new chat every morning.

It contradicts a decision you made 20 minutes ago in the same session.

You find yourself keeping a document of "things to tell the AI" that you re-paste by hand. That document is the system, and you are running it manually.

Every one of those is a filing symptom wearing a technology costume.

What it looks like when it is done

~/business/
├── CLAUDE.md          <- the map. 11 lines. always read first
├── Context.md         <- the desk. what we're doing today
└── ops/
    ├── clients/
    ├── offers/
    ├── sops/
    └── archive/

1 file that is always read first. 1 file that says what we are doing now. Folders holding the material.

The agent reads the map, the map sends it to the desk, the desk names the folder. It opens that folder and nothing else.

No orchestration platform. No vector database. No 9th agent whose job is to summarise the other 8.

Is this the same as RAG or memory?

Related, not the same, and the distinction is worth 30 seconds.

RAG is one technique for getting relevant material in front of the model automatically. It is a tool inside context engineering, not a synonym for it.

Memory is about carrying things across sessions. Useful, and it is also the thing people reach for when the real problem is that nothing was written down in the first place. More on that in the memory post.

Context engineering is the umbrella. It is the decision about what goes in front of the model. RAG and memory are 2 ways of executing that decision.

Where the method comes from

The version I run has a name. Interpretable Context Methodology, ICM. Jake Van Clief and David McDermott wrote the paper, and their argument is that your folder structure can carry the job people currently write orchestration code to do. Jake teaches it himself over at Clief Notes.

Anthropic has published on context engineering as well, and the part everybody agrees on is the part that matters: the constraint is not how smart the model is. It is what you put in front of it.

I did not invent any of this. I run it in public and show the receipts. Full breakdown of the methodology: Interpretable Context Methodology in plain English.

Do you need to learn this properly?

If you are building software other people will use, yes. Learn retrieval, chunking, evaluation, all of it.

If you are a business owner who got handed the AI, no. You need a filing system and about 20 minutes. I wrote about that here: why you probably do not need a context engineering course.