Quick answer: Context engineering is the practice of curating everything that goes into a model's context window: the instructions, retrieved data, tool definitions, memory, examples, and output format. It is a broader discipline than prompt engineering, which focused mainly on wording the instruction. As applications became agents that pull in live data and call tools, the hard problem shifted from writing a clever prompt to assembling the right context at the right time.
From Prompt Engineering to Context Engineering
A couple of years ago, the craft was prompt engineering: find the phrasing that coaxes the best answer out of a model. "Act as an expert," "think step by step," "return only JSON." That skill still matters, and our prompt engineering guide covers it. But it was always a slice of a bigger picture.
The context window is everything the model sees when it generates a response. If you want to understand the container itself, we cover it in what is a context window. The prompt is just one part of that window. Also in there: the system instructions, any documents you retrieved, the tools the model can call, the conversation history, and few-shot examples.
Context engineering is the discipline of managing that whole window. The reframing matters because as soon as your application does anything real, the model's output depends far more on what information you assembled than on how you phrased the ask. A perfectly worded prompt over the wrong context still produces a wrong answer.
What Goes Into the Context Window
Think of the context window as a workspace you set up fresh for every call. A context engineer decides what belongs on the desk. The main ingredients:
| Ingredient | What it does |
|---|---|
| Instructions | The task, role, rules, and constraints |
| Retrieved data | Documents pulled in to answer this specific query |
| Tool definitions | The functions the model can call and their schemas |
| Memory | Relevant history from earlier in the session or past sessions |
| Examples | Few-shot demonstrations of the desired output |
| Output format | The exact schema or structure the answer must follow |
The skill is not stuffing all of this in. It is choosing the right subset for each call, in the right order, within a finite budget.
Why the Window Is a Budget, Not a Bucket
Context windows keep getting larger, which tempts people to dump everything in. That is a trap for two reasons.
First, cost and latency scale with how much you put in the window. More tokens means more money and more waiting on every single call.
Second, models do not attend to a huge context uniformly. Information buried in the middle of a long context is often used less reliably than information near the start or end. A window crammed with marginally relevant text can bury the one paragraph that actually answers the question. Precision beats volume.
So context engineering is fundamentally an editing problem. You are constantly deciding what to include, what to leave out, and what to summarize, so that the tokens that reach the model are the ones that matter.
Core Techniques
A few techniques do most of the work in practice.
Retrieval. Pull in only the documents relevant to the current query, usually via vector search over a RAG index. This is how you give the model your knowledge without hardcoding it.
Compression and summarization. Long conversations and large documents get summarized so the essential state fits in the budget. Instead of the full transcript, you keep a running summary plus the last few turns.
Structured formatting. Wrap retrieved chunks with their source, use clear delimiters, and label sections. A model handles a tidy, well-marked context far better than a wall of concatenated text.
Tool results as context. When a model calls a tool, the result comes back into the window. Deciding what to keep from a noisy tool output, and trimming it before the next turn, is context engineering.
Ordering. Put the most important material where the model attends best, typically the instructions up top and the critical data near the query at the end.
Here is a sketch of assembling a context window deliberately rather than by accident:
def build_context(question, history):
system = "You answer using only the provided sources. Cite each source."
# Retrieve only what is relevant to THIS question
docs = vector_search(question, top_k=5)
sources = "\n\n".join(
f"[Source: {d.url}]\n{d.text}" for d in docs
)
# Compress old history, keep recent turns verbatim
memory = summarize(history[:-4]) + "\n" + format(history[-4:])
return [
{"role": "system", "content": system},
{"role": "user", "content": f"{memory}\n\nSources:\n{sources}\n\nQuestion: {question}"},
]
Notice that the clever wording is a small part of this. Most of the work is selecting, compressing, and arranging information.
Why Retrieval and Extraction Quality Matters
Here is the point that gets underrated: context engineering is only as good as the raw material you feed it. If the documents you retrieve are polluted with navigation menus, ads, boilerplate, and broken formatting, you are spending your token budget on noise and handing the model a worse chance of getting the answer right.
This is why extraction quality sits upstream of everything. Clean, well-structured source text means your chunks are meaningful, your embeddings are accurate, and the context you assemble is dense with signal instead of junk.
Web content is the worst offender, because raw HTML is mostly not content. link.sc fetches any URL and returns clean markdown, which is exactly the shape you want going into a context window:
curl https://api.link.sc/v1/fetch \
-H "x-api-key: lsc_your_key" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/article", "format": "markdown"}'
When you feed a model clean markdown instead of scraped HTML, every downstream step (chunking, embedding, retrieval, and the final context) gets better. Good context engineering starts with good extraction.
How It Relates to RAG and Agents
Context engineering is the umbrella, and RAG and agents are two things that live under it.
RAG is a context engineering pattern: the retrieval step is how you populate the window with relevant knowledge. Everything about chunk size, ranking, and how you format retrieved text is a context decision.
Agents raise the stakes. An agent runs many model calls in a loop, calling tools and accumulating results. Each step, the context window has to be reassembled from the growing pile of history, tool outputs, and new retrievals, all within budget. Managing that state well is the difference between an agent that stays coherent over twenty steps and one that drifts. If you are building agents, our roundup of the best AI agent frameworks shows how different frameworks handle this context assembly for you.
The Bottom Line
Context engineering is the evolution of prompt engineering for a world of retrieval, tools, and agents. The job is no longer just wording the ask; it is curating the entire window so the model sees exactly the right instructions, data, and format within a finite budget. And because the model can only work with what you give it, the quality of your retrieval and extraction is where good context engineering begins.
Feed your models clean context, not scraped HTML. Fetch model-ready content from any URL with link.sc.