Context Engineering: The Discipline That Decides Whether Your Agent Works

In 2023, the hottest job in technology was something called prompt engineering. Six-figure postings made headlines. Bootcamps appeared overnight. The promise was that a person who knew the magic words could coax genius out of a language model, and for a brief window the promise held, because the models were new, the inputs were short, and a clever phrasing really could change the output.

Three years later that job has quietly disappeared, and not because it failed. It disappeared because it was absorbed into something larger and more durable. The craft did not die. It grew up, took a new name, and moved to the center of how serious AI systems get built. The name is context engineering, and if you want to understand why one agent feels like magic and another feels like a parlor trick, this is the single most important idea to absorb in 2026.

The thesis is blunt. An agent almost never fails because the model is not smart enough. It fails because it was handed the wrong context. The model is rarely the bottleneck anymore. The context is.

01 / The Rename That Mattered

The job that vanished, and the discipline that replaced it

The story of how the term changed is unusually well documented, because it happened in public, on X, over the course of about a week in June 2025.

The writer and engineer Simon Willison had spent years defending "prompt engineering" as a serious skill, and watching it lose. The problem was never the work. The problem was the word. In the popular imagination, he observed, the phrase had curdled into "a laughably pretentious term for typing things into a chatbot." The genuine practice of constructing reliable inputs got tarred with the same brush as someone asking a chatbot to write a limerick about their cat.

Then Shopify's CEO, Tobi Lutke, offered a replacement. He preferred "context engineering," he wrote, because it named the real skill: "providing all the context for the task to be plausibly solvable" by the model. Days later Andrej Karpathy, among the most widely followed voices in the field, amplified it, and that was the moment it stuck. People hear "prompt" and picture a short instruction, he noted, when every serious application actually depends on something far deeper.

Karpathy's own definition became the canonical one. Context engineering, he wrote, is "the delicate art and science of filling the context window" with exactly the right information for each step. He was careful to add that he was not trying to coin a buzzword. He simply thought the word "prompt" made people underestimate a genuinely hard piece of engineering. It was the same instinct behind his older and more famous line that "the hottest new programming language is English." The interface had changed. The discipline behind it was only getting more demanding.

Context engineering is the delicate art and science of filling the context window with just the right information for each step.

The rename was not cosmetic. It marked the moment the field admitted out loud that the interesting work had moved upstream of the sentence you type.

02 / The Definition

What context engineering actually means

To feel the difference, borrow a mental model that Karpathy and others have leaned on: think of the language model as a CPU, and its context window as the RAM, the working memory it can see at any single instant. The model itself is fixed. What changes from one task to the next, and what decides whether the task succeeds, is what you load into that working memory before you ask the model to act.

Prompt engineering was about writing one good instruction. Context engineering is about assembling the entire working memory: the instructions, yes, but also the relevant history, the retrieved facts, the available tools, the user's preferences, and the current state of the world, all compacted into a limited window so the model has what it needs and nothing that distracts it.

Put simply: a prompt is what you say, and context is everything the model needs to know to act on what you say. The first is a sentence. The second is an architecture. This is why Karpathy described context engineering as merely one part of a thick layer of nontrivial software that surrounds any real application. The model sits in the middle. The engineering lives in the layer around it, the part that decides, on every single turn, what the model is allowed to see.

03 / The Clearest Example

Watch the same task done twice

The fastest way to feel the difference is to watch one task performed with poor context and then with rich context. Take the most ordinary request imaginable, the kind that lands in millions of inboxes every day: "Hey, are you free for a quick call tomorrow?"

Hand that sentence to a thin agent with no context and you get something close to useless. It does not know who "you" are, what "tomorrow" means in your timezone versus the sender's, whether your calendar is already full, whether this person is your largest customer or a cold pitch, how long your "quick calls" actually run, or whether you guard your mornings for focused work. It will either fire back a dozen clarifying questions or confidently propose a slot that is wrong in three different ways. This is the demo that impresses nobody, and it is what most "agents" on the market quietly are.

Now hand the identical sentence to an agent with engineered context. It can see both calendars and the genuinely open slots. It knows the sender's timezone and resolves "tomorrow" correctly. It knows this person closed a major deal last quarter, so the meeting carries weight. It knows your standing preference for no meetings before ten in the morning. It knows your quick calls run twenty-five minutes, not sixty. It proposes a single specific time that a thoughtful human assistant would have proposed, and it does so in one pass, without interrogating anyone.

The model in both cases is identical. The intelligence is identical. The entire difference is the context.

That is the whole thesis in miniature. The difference between an agent that embarrasses you and an agent that feels like a brilliant chief of staff is, almost entirely, the quality of the context assembled around the request. And it is why coordination problems — where the right answer depends on many people, many calendars, and many constraints at once — are among the most context-hungry tasks in all of enterprise software. The model is a commodity in that example. The context is the product.

04 / The Failure Mode

Why agents break in production

If more context produces better answers, the naive conclusion is to stuff everything into the window. Dump the entire knowledge base, the full history, every available tool. This is the most common failure mode in production, and it fails for a reason that surprises newcomers: more context is not better. The right context is better.

Models degrade when the window fills with noise. Researchers have documented a "lost in the middle" effect, where information buried in the center of a long context gets overlooked even though it is sitting right there. Practitioners now talk about "context rot," the slow decay of an agent's reliability as its window accumulates stale instructions, irrelevant retrievals, and the residue of earlier turns. Too little context and the model is ignorant. Too much of the wrong kind and the model is confused, slower, and more expensive, because every token in that window is metered and paid for.

So the real craft is not accumulation. It is curation. Good context engineering is as much about deciding what to leave out, when to summarize, and when to refresh, as it is about what to put in. It looks far more like disciplined information architecture than like clever wordsmithing. The skill that separates a strong system from a fragile one is knowing, on each step, the smallest set of inputs that makes the task solvable. This is exactly why Karpathy called it a science and an art in the same breath. The science is the retrieval, the compaction, the memory management. The art is the judgment about what actually matters right now.

05 / A Working Framework

The four layers worth engineering

It helps to stop treating "context" as one undifferentiated blob and start treating it as a small stack of distinct layers, each engineered on its own terms. Four are worth naming, because each one fails differently when you neglect it.

The first layer is instructions: the system prompt, the role, the rules, the procedure the agent should follow. This is the layer closest to old prompt engineering. It is still necessary. It is simply no longer sufficient on its own.

The second is state and history: the short-term memory of the current task. What has happened so far in this session, what the agent already tried, what the user said three turns ago. Engineering this layer means deciding what to carry forward and what to compress, so the thread stays coherent without bloating into nonsense.

The third is knowledge: the retrieved facts the task depends on, pulled from documents, databases, and prior records. This is the home of retrieval-augmented generation, and increasingly of semantic memory, the durable record of what a particular user or business actually means by its own terms. When a system knows that "the Johnson account" maps to a specific record and a specific history, that is engineered knowledge, not luck.

The fourth is tools and environment: the actions the agent can take and the live data it can reach. An agent that can read a calendar, query a system of record, or send a message has a fundamentally richer context than one that can only talk, because the world itself becomes part of what it can see and change.

Engineer all four deliberately and the agent feels capable and calm. Neglect any single one and the breakdown appears precisely where you cut the corner: a confident answer built on stale knowledge, a coherent paragraph that forgot what was decided two turns ago, a perfect plan it has no way to execute.

06 / The Evidence

What the 2026 Gartner map reveals

Here is the strongest sign that context engineering is no longer a niche term from a handful of influential posts. It has become a category that the largest analyst firm in enterprise technology now scores vendors against.

Gartner's 2026 Magic Quadrant for AI Platforms for Data Science and Machine Learning, published in June 2026, reads in places like a referendum on exactly this discipline. The report repeatedly assesses whether a platform can supply the semantic context, the metadata, and the knowledge-graph grounding that agents need in order to behave reliably inside a real enterprise. And it does not soften the gaps. One long-established leader is cautioned for limited ability to provide that context layer, with Gartner noting its customers may have to source the capability from other providers. A major analytics vendor is flagged for offering only thin exposure to context-ready assets such as semantic definitions and knowledge graphs, which the report says makes interoperable multi-agent systems markedly harder to build.

The mirror image is just as telling. The vendors climbing the chart are the ones shipping context as a headline feature. One hyperscaler now markets an integrated knowledge layer positioned as the thing that lets agents operate inside a messy enterprise without falling over. A leading data-platform vendor has organized its entire 2026 roadmap around supplying context and decision intelligence so that agents can reason across business processes rather than guess. Another has built a named context engine directly into its agent stack and treats it as a primary differentiator. The language has converged. Across very different companies, the pitch has become some version of "we give your agents the context."

When the inputs you put in the window become a scored axis in the industry's most-watched ranking, the term has left the blog and entered the boardroom.

Watch, too, what these companies bought rather than what they shipped. Across the field, the acquisitions of the past two years cluster around the same three capabilities: data lineage, observability, and agent evaluation. The machinery, in other words, for knowing what an agent saw, where the data came from, and whether the output can be trusted. Nobody was acquiring their way to a smarter base model. They were acquiring the ability to manage context and to prove it held up. And the rapid, near-universal embrace of the Model Context Protocol, a standard whose very name announces that its job is feeding context to models, tells you where the plumbing of this layer is consolidating.

When an idea travels from a founder's post on X to a scored axis in the most-watched vendor ranking in enterprise software inside of twelve months, that is not a fad cycle. That is a discipline forming in real time, and being priced accordingly.

07 / The Strategic Point

Context is where the moat moved

There is a deeper reason all of this matters, and it connects to a pattern as old as technology adoption itself. The model, the expensive and dazzling component everyone fixates on, is also the component that goes obsolete fastest. Today's frontier model is next year's baseline, and the year after that it is a footnote. If the most visible piece of the system is also the most perishable, it simply cannot be the lasting advantage. It is the electricity, not the factory.

The context layer behaves in the opposite way. The semantic record of what your business means, the accumulated memory of your users and their preferences, the rails that connect your agents to your systems, the hard-won curation of what belongs in the window and what does not: these compound over time, and they do not reset when the next model ships. You can swap the engine in an afternoon. You cannot swap the wiring of an organization overnight, and you cannot rebuild years of accumulated context with a single API call.

This is why the most serious builders have quietly stopped competing on the model and started competing on the context. The model is becoming something you select, like a power supply, judged on price and performance and swapped without sentiment. The context is the thing you build, and own, and improve, week after week. In a market where nearly everyone has access to roughly the same intelligence, the durable advantage belongs to whoever feeds that intelligence best.

Prompt engineering taught a generation to write better sentences. Context engineering is teaching that same generation to build better systems. The first was a skill that lived in a person's head and walked out the door when they left. The second is an architecture that lives in the product and compounds while you sleep. One was a clever input. The other is a moat.