Methodology
·
4 MIN
Prompt engineering vs context engineering: not a rebrand, a change in what you optimise
Prompt engineering words one instruction. Context engineering designs the whole payload the model sees, under a token budget.
LOCATION
Worldwide
SERIES
Best Practices
AUTHOR
Sayan Sinha
PUBLISHED
Context engineering is not a rebrand of prompt engineering. It is a change in the object you optimise. Prompt engineering tunes a string: the wording of a single instruction. Context engineering designs a system: the whole token payload the model reads at inference, assembled from the system prompt, retrieved documents, tool definitions, memory, and conversation history, under a finite budget. The shift happened for a concrete reason, not fashion. Production work moved from single chat turns to agents that assemble context dynamically over many turns, and the empirical evidence killed the assumption that a bigger context window fixes everything.
01.
The actual difference, in one line each
Prompt engineering is wording one instruction well. Context engineering is deciding what the model sees at all. The term was popularised in June 2025 by Shopify's Tobi Lutke and amplified by Andrej Karpathy, who described it as the art of filling the context window with just the right information for the next step. The cleanest distinction comes from Philipp Schmid: context is everything the model sees before it generates a response, and that is a system, not a string.
The two are not rivals; prompt engineering is a subset. When you write one good system prompt, that is prompt engineering. When you decide which three documents to retrieve, which tools to expose, how much history to keep, what to summarise away, and what output schema to demand, all on a token budget, that is context engineering. Anthropic's own guidance frames it as managing the entire context state across turns, and its sharpest line is the one worth keeping: context is a finite resource with diminishing marginal returns.
02.
Why the field shifted, and it was not fashion
The reason context engineering became a named discipline is that the easy assumption broke under measurement. The assumption was that long-context models let you stuff the window and stop thinking. Chroma's Context Rot study tested 18 frontier models in July 2025 and found that every one degrades as input grows, often in non-uniform ways: the model does not handle the ten-thousandth token as reliably as the hundredth. The older lost-in-the-middle finding pointed the same way.
Two forces made the payload, not the prompt, the thing to engineer. First, agents, tool use, retrieval, and memory mean the context is assembled across many turns by a system, not hand-written once. Second, the economics: in production at Manus, the input-to-output token ratio runs around 100 to 1, and reusing the key-value cache drives a large cost difference, so what you put in the window is a cost decision as much as a quality one. More context is not better; budgeted, relevant context is. This is the empirical backbone under our earlier walk-through of context engineering and why it matters.
03.
What context engineering is actually made of
Stripped of the label, context engineering is a set of testable practices, not prompt-whispering. The named techniques recur across Anthropic, LangChain, and the Manus production write-up:
Retrieval. Pull the few relevant documents at the moment they are needed, rather than pasting everything in. This is the discipline behind retrieval-augmented generation.
Compaction and summarisation. Compress old turns into a running summary so the budget is spent on what is live, not on transcript.
Memory and note-taking. Offload state to external notes or files the agent can read back, instead of carrying it in the window.
Tool curation. Keep three to five core tools loaded and pull the rest just in time. Loading every tool dilutes the signal and breaks the cache.
Structured outputs. Demand a schema so the model spends tokens on the answer, not on formatting prose.
Isolation. Partition work across sub-agents so each one sees only the context it needs.
LangChain frames the same set as write, select, compress, and isolate. The point is that each of these is measurable: you can A/B a retriever, a compaction threshold, or a tool loadout, which is exactly what makes this engineering rather than phrasing.
04.
Is it just a rebrand? The honest answer
Partly, and that is fine. Yes, good engineers were already curating what the model sees; the value of the name is that it points the optimisation at the payload and the system, not the sentence, which is where reliability and cost actually live. The live debate is more useful than the terminology argument. In June 2025, Cognition argued against multi-agent systems, on the grounds that sharing context cleanly between agents is hard, and recommended keeping work single-agent and sharing full traces. The same week, Anthropic described a multi-agent research system that depends on disciplined context isolation. Same discipline, opposite architectural conclusion.
For a team building with LLMs, the takeaways are plain. Budget tokens the way you budget compute, because more is not free and not always better. Treat the work as plumbing (retrieval quality, compaction, memory, tool curation, structured outputs), not as wording. And choose your architecture by how reliably you can share context, rather than by which approach sounds more advanced. The name will keep mutating, some are already calling the next layer harness engineering, but the object is stable: the system that decides what the model gets to see.
