Summary: Context engineering is the art of giving a model exactly the information it needs to do the next step of its work — and deliberately withholding the rest. As model capabilities grow, the bottleneck shifts from what the model can do to what the model can see. Several articles in this vault circle the same idea from different angles — agent architecture, production RAG, learning, ontology, and AI-SDLC methodology. This page draws them together.

Why context, not capability, is the new bottleneck

A human engineer is bounded by a cognitive limit — no single brain holds an entire large business domain. An AI agent has a different bottleneck: the context window, the maximum number of tokens it can "see" at once. Modular Monolith Instead of Microservices makes the consequence concrete: an agent reads dozens of times more tokens than it generates (analyses point to a ~166:1 read-to-generate ratio), so architecture determines the economics of every change the agent will ever make. Andrej Karpathy, within his Software 3.0 framing (the LLM as interpreter, the context window as program), compares the agent to a colleague with anterograde amnesia — it remembers only what is currently in context.

This is why classic architectural metrics — Conway's Law, Two-Pizza Teams, coupling vs. cohesion — were answers to the human limit, and why context engineering now matters more than classic coupling. The dominant question becomes: how much working memory will the agent spend understanding this system before it can do any real work?

Bigger windows do not solve it

The naive hope is that ever-larger context windows make the discipline unnecessary. They do not. Modular Monolith Instead of Microservices catalogs three failure modes that survive larger windows:

  • Context Rot — the model "gets dumber" as you add more. Drew Breunig's four patterns: Poisoning (a hallucination repeated back into context), Distraction (an over-long context fragments attention), Confusion (irrelevant information degrades quality), and Clash (conflicting data).
  • Lost in the Middle — empirical research (Liu et al., 2023) shows accuracy drops markedly for content buried in the middle of a long context: a U-shaped performance curve.
  • The Navigation Paradox — for tasks with hidden dependencies, a structural map (e.g. a dependency graph) beats a vanilla large-window LLM by a wide margin. A bigger window doesn't remove the need for structure; it only shifts the failure mode.

The practical takeaway: signal density beats volume. More context is not more help.

Context discipline in a production system

Building Reliable Agentic AI Systems shows the discipline operationalized. Bayer's PRINCE platform found that larger windows "did not remove the need to be selective" — dumping everything into the prompt made the system harder to steer and harder to evaluate. Instead it routes different context to different capabilities at the right time:

  • planning context → the Think & Plan step,
  • retrieval context → the Researcher agent,
  • evidence context → the Reflection agent,
  • synthesis context → the Writer agent.

Concretely: Text-to-SQL injects only the schema relevant to the current query, not the whole database; the Reflection agent sees the original question plus collected evidence, not the full workflow history; the Writer receives curated chunks with citation constraints, not raw retrieval output. Splitting a monolithic agent into this structured workflow is what let each piece be evaluated, debugged, and improved in isolation. This pairs with harness engineering — the scaffolding (orchestration, tool boundaries, state persistence, retries, fallbacks, reflection loops, observability) within which the model acts. Context engineering shapes what the model sees; harness engineering shapes what the model can do.

Memory is the substrate

Context has to come from somewhere, and that somewhere is memory. Two articles supply the foundation:

  • Spec-Driven Development Will Collapse names Context Crafting as one of its Four Crafts (Intent · Spec · Context · Prompt) — the system's decision layer, "backed by empirical memory." Given an intent, under these constraints, with this organizational history: which architecture, which patterns, which tools? "The knowledge base is the differentiator. Without it, context crafting collapses back to architect guesswork." Kapil Viren Ahuja's blunt conclusion — "memory isn't a feature, it's the prerequisite" — is the same claim from the methodology side: a system that forgets what it was building "lies with confidence."
  • Knowledge Graphs and the Five Waypoints supplies the structural form of that memory. Benny Cheung's wager — "the formless can be made legible without being made smaller" — is exactly the context-engineering bet: structuring data does not lose detail, it gains the road that lets you walk between the pieces. Every RAG project that skips the ontology layer and reads straight off the data pile stalls, because "the retrieval surface has no shape to retrieve along." Ontology is context engineering at the data layer.

The human counterweight

The Learning Loop and LLMs supplies the necessary caution. LLMs are a superb natural-language interface to all the specialized notations of software — but that fluency in translating intent into code "is not the same as learning." Readymade components and LLM output are "compressed bundles of context": you get the functionality without internalizing the decisions inside it, which is how teams hit the maintenance cliff. So context engineering cuts both ways — engineering the machine's context is essential, but it must not be mistaken for the engineer's own hard-won understanding. The goal is to feed the model the right context, not to outsource the human's learning loop to it.

The throughline

Across all five threads the same principle recurs: as models get more capable, the leverage moves from the model to the context around it. Whether the unit of work is an agentic workflow, a RAG pipeline, an architecture an AI must navigate, an SDLC methodology, or a developer's own learning, the differentiator is the discipline of assembling the right information, in the right shape, at the right moment — and withholding the rest. As model capabilities improve, parts of today's explicit context-and-harness scaffolding may thin out or move into native model capabilities; but where trust, traceability, and reviewability matter, explicit control over context remains essential.