Context Engineering, Explained From Zero

We now have many ways to feed a model information — system prompts, questions, retrieved documents, tool results, conversation history. Context engineering is the judgement layer that decides how to combine them, and it's very often the quiet reason a system “just works well.” This guide starts from nothing and builds up the discipline of composing what the model sees.

1 · The model has a desk, not a warehouse

There's a hard limit tying everything together: the model can only “see” a fixed amount of text at once. That space is the context window, and everything it uses to answer — instructions, question, retrieved passages, tool outputs, chat history — must fit inside it. Picture it as a desk, not a warehouse. A desk holds only so much at one time; pile on too much and things slide off or get buried. The model has no infinite filing room to browse — it has this one finite desk, and it can only reason about what's actually laid out on it right now. Context engineering is the discipline of deciding, deliberately, what goes on that desk.

2 · More is not better

The instinct is to give the model everything, just in case — but that instinct is wrong, and understanding why is the heart of this topic. When you stuff the window full, two bad things happen. First, the signal gets buried: the one paragraph that actually answers the question sits amid pages of marginally-related text, and the model, like a person facing a cluttered desk, can lose track of what matters — models genuinely pay less reliable attention to information drowned in a heap. Second, you crowd out room the model needs for its own reasoning and answer. So more context often produces worse answers, not better ones. The goal isn't to maximise how much you cram in; it's to put the right information in front of the model — enough to answer well, and little enough that the important parts stand out. Curation beats accumulation.

3 · Everything competes for the same desk

Here's what makes this a real engineering problem: everything competes for the same finite desk. Your system prompt takes space. The user's question takes space. Every retrieved document takes space. Every tool result takes space. And the entire conversation history — every earlier message — takes space too, growing with each turn. They all draw from one shared budget. So context engineering is really a budgeting exercise: given this limited window, how do I spend it? How many retrieved chunks before I crowd out the question? How much history do I keep versus summarise? Do I need this tool's full raw output, or just the one field that matters? Every token spent on one thing is unavailable for another. Seeing the window as a budget to allocate — rather than a box to fill — is the mental shift that makes you good at this.

4 · The long conversation problem

A concrete case shows why this matters constantly: the long conversation. Each exchange usually sends the whole history back into the window so the model remembers the discussion — but that history only grows, and eventually a long chat simply won't fit on the desk. Something has to give. The crude fix is to drop the oldest messages, but then the assistant “forgets” how the conversation began, which can be jarring and lose context set up early. A smarter approach is to summarise: compress the earlier part into a short recap that captures what matters, and keep the recent messages in full. That way the assistant retains the gist of the whole discussion while fitting comfortably in the window. Deciding what to keep verbatim, what to summarise, and what to drop is a central, recurring context-engineering job in any real chat application.

5 · Put the important things where they land

It's not only what you include but how you arrange it. Models don't treat every position equally — text at the very start and very end tends to get more reliable attention than text buried in the middle of a long block. So placement is a lever. Put your core instructions clearly at the top, where they anchor everything. Keep the most important facts close to the user's actual question, not adrift in the middle of a huge pile of retrieved text. State the question itself plainly and prominently, so the model is never in doubt about what it's being asked. Structure helps too: clear headings and separation let the model tell instructions from data from question at a glance, just as a tidy desk lets you find things fast. Good context engineering is part choosing what goes on the desk and part arranging it thoughtfully — because a well-organised desk is one the model can actually work from.

6 · It pulls the whole course together

Context engineering is where the course comes together, because it decides how to combine everything you've learned. Retrieval gives you relevant documents — but how many chunks before you're crowding the desk? Tools fetch live data — but do you pass the full raw result or just the field that matters? The conversation has a history — how much do you keep versus summarise? The system prompt sets the rules — how much instruction is enough before it competes with content? Each is a context-engineering decision, and they interact: spend more on retrieved docs and you have less for history. So this isn't a new source of information; it's the judgement layer that orchestrates all the sources into one well-composed window. When people say a system “just works well,” strong context engineering is very often the quiet reason why.

7 · A simple recipe you can apply

Here's a recipe for almost any AI feature. Start from the question, not the sources: what does the model genuinely need to answer this well? Then add only what directly serves that — the few most relevant chunks, the specific tool result, the essential instructions — rather than everything you could include. Next, actively trim: summarise long history, cut retrieved passages to the parts that matter, strip tool output to the useful fields. Finally, arrange what remains clearly — instructions at the top, the question stated plainly, related facts grouped together. The mindset is answer-first curation, working backward from what's needed rather than forward from what's available. If you catch yourself adding context “just in case,” pause — that's usually noise crowding the desk. Deliberate, minimal, well-arranged: that's the whole recipe, whether the feature is a chatbot, a search tool, or an agent.

8 · A simple test you can run this week

9 · Glossary — every term, spelled out

Context window

The fixed amount of text a model can “see” at once — the desk everything must fit on.

Context engineering

The discipline of choosing and arranging what goes into the window so the model has what it needs and no more.

Token budget

The idea that window space is finite and every piece of content spends part of it.

Summarisation

Compressing older conversation into a short recap to fit long chats in the window.

Placement

Where in the window information sits; start and end get more reliable attention than the middle.

Answer-first curation

Deciding what to include by working backward from what the question actually needs.