Context engineering definition

Context engineering is the work of curating what a model sees on every turn, from system instructions and tool definitions to retrieved documents and runtime state. It is a systems discipline, not a writing one. The output is a pipeline that assembles context per request. Sanity Context serves that pipeline through a read-only MCP endpoint, so an agent can query the live dataset with GROQ or read a pre-built knowledge base rather than depend on a stale copy of your content.

What is the difference between context engineering and prompt engineering?

Prompt engineering is writing and organizing the instructions you hand a model. Context engineering is managing the whole context state across a run: instructions, tool definitions, external data, retrieved documents, and message history, decided fresh at each turn. Anthropic, in its September 29, 2025 engineering post, calls context engineering "the natural progression of prompt engineering," driven by agents that now operate over many turns and longer time horizons rather than a single question and answer.

The practical difference is that prompt engineering is a discrete authoring act. Context engineering is a loop. A prompt is a document you write once and revise occasionally. Context is assembled by code every time the model is called, which means it has tests, failure modes, latency, and cost.

Split the two by owner, not by prestige. Writing what an agent is, how it speaks, and what it must never promise is an authoring job that a brand, support, or compliance person can do well. Orchestrating what the model knows at each turn is programming. Teams that conflate them usually end up with engineers writing brand voice and writers filing pull requests.

What goes into a model's context?

Context engineering usually deals with four kinds of information, and they have different lifetimes and different owners.

Static instructions are what the agent is, what it must never say, its tone, its scope, and when it escalates to a human. These change per release and belong to product, brand, and compliance. Per-turn runtime state is who the user is, what page they are on, what is in their cart, and what plan they are on. It lasts a single turn and belongs to the application. In our experience, this is the layer teams underbuild: an agent is not personalized out of the box, and it only knows who it is talking to if you inject that state every turn.

Retrieved content is catalogs, documentation, policies, and knowledge bases. It is relatively stable and belongs to the content team. This is what most people assume "context" means, and it is one of four things, not the whole job. Agent-authored notes are the summaries and memory an agent writes for its own future self when a task runs longer than one window.

Models do not have context. They have a context window. Filling it well is engineering work.

Is context engineering just RAG?

No. Retrieval is one input to context engineering, not the whole job. RAG, or retrieval-augmented generation, is the pattern of fetching relevant documents at query time and putting them in the prompt so the model answers from them instead of from memory. That covers the retrieved-content layer and says nothing about static instructions, runtime state, or agent memory.

Good retrieval is broader than vector search. Embeddings, which turn text into numeric vectors so you can rank passages by meaning, are one ingredient in a hybrid strategy that includes filters, structured queries, and metadata. "We have embeddings" is not a retrieval strategy.

Sanity's retrieval modes make the split concrete. GROQ mode queries the dataset at request time, which is exact across hundreds of thousands of records with no build step and nothing to keep in sync (it requires a deployed schema, Studio v5.1.0 or later). Knowledge Base mode serves an index built ahead of time, for when the hard part is locating an answer spread across a spec, a compliance memo, and a support article. The rule of thumb is GROQ mode for tabular data and knowledge bases for knowledge. One technical detail worth remembering: in GROQ, text::semanticSimilarity() is only valid inside score(), because semantic search ranks, it does not filter. Narrow the candidate set with a filter first, then rank what is left.

Why not just use a bigger context window?

Because context engineering is a question of attention, not capacity. Anthropic's September 2025 guidance frames context as "a finite resource with diminishing marginal returns" and describes an attention budget that every added token depletes. The architectural reason is that transformer attention creates n squared pairwise relationships for n tokens, so precision gets stretched thinner as the input grows. Anthropic describes the result as a performance gradient, not a hard cliff.

There is independent evidence for the effect. Chroma's "context rot" research, published July 14, 2025, benchmarked 18 models including GPT-4.1, Claude, Gemini, and Qwen, and found that performance degrades non-uniformly as input length grows, even when the answer is present in the context and the window is far from full.

So a million-token window does not mean you should fill it. Overstuffed context invites the model to lose track of what it is doing, and it is slower and more expensive per call. Context engineering is subtractive as often as it is additive.

How is context engineering different from fine-tuning?

Fine-tuning changes a model's weights by training it further on your data. Context engineering changes what the model is shown at inference time, leaving the weights alone. The operational difference matters more than the technical one: a fine-tune is a training run you repeat, while context can be updated the moment the underlying content changes.

That is why context engineering is where governance often lives. If your returns policy changes, you want the agent to reflect the new policy on the next request, not after the next training cycle.

Sanity is the Content Operating System for the AI era, the intelligent backend for companies building AI content operations at scale, and the capability that applies here is agentic context storage and MCP delivery. Two pieces of it are worth naming. An agent's system prompt can live in the Studio as a document with typed fields, so brand owns the voice field, support owns escalation, and compliance owns the must-not-say list, and the fields stitch together into one system prompt at runtime with version history and rollback, no deploy required. Sanity Knowledge Bases (currently in beta, enabled by an organization admin from the Apps page in Manage) build a pre-built index over sources you choose, organized as a tree of topics that follows what the sources are about rather than folder structure, and surface conflicts for you to resolve. If a help center says returns are accepted within 30 days and a product page says 45, the build raises an issue showing both claims with their sources so you can pick ground truth.

Who invented the term context engineering?

Context engineering emerged as a named practice in mid-2025 rather than being coined by any single organization. Tobi Lütke posted on June 19, 2025 that he preferred "context engineering" to "prompt engineering," and Andrej Karpathy endorsed it on June 25, 2025, describing it as "the delicate art and science of filling the context window with just the right information for the next step." Simon Willison's write-up on June 27, 2025 helped fix the phrase in circulation.

Anthropic formalized and popularized the working definition in its September 29, 2025 engineering post, describing context engineering as the set of strategies for curating and maintaining the optimal set of tokens during inference, including everything that lands in the window outside the prompt itself.

Other definitions in circulation converge on the same idea. IBM describes context engineering as deliberately designing, structuring, and optimizing the context given to a model to produce more accurate and reliable outputs, especially in agentic and multistep tasks. LangChain describes it as building dynamic systems that provide the right information and tools in the right format so a model can plausibly accomplish a task.

Last updated: September 11, 2026