Why Context Engineering Beats Picking a Smarter Model

The framing that's gained traction in 2026 is: model weights are the AI's hardware, context is its software. When you interact with ChatGPT, the underlying neural network weights don't change - those are baked in during training and stay the same across millions of conversations. What changes is the context: the system prompt, your messages, any documents you've uploaded, the memory the product is keeping between sessions.

Changing the weights requires retraining the model. That's extremely expensive and only OpenAI/Anthropic/Google etc. do it. Changing the context is something anyone can do, in real time, with no special infrastructure. That's why the leverage for everyone outside the frontier labs sits in context, not in models.

Three real examples from 2026 illustrate this:

• Perplexity vs raw ChatGPT. Both can use GPT-5. Perplexity feels noticeably better at research questions because it does web search first, retrieves the relevant pages, extracts the relevant sections, and presents the model with a structured 'here's what's currently known about X' bundle before asking the question. The model itself isn't smarter. The context preparation is.
• NotebookLM. Google's tool that lets you upload up to 50 sources and chat with them. The model is Gemini, which is also available in the Gemini app. The difference: NotebookLM keeps a dedicated retrieval system over your sources, ranks the right chunks for each question, and structures the prompt around them. It often produces better answers about YOUR documents than directly asking Gemini.
• Coding tools like Cursor and Claude Code. Both use Claude as the underlying model. They feel different because each builds a different context window: which files to include, in what order, with what conventions, with what history. The model just answers; the tool decides what to show it.

The pattern is consistent: when products differentiate in 2026, the differentiation usually lives in the context layer above the model, not in the model itself.

A useful worked example arrived in October 2026. Benchouse published a study in which it pushed nao (an open-source analytics agent that answers business questions by writing queries against a data warehouse) through 90 fixed questions over 59 warehouse tables, running each configuration three times. Benchouse is a company that benchmarks analytics agents; the write-up states that nao sponsored the piece and that Benchouse ran the evaluation itself.

The numbers tell a two-part story:

• The model came first. With nothing but table and column names, Claude Sonnet 5 answered 49.6% of questions correctly. Swapping to Claude Opus 5.5 on the same bare schema jumped that to 88.2%. The larger model explored the database with its tools far more readily.
• Context closed the gap to production grade. Adding synced schema details, then full table documentation, then nao's own context-rules step lifted Opus to 92.9%. Explicit business definitions and answering rules took it to 96.5%.
• Consistency improved as well. The share of questions answered correctly on all three attempts rose from 77.6% to 92.9%.
• Good context made a cheaper model viable. Run on the finished context, Claude Sonnet 5.5 scored 92.9% at roughly half the cost per question - a 48% saving, measured in US dollars in the study.

So the honest reading is not 'context beats the model' in every case. For an agent that has to find its own way around a database, the stronger model bought the first big jump. The last few points - the difference between a demo and something a finance team will trust - came from context. And once that context existed, it was what let the team drop back to a cheaper model without losing much.

The final jump came from a handful of unglamorous changes. Each one works for a reason that applies well beyond analytics.

1. Defining business metrics in writing. Terms like 'money-losing campaign' or 'fill rate' have several reasonable meanings. A model has no way to know which one your company agreed on, so it picks the most common industry reading. Writing the house definition next to the table removes the guess - the model applies the rule you gave it instead of the one it learned from the internet.
2. Removing ambiguous terminology. When one synonym points at two different columns, or a catalogue note is out of date, the model has to choose between competing paths. Every extra fork is another chance to pick the wrong one. Fewer, cleaner names shrink the search space.
3. Telling the agent to use the agreed calculation first. Capable models are eager to improve on what they find. In the study, once the documentation admitted a data field was imperfect, the agent built its own replacement rather than using the agreed one. An instruction to lead with the house figure and only then flag caveats keeps the reported number stable, while still surfacing the limitation.
4. Asking it to answer the question that was asked. Agents like to anticipate the next question. A rule to answer the requested period and breakdown first, then extend the analysis, keeps the core answer from getting buried.

Notice that none of these is more information for its own sake. Two of the four are about giving the model less room to improvise. That lines up with what we see in long-running agent sessions: relevance and clarity matter more than volume.

Whether you run an analytics agent over a warehouse or a simpler assistant over a few spreadsheets, the same checklist applies. Work through it in order - each step is cheaper than the one after.

For a normal user (you, asking ChatGPT or Claude things in the browser), there's a meaningful gap between 'I just typed a question' and 'I prepared the context first'. A few habits that make a measurable difference:

1. Front-load relevant context. If you're asking about your specific project, paste the bits of the project the AI needs to see. Don't make the model guess. 'Here's our existing email template, here's the customer complaint, draft a reply' beats 'draft a reply to an angry customer'.
2. Be explicit about constraints. 'In 150 words, no exclamation marks, friendly but direct, sign-off from Sarah' is doing context engineering. The model uses these rules; without them it picks defaults that won't match your voice.
3. Show examples of the output you want. Especially for any structured task (categorisation, summarisation, format conversion), 2-3 worked examples in the prompt are worth more than 200 words of instructions.
4. Curate memory. If your AI product has persistent memory (ChatGPT, Claude Projects, NotebookLM notebooks), keep it tight. Stale or contradictory memory actively makes answers worse. Periodically review + prune.
5. Use the right product for the job. Different products have different context architectures. Perplexity for research, NotebookLM for chatting with your documents, ChatGPT/Claude for general conversation, Cursor/Claude Code for coding. The 'best' model for any of these is similar; the surrounding architecture is what matters.

Picking a smarter model still helps - it's just not the lever it was. Going from GPT-3.5 to GPT-4 made everything noticeably better; going from GPT-4 to GPT-5 makes a subset of harder tasks better. If you're spending £200/year on AI tools, paying for Plus tier on one good chat product (ChatGPT Plus, Claude Pro, or Gemini Advanced) generally gets you 80% of the frontier capability.

The exception is agentic work, where the model has to explore and use tools on its own. There, as the analytics study above shows, a stronger model can still be the single biggest jump - and context is what takes it the rest of the way. For more on that trade-off, see our guide to building AI agents that survive production.

The remaining 20% of difference between providers is specialisation: Claude is genuinely better at coding + long documents; Gemini is better integrated with Google Workspace; ChatGPT has the best Apps SDK + agent ecosystem. None of those advantages come from raw model smarts - they come from the context and tools built around the model.

A few practical shifts to expect through 2026 and into 2027:

• Context windows keep growing. A 1-million-token window (Claude 4.7's current spec) means you can paste an entire book or codebase as context. The bottleneck shifts from 'what fits in the prompt' to 'what's actually relevant to the question'.
• Memory becomes more persistent. Products are leaning into long-term memory so the AI remembers your preferences across sessions. This is genuinely useful, but worth checking the memory settings regularly so it stays accurate.
• Retrieval gets cheaper and faster. Products that fetch information from the web or your documents in real-time become the default rather than the exception.
• Custom 'agents' become normal. Pre-configured AI helpers with their own context + tools + instructions, that you (or a developer) can publish for specific tasks. ChatGPT's Apps SDK, Claude's MCP, Google's Gems - all roughly the same idea, all about packaging context as a reusable thing.

If you're trying to get more value out of AI tools in 2026, the highest-leverage move is rarely 'pay for the smarter model'. It's usually 'put more relevant context in the prompt' or 'use a tool that's already doing that for you'.

Context is the moat - both for big products like Perplexity and NotebookLM, and for you as the user. The model you're talking to today is approximately as smart as the model you'll be talking to in a year. What changes is how well the product structures the work + what you bring to the conversation.