← all articles

what is context engineering?

context engineering is the discipline of deciding what a model knows before it answers.

not what you asked it. what was in the window alongside your question: the retrieved documents, the tool results, the conversation so far, the project instructions, the summary of everything that got compacted away. in a real agent your actual instruction is a rounding error next to all of it.

the term hardened during 2025 and became the default framing for building with models through 2026. here is what it means in practice, where it breaks, and what to build first.

context engineering vs prompt engineering

prompt engineering asks what words to use. context engineering asks what the model should know before it reads them.

that is the whole distinction, and it is not a rebrand. the shift happened because prompting alone stopped solving production problems once systems ran for many turns, called tools and had to hold state. a single perfect instruction cannot compensate for a window that is missing the document the answer lives in.

the context engineering vs prompt engineering framing is now standard in practitioner guides, and it is the reason job descriptions changed wording during 2026.

prompt engineeringcontext engineering
unit of workone instructionthe whole window
questionwhat words work?what should be in here at all?
scopea turna session, and across sessions
typical fixrewrite the askchange what gets retrieved
fails whenwording is ambiguousthe fact was never recorded

prompt engineering is not dead. it is a component. a bad system prompt still ruins a well assembled window, and 20 minutes spent on one is still the best value in the stack.

what actually goes in the context window?

six things compete for the same finite context window, and they are rarely budgeted deliberately.

  1. system and project instructions. how the model should behave, and what this project is.
  2. the conversation so far. including whatever compaction has already thrown away.
  3. retrieved documents. the rag layer, if there is one.
  4. tool definitions. every tool you expose costs tokens before it is ever called.
  5. tool results. frequently the largest and least controlled item on the list.
  6. the user's actual message. almost always the smallest.

most teams tune 6 and ignore 4 and 5. a server that returns 40,000 characters of raw text on every call will dominate the window regardless of how carefully the prompt was written, which is why research on agent tooling spends so much of its time on selection and compaction rather than on phrasing.

the four failure modes

they look alike from the outside and have completely different fixes.

poisoning. something wrong entered the window early and everything downstream inherits it. a stale doc, a bad tool result, a hallucination the model now treats as established. fix upstream, not with a firmer instruction.

distraction. everything relevant is present and buried. the answer was in the window and the model weighted the wrong part of it. this is the one a bigger window makes worse.

confusion. two sources disagree and nothing resolves the conflict. common when a wiki and the code contradict each other and both got retrieved.

absence. the fact was never written down anywhere retrievable. no amount of engineering fixes this one, and it is by far the most common.

ai agent memory features do not close the absence gap either. openai shipped its background memory system on june 4, 2026, anthropic reworked claude's into editable entries on july 10, 2026, and google rebranded gemini's context layer as personal intelligence in january 2026. all three store facts drawn from what you typed to them, which we compared in ai memory is everywhere in 2026.

that last category is the interesting one, because it is not a modelling problem at all.

why is absence the real bottleneck?

the record usually does not exist, and everyone treats it as a retrieval problem.

per the anthropic economic index for may 2026, searching electronic sources for information is the single most common work task in ai conversations at 4.95%, with reference searching second at 3.74%. retrieval is what people mostly do with these systems. now look at what they cannot retrieve.

request topicshare of conversations
content creation and copywriting22.72%
education and learning13.23%
software development11.51%
research and intelligence10.94%
document processing and extraction4.32%
knowledge retrieval and enterprise search3.61%
personal ai assistant2.86%
conversation and meeting intelligence0.26%

searching your own organisation's knowledge is 3.61%. anything about a meeting is 0.26%. those are not statements about demand, they are statements about supply. the decision made on a call, the constraint explained in a doc that was read once and closed, the reason the api looks like that: none of it is in any index, so no retrieval strategy can reach it.

context engineering that starts at the embedding model is starting three steps too late.

the transport layer: mcp

mcp is how the assembled context actually reaches the model at runtime.

anthropic published the model context protocol in late 2024 and by 2026 it was the default integration standard across labs and editors. a server advertises typed tools, a host connects, the model calls them mid session. it is a standard plug rather than a standard brain.

what matters for context engineering is that mcp moves the decision to runtime. instead of stuffing everything into the window up front, the model asks for what it needs when it needs it. that turns a budgeting problem into a routing problem, which is a much better problem to have. the practical setup is in how to give an ai agent context.

a build order that works

fix the sources before you tune the retrieval. in this order.

  1. write the project file. a claude.md or agents.md at the repo root. read every session, costs 20 minutes, and it is the cheapest claude code context available.
  2. audit what your tools return. measure the tokens. cut anything returning more than a screenful by default and make detail a second call.
  3. connect the systems of record. issue tracker, docs, design. these hold decisions and most now ship an mcp server.
  4. capture what has no system of record. the calls, the tabs, the terminal, the document read once and closed. this is the absence category, and it needs something that was recording at the time.
  5. only now tune retrieval. chunking, ranking, reranking, and the retrieval augmented generation stack generally. this is where teams start and it should be step 5.

step 4 is the one with no vendor. remynd covers it on a mac by capturing the focused window, running ocr locally so what you looked at becomes searchable text, and exposing that archive to claude code and codex over a local connector since august 2026. capture, ocr and storage stay on your machine by default and apps or sites can be excluded entirely, though sign in and the cloud agent do reach the network, which is set out on the security page.

the shift worth internalising

a small model with the right context beats a large model guessing, and costs a fraction as much.

that is the practical payoff of taking this seriously, and it inverts the usual instinct. when an agent gets something wrong, the reflex is to reach for a better model or a longer window. the higher yield move is almost always to ask what it did not know, and then whether that thing was ever written down anywhere at all.

usually it was not. that is a recording problem wearing a modelling problem's clothes, and it is covered further in what is an ai memory app and how to find something you saw on your screen.

download remynd for mac and close the absence gap first.

common questions

what is context engineering in simple terms? +
it is deciding what information a model receives, how that information is structured, and when it enters the context window. prompt engineering is about the words in your instruction. context engineering is about everything else in the window alongside them, which in a real agent is the overwhelming majority of the tokens.
is context engineering replacing prompt engineering? +
no, it absorbs it. a well written system prompt still matters and always will. it is now one input into a larger system that also decides what gets retrieved, what gets summarised, what gets dropped and what gets carried between sessions. the prompt is a component rather than the whole job.
does a bigger context window remove the need for context engineering? +
it makes it more important, not less. a larger window raises cost and latency on every turn and models still lose precision over long spans, so the discipline shifts from "what fits" to "what earns its place." and no window is large enough to hold a fact that was never written down anywhere.
what is the difference between context engineering and rag? +
rag is one technique inside context engineering. retrieval augmented generation embeds documents and pulls the closest chunks into the prompt. context engineering is the wider question of which sources exist at all, how they are chunked, what gets compacted, and how state survives between sessions.
what should i build first? +
the cheapest thing with the highest return is a project instruction file, a claude.md or agents.md at the repo root, because it is read every session. after that, fix your sources before you tune retrieval. most context failures are missing records rather than bad ranking.