RAG & LLM Engineering · BraivIQ AI Engineering Playbook

Context Engineering In Code: How Senior Engineers Actually Build The Context Window In 2026

Context engineering became the load-bearing AI skill of 2026 after Andrej Karpathy and Shopify's Tobi Lutke gave a name to what expert builders were already doing - but most of the discussion has stayed at the level of slogans (context beats prompting, quality of what the model sees matters most). This educational deep-dive is for senior engineers and CTOs who need the level below the slogan: what context engineering actually is as an engineering discipline, and how you build the context window in code. It covers the anatomy of a well-engineered context, the retrieval and assembly decisions that make or break it, the hard problem of managing a finite window on long-running tasks (compaction, summarisation, pruning tool results), and why in agentic systems the tools an agent can reach are themselves context. If you are past the point of asking for a magic prompt and want the engineering underneath, this is the playbook.

September 13, 2026 · 13 min read · By BraivIQ Engineering

Below the slogan - Everyone now agrees context beats prompting; far fewer can tell you how to build the context window in code · Assembly - Context engineering is a retrieval-and-assembly problem: what to fetch, what to include, what to order, what to leave out · Finite window - The hard part is managing a bounded context across long tasks - compaction, summarisation, pruning tool results · Tools = context - In agentic systems, the tools an agent can reach are part of its context and must be curated like everything else

By late 2026, everyone building with AI has heard the message: context engineering has overtaken prompt engineering as the skill that determines whether an AI system works, a shift crystallised when Andrej Karpathy and Shopify's Tobi Lutke put a name to what expert builders had been doing intuitively. The slogans are now everywhere and they are true - the quality of what the model sees matters more than how cleverly you word the request; a brilliant prompt on poor context fails while an ordinary prompt on well-engineered context succeeds. But slogans do not ship. For senior engineers and CTOs, the useful question is the one under the slogan: what is context engineering actually as an engineering discipline, and how do you build the context window in code? That is a concrete, technical problem with real decisions and real failure modes, and it is where the difference between an AI feature that impresses in a demo and one that holds up in production actually lives. As an AI Agency Developer London that builds these systems, this educational deep-dive is the level below the slogan - written for people who are past asking for a magic prompt and want the engineering underneath.

Context Engineering, Defined For Engineers: Context engineering is the discipline of deciding, in code, exactly what information occupies the model's context window at the moment it is asked to act - and doing so under a hard constraint: the window is finite, and everything you put in it competes for space and attention. It is fundamentally a retrieval-and-assembly problem. Every request you send is a context you assembled: some fixed instructions, some retrieved knowledge, some conversation history, some tool results, some structured data, and the actual task. Context engineering is the set of decisions about what to retrieve, what to include and exclude, how to order it, how to format it, and how to keep it within budget as a task grows. Prompt engineering optimises the wording of one part of that context (the instruction); context engineering optimises the whole assembly. That reframing - from wording to assembly - is why it is an engineering discipline and not a knack.

The Anatomy Of A Well-Engineered Context

Think of the context window as a budget you allocate, not a bucket you fill. A well-engineered context for a typical task has several distinct components, and the engineering is in choosing how much of the budget each gets and what actually goes in. There are the system instructions - who the model is, what it must and must not do, the output contract - which should be stable and precise rather than sprawling. There is retrieved knowledge - the documents, records or facts relevant to this specific request, fetched from your data - and the central decision here is relevance: pulling the few genuinely pertinent chunks beats dumping everything, because irrelevant content does not just waste budget, it actively degrades the answer by diluting the model's attention. There is history - prior conversation or task state - which must be included enough to preserve continuity but is a prime candidate for compaction as it grows. There are tool results - the outputs of actions the agent has taken - which can be enormous and often need trimming to the parts that matter. And there is the task itself, stated clearly. The craft is that more is not better; relevant, well-ordered and appropriately compressed is better. A senior engineer approaches the context window the way they approach any constrained resource: deliberately, measuring what earns its place.

Retrieval And Assembly: Where It Is Won Or Lost

Most context engineering effort, in practice, goes into retrieval and assembly, because that is where quality is decided. Retrieval is the problem of getting the right knowledge into the context for this request - and it is more than a vector search. Good retrieval means chunking your source material sensibly so that a retrieved piece is self-contained and meaningful; choosing a retrieval strategy that actually surfaces the relevant material (semantic search, keyword, hybrid, or structured queries, depending on the data); and, crucially, being ruthless about relevance, because the single most common failure we see is stuffing too much marginally-related content into the window and wondering why answers got worse. Assembly is the problem of arranging what you retrieved: ordering matters (models weight the start and end of a context differently from the middle), formatting matters (structured, clearly delimited context is easier for the model to use than an undifferentiated blob), and provenance matters (labelling where information came from lets the model reason about trust and lets you trace answers). The discipline that separates production systems from demos is measuring this: building an evaluation set and testing whether a retrieval or assembly change actually improves answers, rather than trusting intuition. Context engineering, done seriously, is as much about evaluation as about assembly.

Budget, don't fill - treat the window as a resource to allocate; every token competes, and irrelevant content degrades answers, not just wastes space.
Chunk for self-containment - retrieved pieces must be meaningful on their own; bad chunking poisons retrieval no matter how good the search.
Be ruthless about relevance - the most common failure is over-stuffing marginally-related content; fewer, more relevant pieces win.
Order and format deliberately - position and clear structure change how well the model uses the context; a labelled, delimited context beats a blob.
Measure with evals - test whether a retrieval or assembly change actually improves answers; do not trust intuition on context decisions.

The Hard Part: Managing A Finite Window On Long Tasks

Where context engineering gets genuinely hard - and where it connects to the agent-runtime story of 2026 - is in long-running tasks that generate more context than the window can hold. An agent working through a multi-step task accumulates conversation, reasoning and tool results, and eventually that accumulation exceeds the budget. Handling this well is a real engineering problem with several techniques, each with trade-offs. Compaction summarises earlier parts of the task into a compact form that preserves what matters and discards the rest - powerful, but lossy, and getting the summary wrong can break the task by dropping something it later needs. Pruning tool results is often the highest-leverage move, because raw tool outputs (a full API response, a large query result) are frequently enormous and mostly irrelevant after they have been used; keeping a distilled version rather than the raw dump reclaims huge amounts of budget. Sliding windows keep recent context in full and drop or summarise older content. Structured external memory moves state out of the window entirely into a store the agent can query, keeping the live window small. The managed agent harnesses that arrived this year do some of this compaction automatically, which is genuinely useful - but a senior engineer should understand what is being compacted and why, because automatic compaction that drops the wrong thing is a subtle and serious failure mode. Managing the finite window is the part of context engineering that most separates people who have shipped long-running agents from those who have not.

The Bottom Line

Context engineering earned its status as 2026's load-bearing AI skill for a real reason, but the slogans it travels on hide the actual work. Below the slogan, it is a concrete engineering discipline: deciding in code exactly what occupies a finite context window at the moment the model acts, and doing so under a budget where everything competes. It is won or lost in retrieval and assembly - getting the right, relevant knowledge in, ordered and formatted well, measured with real evals rather than intuition - and it gets genuinely hard on long-running tasks, where compaction, pruning tool results, sliding windows and external memory are the techniques that keep a bounded window working, each with lossy trade-offs a senior engineer must understand rather than delegate blindly to automatic tooling. And in agentic systems, the tools an agent can reach are themselves context to be curated. For engineering leaders, the takeaway is that getting value from AI is now much more about this disciplined, measurable, unglamorous context work than about model choice or clever prompts - which is why it rewards exactly the skills good engineers already have. Stop looking for the magic prompt; engineer the context window, in code, on purpose.

References & Further Reading

DEV Community - Context Engineering in 2026: the skill that actually makes AI coding work: https://dev.to/alexcloudstar/context-engineering-in-2026-the-skill-that-actually-makes-ai-coding-work-37ni
deepset - Context engineering: the next frontier beyond prompt engineering: https://www.deepset.ai/blog/context-engineering-the-next-frontier-beyond-prompt-engineering
Karo Zieminski - An illustrated guide to context engineering, prompt engineering and the future of both: https://karozieminski.substack.com/p/context-engineering-product-builders-guide-2026
Anthropic - Effective context engineering for AI agents (engineering guidance): https://www.anthropic.com/engineering
Scrimba Guide - What is context engineering? (2026 developer guide): https://scrimbaguide.tech/blog/what-is-context-engineering/