Prompt engineering is designing the input that controls how a model behaves. Context engineering is deciding what the model can see at all — the instructions, the retrieved facts, the conversation history and the tool definitions that together fill the context window. The second discipline absorbed the first because that is where the failures moved.
Why the emphasis shifted
By mid-2025 experienced teams had stopped getting large returns from rewording prompts. The recurring problem was different: feeding an agent the right files, the right tool definitions, the right slice of history and the right retrieved facts on every turn, without the context window collapsing under its own weight.
That is not a writing problem. It is a systems problem — retrieval, ranking, compression, eviction — and it responds to engineering rather than to phrasing.
The four pillars
- Instructions — system prompts and behavioural framing. The part that most resembles classic prompt engineering, and the smallest lever of the four.
- Retrieval — RAG and grounded search: what external facts get pulled in, and how they are ranked.
- Memory — short-term conversation state and long-term persistent state, including which decisions were already made and why.
- Tools — which capabilities are visible, and how their descriptions are worded, since a tool description is itself context.
The failure modes are different
Prompt-engineering failures look like tone problems or ignored instructions. Context-engineering failures look like this:
- Lost in the middle — the relevant fact was in context but positioned where the model underweights it.
- Context dilution — twenty retrieved chunks where three were relevant, so the signal is buried.
- Stale memory — a decision reversed three weeks ago is still being cited as current.
- Tool confusion — two tools with overlapping descriptions, so selection becomes a coin flip.
The diagnostic that saves the most time
When an agent gives a wrong answer, log and read the entire context window that produced it before changing anything. In most cases the required fact was absent, was present but buried, or was contradicted by something stale. All three are retrieval and memory problems, and none of them are fixed by rewriting the system prompt.
What good context engineering looks like
- Retrieve fewer, better chunks. Rerank, and measure whether reranking changed the answer.
- Put the most decision-relevant material at the start or end of the window, not the middle.
- Give long-lived decisions a durable home so they can be retrieved as facts rather than recalled from a chat log.
- Budget the window explicitly — assign shares to instructions, retrieval and history, and compress the rest.
- Version tool descriptions and re-run evals when they change, because they are behaviour.
Prompt engineering did not become useless
It became a smaller, more specific job. Output format, refusal behaviour and the framing of the task still respond to careful wording. The mistake is spending a week on phrasing when the model never received the fact it needed.
Frequently Asked Questions
Is context engineering just RAG with a new name?
No. Retrieval is one of four pillars. Memory, tool definitions and instruction framing are equally part of what lands in the window, and many failures come from those rather than from retrieval.
Does a bigger context window solve this?
It reduces truncation pressure and increases dilution. More room to put irrelevant material in front of the model is not obviously an improvement — selection still matters.
Where should this live in a team?
With whoever owns the retrieval and memory layers, which usually means backend or data engineering rather than a dedicated prompt role.
References
About Jishu Labs
Jishu Labs is a software development company founded in 2016. We build custom software, AI/ML systems, and full-stack web and mobile applications for clients, and we make eight AI tools for software teams.