Context engineering: how to get much better answers from Claude

Most people trying to get better at AI obsess over the prompt — the exact wording of what they ask. That’s worth some attention, but it’s not the biggest lever. The biggest lever is something subtler and far more powerful: what the model can actually see at the moment it answers.

That’s context engineering. And once you start thinking about it, the quality of what you get back changes dramatically.

First, what “context” means

Every answer a model gives is produced by looking at a chunk of text called the context window — its working memory for this moment. Into that window goes your current message, your earlier messages, any files it’s read, its own previous responses, and any instructions it’s been given. Everything in there shapes the answer. Everything not in there might as well not exist.

The window is large but finite. So the real question is never “how do I phrase this?” alone. It’s “what does the model need in front of it to answer this well — and what’s getting in the way?”

The two failure modes

When answers are disappointing, it’s almost always one of two problems with the context, not the prompt.

Too little. The model is missing something it needed — the relevant file, the constraint you forgot to mention, the example of what “good” looks like. It’s not being dumb; it’s answering the question it could see, which wasn’t the whole question. You’d give the same vague answer if someone asked you about a document you hadn’t read.

Too much of the wrong thing. The window is cluttered with irrelevant history — three abandoned ideas, output you already acted on, a tangent from twenty minutes ago. The signal you care about is buried in noise, and the model’s attention is split. This is the one people don’t expect: more context is not better. A focused window beats a bloated one, every time.

Context engineering is the practice of fixing both: making sure the right things are present, and the wrong things aren’t.

How to do it on purpose

A handful of deliberate moves cover most of the value.

Bring in what matters — explicitly

Don’t assume the model knows the relevant background; put it in front of it. Point it at the specific file, paste the exact constraint, show it one example of the output you want. “Summarise this for a non-technical executive, in five bullets, like this example” gives the model a context to match. A naked “summarise this” leaves it guessing at the shape you had in mind.

Keep sessions focused

A session that’s wandered through five unrelated tasks has a context full of clutter. The fix is mechanical:

• Start fresh for a new task. A clean window is a sharp window.
• Summarise or compact a long one. In Claude Code, /compact distils a sprawling conversation down to what matters, clearing the noise while keeping the thread.
• Don’t hoard. Once you’ve acted on some output, you don’t need it sitting in the window competing for attention.

Use a memory file for the permanent stuff

Some context isn’t per-task — it’s always relevant. Your conventions, your tone, your “never do X” rules. Those belong in a standing memory file (CLAUDE.md in Claude Code), read at the start of every session, so they’re reliably present without you re-pasting them and without cluttering each conversation. That’s context engineering as a habit: the permanent context lives somewhere permanent.

Let agents manage their own context

This is also why subagents work so well. When you split a big job across several agents, each one gets its own clean context focused on its slice. None of them is distracted by the others’ work. You’re doing context engineering structurally — giving each piece of the task exactly the window it needs and nothing more.

Why this beats prompt tricks

There’s a whole genre of “magic prompt” advice — say “you are an expert,” add “think step by step,” and so on. Some of it helps a little. But it’s optimising the wrong thing. The most beautifully worded prompt about a document the model can’t see will still produce a vague answer. The plainest possible prompt about a document the model can see, with the irrelevant clutter cleared away, will produce a good one.

Put differently: prompt engineering tunes the question; context engineering tunes the working environment the question is asked in. A great question in a bad environment loses to an ordinary question in a great one.

The mental shift

The shift is to stop thinking “how do I word this?” and start thinking “what does the model have in front of it right now, and is that the right set of things?”

Before you ask, glance at the context: Does it have what it needs? Is it cluttered with what it doesn’t? Two seconds of that question, and a willingness to bring in a file or clear out the noise, will do more for your results than any prompt template.

It’s also a skill that compounds. As models get more capable and context windows get larger, the temptation is to just dump everything in and hope. The people who instead curate — present the signal, cut the noise — will keep pulling ahead. Bigger windows make context engineering more powerful, not less necessary.