Context Engineering Is the New Prompt Engineering

Three years ago the interesting job was prompt engineering. Two years ago it was retrieval. This year the interesting job has a longer name and a much bigger surface: context engineering, and underneath it, harness engineering.

The shift is not a rebrand. It is a widening of what the word "prompt" actually points at. A prompt used to be a paragraph. Then it became a paragraph plus some retrieved documents. Then it became a paragraph, some documents, a tool schema, a memory summary, a policy header, a few-shot exemplar, a scratchpad, and a stop token — and by the time you finish listing everything that lives between your user and your model, you are no longer writing a prompt. You are writing a system.

That system is the harness. Context engineering is the discipline of building it. Prompt engineering, as it existed in 2023, is now one small file inside a much larger repo.

It helps to name the three layers cleanly, because most confusing conversations about AI are really conversations happening at different layers.

Weights are the model. That is a frontier lab problem — OpenAI, Anthropic, Google, Meta, Mistral, the open-weights ecosystem. Very few enterprises will meaningfully move this needle, and none of them will move it every quarter.

Context is what the model sees at inference time. Documents, structured data, tool outputs, memory, policies, examples. This is where your business lives. Nobody at a frontier lab knows what your company means by "active account" or which of your three revenue columns is the canonical one. Only you can supply that.

Harness is the code and infrastructure around the model. The orchestration loop, the tool registry, the memory stores, the retrieval pipelines, the eval harness, the guardrails, the cost meter. This is where correctness, latency, and unit economics are actually decided.

Weights are commoditizing. Context is proprietary. Harness is the leverage. The book calls this out in Chapter 4 and returns to it whenever the discussion drifts back toward model choice.

Every serious agent, stripped of marketing, runs the same five-step loop: plan, retrieve, act, observe, reflect. It is not new — classic planning systems used a version of it in the 1970s. What is new is that the individual steps are now cheap enough, and the models flexible enough, that you can afford to run the loop hundreds of times per user request.

Plan decides what to do next. Retrieve fetches the context that decision needs. Act invokes a tool or produces an answer. Observe reads the result. Reflect decides whether to keep going, back up, or stop.

Most bad agents are bad because one of those five steps has been collapsed into the model. Ask the LLM to plan and retrieve in one shot and you will get confident answers built on missing evidence. Ask it to act and observe in one shot and you will get tool calls with no error handling. The harness's first job is to keep those steps visible, inspectable, and cheap to change.

Chapter 15 walks through this loop as a reference architecture; Chapter 16 covers what breaks when you skip a step.

The industry likes to say an agent "has tools." That framing is a trap. A tool is not an API method the model can call. A tool is a promise the harness makes to the model about what the world will do when a specific typed message is sent.

That promise is context. The name of the tool, its description, its argument schema, the shape of its response, the errors it can raise, the side-effects it will produce — all of that is context the model reasons over before it decides to use the tool at all. A poorly described tool is a hallucination generator. A well-described tool is a rail.

In practice this means the harness owns three things per tool: a schema (what goes in and out), a spec (what it means in business terms), and a guardrail (what it is not allowed to do). Skip any of the three and you will pay for it in an incident review. Chapter 17 has the full checklist.

The word "memory" is doing too much work in AI conversations right now. In a real harness there are at least three distinct tiers, and confusing them is one of the most common reasons agents feel unreliable.

Session memory is what the agent remembers inside a single conversation. Minutes long. Ephemeral. Cheap.

Task memory is what the agent remembers across steps of a longer job — a research task, a migration, a multi-day workflow. Hours to days. Structured. Needs summarization, not raw transcripts.

Org memory is what the company remembers. The canonical definitions, the resolved entities, the policies, the audit trail. Persistent. Governed. Expensive to get wrong.

The bug most teams ship in year one is treating all three as the same store. They are not. Session memory can be a buffer. Task memory needs a summarizer and a schema. Org memory needs governance, versioning, and RLS — see Chapter 18 for the reference model.

Every request an agent makes lives inside three budgets at once: tokens, latency, and cost. Context engineering is the practice of spending each of those three deliberately, instead of watching them get spent for you.

Tokens are the container. Every retrieved chunk, every tool description, every memory summary competes for the same window. A ten-million-token context does not help you if you fill nine million of them with things the model does not need for the current turn.

Latency is the container users actually feel. Every retrieval, every tool call, every reflection step adds real seconds. A carefully pruned context that costs three hundred milliseconds to assemble beats a maximalist context that costs four seconds, every time.

Cost is the container the CFO feels. Model spend is now a line item. A harness that cannot tell you the average tokens-per-task and the ninety-fifth-percentile cost-per-task is not a harness — it is a science experiment. Chapters 23 (/context-advantage/book/chapter-23) and 27 (/context-advantage/book/chapter-30) go deep on this.

A harness without an eval harness is a house without smoke detectors. It will feel fine for months, and then one day something will be quietly on fire and nobody will know.

The three eval surfaces every serious agent needs: a golden set (frozen inputs with known correct outputs, run on every change), a shadow set (real production traffic replayed against candidate versions, no user impact), and agent-task evals (multi-step scenarios that score the whole loop, not just the final answer).

The point of these is not perfection — it is a tripwire. When a change makes the model faster and cheaper but drops the golden set from 94 to 82, you catch it before your users do. Chapter 21 is the field guide.

If you are a data engineer, an analytics engineer, or an AI engineer, this is the shape of the work now: less time writing clever prompts, more time designing the context the model receives and the harness it runs inside.

That is a promotion, not a demotion. The skills that made you good at pipelines — thinking in schemas, respecting idempotency, budgeting compute, writing tests that catch drift — are the exact skills the harness needs. Chapter 6 makes the career case; Chapter 7 makes the case that context is the new semantic layer.

The uncomfortable truth is that people who insist on staying at the prompt layer will spend the next two years feeling like the ground is moving. It is. The ground is moving down one layer, into the harness. That is where the interesting problems live now, and that is where the durable careers are being built.

The line that keeps circulating on X captures the whole shift: building AI agents requires a system prompt that is more code than conversation. That is exactly right, and it is why the discipline has a new name.

You are not writing English at a model anymore. You are writing typed context into a running system, watching how it flows through a loop, budgeting how much of it the model gets to see, and testing whether the whole thing still behaves when a tool fails or a memory is stale. That is engineering. It happens to use natural language as one of its data types.

If you want the long-form version of this argument, with the reference architectures, the eval templates, the memory schemas, and the failure modes we keep watching real teams walk into — read The Context Advantage at https://thecontextadvantage.com/context-advantage, or unlock the full book at /context-advantage/buy. The chapters linked throughout this essay are the ones we would start with.