The Context Engineering Manifesto

First, credit where it is due. The phrase "context engineering" was popularised in mid-2025 by Andrej Karpathy, Tobi Lütke, Walden Yan, Ankur Goyal, Dex Horthy, and a handful of others who were trying to name something the existing vocabulary could not capture. Karpathy called it "the delicate art and science of filling the context window with just the right information for the next step." Simon Willison noted that unlike "prompt engineering" — which many people read as a pretentious term for typing things into a chatbot — "context engineering" had an inferred definition much closer to the actual work involved. Gartner formalised it as an enterprise discipline. By early 2026, the industry consensus had shifted: most data and AI leaders agreed that prompt engineering alone was no longer sufficient to power AI at scale.

Context engineering is the discipline of designing the full informational environment an LLM receives. Not just the prompt, but retrieved knowledge, tool outputs, conversation history, memory state, system instructions, output schemas — everything the model sees before it generates the next token.

Context engineering matters because prompt engineering assumed a static world. You wrote a prompt, tested it, maybe iterated a few times, and shipped it. The problems showed up when LLM applications needed to call external tools, retrieve documents dynamically, maintain state across dozens of turns, or coordinate multiple agents. In those scenarios the prompt is just one piece of what the model sees. You can have a perfect prompt and still get terrible results if the surrounding context is wrong. The reframe is correct. I am not here to argue with the reframe.

I am here to argue that the reframe has been collapsed into something smaller than its own definition says it is.

Here is the question I cannot find in any of the published pieces on context engineering, and I have read most of them by now:

When an LLM reads its context window, a large portion of what it sees — the role definition, the tone register, the domain knowledge, the task framing, the reasoning strategy, the examples, the output format, the constraints, the tool descriptions — was written by a human. Not retrieved. Not orchestrated. Authored. Where did that authored content come from? What tool? What structure? Who reviewed it? What does the craft of writing it look like, for a team, at scale, over time?

The honest answer, in 2026, is: a Google Doc, a comment at the top of a Python file, a prompt buried in a LangChain template, a Slack thread someone promised to document later. Or, increasingly, a "prompt management platform" that is — let us be honest with each other — a version-controlled text area with logging bolted on the back.

The industry-standard answer to "what are the components of a prompt" has been stable for a couple of years. Google, OpenAI, Anthropic, and DAIR.AI converge on something like six pieces: a role, context, a task, examples, an output format, and constraints. Every serious prompt engineering framework teaches some version of this list.

The six-component model works well for individual prompts. For production systems, it has three honest weaknesses.

If you make those three moves — separate tone from role, promote reasoning to a first-class concern, add tools — you get a nine-field prompt anatomy.

You do not have to use all nine at once. Start with three — Role, Context, Task — the irreducible core. Graduate to five when you need tone control and output structure. Use all nine when the work demands it. That progressive disclosure — three tiers of complexity on the same underlying anatomy — is how you make structured prompting accessible without dumbing it down.

Claude reads XML tags natively; each field gets wrapped in its own element. GPT-4 prefers Markdown headers with concise formatting. Gemini responds best to uppercase labels with critical restrictions positioned clearly. Lovable and other dev-agent targets want natural prose — no tags, no headers, just paragraphs that read like a product owner writing to an engineering team.

The content of the Role field does not change between these targets. The encoding does. And yet the dominant workflow in 2026 is: write the prompt once, manually reformat it for each target, hope you remember all the platform-specific rules, lose information in each pass, and accept that the multi-platform version of your prompt will drift from the original within two weeks.

If the content is stable and the encoding is platform-specific, the encoding is a compilation step. You do not hand-write assembly for every CPU architecture. You write source code, and a compiler emits the platform-specific output.

Authored context should be written once, in a canonical structured form, and compiled for each target platform at the point of use.

Imagine a customer-support triage agent that classifies incoming tickets, drafts internal summaries, and flags anything urgent for human review. Here is how that looks authored with the nine fields:

That is one canonical authored artifact. Now compile it. For Claude, each field becomes an XML element. For GPT-4, a Markdown section. For Gemini, an uppercase label. Three different outputs, one source.

Notice what is not in this picture. We have not talked about retrieval, vector stores, token budgets, or memory strategies. Those are real and necessary — and the topic of a different conversation. This is the authored half. Good authoring does not replace good retrieval. It makes good retrieval effective by giving the model a clear frame to interpret retrieved information inside.

There is a window closing. Three reasons it is worth naming the authoring half of context engineering in 2026 rather than waiting.