Harness Engineering: How We Got From Prompts to Here

It is safe to say that the landscape of software engineering has changed since the introduction of generative AI. With AI coding tools now everywhere, it has also become clear that the role definition of the software engineer itself is changing.

I’m not sure I even need to prove this claim — we use these tools every day, and companies actively encourage their employees to use them more. But for those who still don’t believe our role definitions are changing, history offers a useful parallel.

Before CAD tools, drafting in civil engineering was manual, intricate work. When CAD applications were introduced, the job didn’t die. Instead, it thrived — in a different way. The engineers who mastered the new tools became the ones headhunted for exactly that skill set. CAD never made civil engineering autonomous; it enabled engineers to take on far more complex work, far more efficiently.

I think we software engineers are living through a similar transition period. The difference in our case is that it’s becoming almost clear that most of the mundane work can be handled by agentic AI. And if you ask me — or simply look at what the sector is trying to achieve — the goal is to handle work autonomously, end to end.

That, however, is not easy. It is still very much an area of active research.

And the word of the day is “harness” — or more specifically, “Harness Engineering.”

I’m sure some of you have already started thinking:

First prompt engineering, then context engineering, and now another term? What the heck is a “harness,” and why is everyone suddenly saying “Harness Engineering”?

Fair question. I believe that to understand it properly, we have to understand how it all got to this point.

…and don’t worry, I’m not going to start from the Big Bang :) — although in our case, the Big Bang would probably be the Transformer architecture and the attention mechanism it is built on.

To give you a rough mental roadmap, here is the adventure ahead:

• What is a prompt? What is prompt engineering?
• What is context? What is a context window?
• What is context engineering?
• Why are prompt engineering and context engineering not enough anymore — what stopped working?
• What is a harness? What is harness engineering?

# In the beginning, there was the prompt

To create a solid foundation, I want to start from something fundamental about human behavior — or at least about how we have invented and improved things for the last couple of thousand years.

Think about the Wright brothers imagining flight. They didn’t start with a manual. They started with observation and imagination — watching birds, studying the gliders and records of the pioneers before them. To get from zero to a goal, they needed input, and luckily enough, they acquired it from their environment.

I can hear you saying: “When are you coming back to the topic?”

So, for the impatient ones: how does an LLM achieve a desired goal? It needs an instruction — or more accurately, a prompt — and the completion is, hopefully, your desired goal.

A prompt is the full text input you hand to the model for a single generation call: the instruction, the question, any examples, any constraints — everything the model reads before it starts producing tokens. And here is the detail that people often miss: the model does not “understand your intent” in any magical way. It does the one thing it was trained to do — predict the most plausible continuation of the text you gave it.

That single fact explains why a good prompt matters so much. An LLM does not read your mind; it completes your text. If your prompt is ambiguous, the model fills the gaps with assumptions — plausible ones, but not necessarily yours. Ask for “a summary” and you might get three lines or three pages, bullet points or an essay, aimed at an expert or a child. Specify the audience, the length, the format, and the constraints, and the space of plausible completions collapses toward the thing you actually wanted. The clearer the input, the narrower — and better — the output distribution.

# Prompt engineering: the first paradigm

Prompt engineering is the systematic version of that instinct: deliberately designing the wording, structure, and examples of a prompt to reliably get better outputs from the model.

Between 2022 and 2023 it grew into a genuine discipline with reproducible techniques. Zero-shot prompting asks the model to perform a task with instructions alone; few-shot prompting adds worked examples directly into the prompt — what researchers call in-context learning, because the model adapts to the task without any retraining. Chain-of-thought prompting showed that simply asking a model to reason step by step measurably improves performance on complex problems [1]. ReAct went further and interleaved reasoning with actions, letting the model think, act, observe, and think again [2]. This was the era of the “prompt whisperer.”

And neglecting it has a real cost. A vague prompt produces inconsistent output formats that break whatever parses them downstream. A prompt without constraints produces a confident, well-written answer to the wrong question. A prompt that demands the final answer immediately, with no room to reason, measurably hurts accuracy on multi-step problems. Prompt engineering is real leverage — I want to be clear about that, because what comes next is not “prompt engineering is dead.”

But wording alone has a ceiling. A perfectly worded prompt still cannot supply facts the model was never given. It cannot remember what happened an hour ago. And it certainly cannot govern a multi-hour autonomous run. Which brings us to what surrounds the prompt.

# Context and the context window

As I explained above, how you prompt an LLM matters. But your prompt never arrives alone — it arrives inside a larger body of text, and that larger body is what actually determines what the model can do for you.

Everything the model sees at inference time is its context: the system prompt, your instructions, the conversation history, tool definitions, retrieved documents, previous tool results. The prompt you type is just one slice of it. In the modern framing, the prompt is a subset of the context.

The context window is the maximum number of tokens the model can attend to in a single call — its working memory. And it is bounded for a very physical reason: the self-attention mechanism at the heart of the Transformer computes pairwise interactions between tokens, so compute and memory grow roughly quadratically — O(n²) — with sequence length. Doubling the context doesn’t double the cost; it roughly quadruples the attention computation. A bigger window is, quite literally, more RAM and more compute. Andrej Karpathy’s analogy captures it well: the model is the CPU, the context window is its RAM, and deciding what gets loaded into that RAM is an engineering problem [3].

Here is the counterintuitive part: even inside the window, more is not better. Research has shown that models attend less reliably to information buried in the middle of long inputs — the “lost in the middle” effect [4] — and practitioners consistently observe that performance degrades as the window fills up, a phenomenon that has come to be called context rot [5]. Every irrelevant token you stuff into the window competes for the model’s attention with the tokens that actually matter. Attention is a finite budget, and so is your context.

# Context engineering: the second paradigm

Once you see context as a finite budget, the next discipline names itself.

In mid-June 2025, Shopify CEO Tobi Lütke posted that he preferred the term “context engineering” over prompt engineering, describing it as “the art of providing all the context for the task to be plausibly solvable by the LLM” [6]. Six days later, Andrej Karpathy endorsed it with a sharper definition: “the delicate art and science of filling the context window with just the right information for the next step” [3]. The label went mainstream almost overnight — because it named something practitioners were already doing.

So what is the relation between the two disciplines? Prompt engineering optimizes the wording of a single request. Context engineering curates everything the model sees, at every step: which instructions, which pieces of memory, which retrieved documents, which tool results deserve tokens right now — and, just as importantly, which don’t. Prompt engineering didn’t die; it became one layer inside a larger system.

The benefit is direct: most failures of LLM applications in this era turned out to be context failures, not model failures. The model was capable; it simply never saw the right information, or it saw too much of the wrong information. Context engineering attacks exactly that.

In practice, the discipline developed recurring machinery:

• Memory. Agents need more than the current window. The CoALA paper proposed the taxonomy the field still uses, adapted from cognitive science: working memory (the active context), episodic memory (what happened before), semantic memory (facts about the world and the project), and procedural memory (how to do things) [7].
• Compaction. When a task outlives the window, you summarize the history — compact the trajectory into notes, scratchpads, and progress files — so the agent can keep going without dragging every token behind it [5].
• Tool use. Tools let the model act and fetch rather than merely recall: run code, query APIs, search documents. The Model Context Protocol (MCP), introduced in November 2024, became the de facto standard for connecting models to tools — though every tool definition you add also spends context, so even tooling is a budget decision [8].

# So why isn’t that enough anymore?

Here is where I want to slow down, because this is the turn most explanations skip.

Look back at that list: memory, compaction, tool use. Notice something? None of those are really context. They are machinery that delivers context. A memory store is code. A compaction step is code. A tool call is code. The moment we started building this machinery, we had quietly stopped “writing better inputs” and started building a runtime system around the model.

And once agents began running for hours instead of seconds, the cracks showed. Prompt engineering and context engineering, even done perfectly, do not answer the questions that actually decide whether an autonomous run succeeds:

• Who decides the next action, and on what basis?
• Who verifies that “done” is actually done — and against what standard?
• Who carries state across sessions when the context window resets?
• Who makes sure the mistake the agent made this morning doesn’t happen again this afternoon?

The instinctive answer — “put more instructions in the prompt” — fails in a predictable way, and we have a documented case of it failing at scale. When OpenAI’s team ran an experiment in building an entire production codebase through agents, their first instinct was one big AGENTS.md file: a giant, ever-growing instruction document. It didn’t work. Context is scarce, so a wall of guidance becomes non-guidance; static instructions rot the moment the codebase changes; and nothing verifies whether the agent actually followed them. Their fix was telling: they shrank AGENTS.md to roughly a hundred lines and treated it as a table of contents pointing into a structured docs/ directory — and surrounded the agent with custom linters, structural tests, and a small set of “taste invariants” that are enforced, not merely stated [9].

In other words: the answer to “the prompt isn’t enough” was not a better prompt. It was a better system.

And we now have quantitative evidence that this surrounding system — not the model — can be the differentiator. In February 2026, LangChain’s team took their coding agent from 52.8% to 66.5% on Terminal-Bench 2.0, jumping from around the Top 30 to the Top 5 on the leaderboard, while keeping the model fixed (gpt-5.2-codex). They changed only the system around it: the system prompt, middleware hooks, self-verification checklists, loop detection [10]. Two months later they showed the same effect across model families: tailoring that surrounding system per model lifted GPT-5.3-Codex from 33% to 53% and Claude Opus 4.7 from 43% to 53% on a subset of tau2-bench [11].

Same model. Wildly different results. Whatever changed has a name.

# The harness problem, in one scenario

Before the definition, let me make the problem concrete. The following scenario is my own composition, but it is inspired by the failure patterns that OpenAI and LangChain describe in their write-ups [9][10] — and by ones I have run into myself.

Imagine handing a capable coding agent this task: “Add rate limiting to our public API.”

The model is genuinely smart. It spends the first stretch of the run exploring the repository, opening file after file, burning through its context window just to figure out how the project is organized — because nobody told it. It then writes a rate limiter, and honestly a decent one — except the codebase already contained a throttling utility that it never found, so now there are two. It doesn’t run the integration tests, because nothing told it how, or that it must. Somewhere in the middle it gets stuck in a loop, re-reading the same file and re-trying the same failing edit. Eventually it declares the task complete. It is not complete.

And here is the part that stings: run it again tomorrow, and it will make exactly the same mistakes — because nothing about the system changed.

The model didn’t fail because it isn’t intelligent enough. It failed because it woke up in an unfamiliar building with no map, no house rules, no memory of yesterday, and nobody checking its work. Everything missing from that picture is, precisely, the harness.

# So what is harness engineering?

Let’s assemble the definition from the sources, because the term crystallized fast and in public.

Simon Willison gave us the cleanest definition of the agent itself: “an LLM agent runs tools in a loop to achieve a goal” [12]. A recent large academic survey formalizes the same picture, defining an LLM-based agent as a foundation model coupled with an execution harness, and decomposing that harness into six coupled runtime responsibilities: observation, context, control, action, state, and verification [13]. Industry converged on the same decomposition from the practical side — as LangChain’s Vivek Trivedy put it: if you are not the model, you are the harness [10].

I find it useful to compress all of this into one equation:

Agent = Model + Harness

The term “harness engineering” itself has a datable origin story. On February 5, 2026, Mitchell Hashimoto (of HashiCorp fame) described his personal practice in “My AI Adoption Journey”: whenever an agent makes a mistake, don’t just correct it in chat — “engineer a solution such that the agent never makes that mistake again” [14]. He humbly noted he wasn’t sure the industry had a term for it yet. Six days later, OpenAI published “Harness engineering: leveraging Codex in an agent-first world,” describing how a small team built a production-scale codebase — roughly a million lines of code, with zero manually written lines, at an average throughput of 3.5 pull requests per engineer per day — by deliberately engineering the environment the agents operate in. Their tagline: “Humans steer. Agents execute.” [9]. Birgitta Böckeler of Thoughtworks then gave the discipline its control-theory vocabulary on martinfowler.com: a harness is a system of guides (feedforward controls that steer the agent before it acts — instructions, conventions, environment design) and sensors (feedback controls that observe after it acts and enable self-correction — tests, linters, review agents) [15].

None of these sources, on its own, states a complete definition. So here is mine, composed from all of them:

Harness engineering is the discipline of designing the persistent, deterministic system around a non-deterministic model — the environment the agent wakes up in, the context it is fed, the tools it can act with, the state it carries across sessions, and the verification that decides whether its work is actually done — such that every recurring failure becomes a permanent, structural fix (a guide or a sensor) rather than a one-off correction in chat.

Read it against the scenario above and every clause lands on a failure: the map it didn’t have (environment and context), the tests it didn’t run (verification), the loop it got stuck in (control), the memory it didn’t keep (state), and the mistakes it will repeat tomorrow (the missing ratchet).

Notice also what happened to Act II of our story: memory, compaction, and tool use — the machinery we met under context engineering — reappear here as harness responsibilities. That is not a coincidence. Context engineering told us what the model should see; harness engineering builds and operates the machinery that makes it so, and adds the parts context never covered: control, state, and verification.

# Mapping the SDLC to “full harness capability”

If you ask me what harness engineering ultimately requires — or more specifically, what I think a full-harness-capable system needs — my mental model is to walk the software development lifecycle and ask, at each stage: what must the harness provide so an agent can carry this stage reliably?

Here is my working map, grounded in the references. (I consider this a v1 — I fully expect to revise it as the field moves.)

Two honest caveats belong next to this map. First, every component of a harness encodes an assumption about what the model cannot yet do alone — and those assumptions expire as models improve; both Anthropic and LangChain say this explicitly [17][10]. Some of today’s harness machinery is scaffolding that better models will dissolve. Second, the hard open questions are already named in the research: harness generalization (does a harness tuned for one model transfer to another?) and model–harness co-evolution (how do the two shape each other over time?) [13]. The tau2-bench profile results above suggest the answer to the first question is, today, “not cleanly” — which is exactly why it’s a research frontier.

# Closing

It is still active research, and companies are still working on it. But the through-line of this whole story is simple: we spent 2022 learning to phrase the request, 2025 learning to curate what the model sees, and now we are learning to engineer the system the model lives in. The model provides the intelligence. The harness provides everything that turns intelligence into reliable work.

And if you are curious whether I’m working on something related to “full harness capability”… well, hopefully I will have more to share soon.

---

# References

1. Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022 — https://arxiv.org/abs/2201.11903
2. Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022 — https://arxiv.org/abs/2210.03629
3. Andrej Karpathy, X post on context engineering, Jun 25, 2025 — https://x.com/karpathy/status/1937902205765607626
4. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023 — https://arxiv.org/abs/2307.03172
5. Anthropic, Effective context engineering for AI agents, Sep 29, 2025 — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
6. Tobi Lütke, X post on context engineering, mid-June 2025 — https://x.com/tobi/status/1935533422589399127
7. Sumers et al., Cognitive Architectures for Language Agents (CoALA), 2023 — https://arxiv.org/abs/2309.02427
8. Anthropic, Introducing the Model Context Protocol, Nov 2024 — https://www.anthropic.com/news/model-context-protocol
9. Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, OpenAI, Feb 11, 2026 — https://openai.com/index/harness-engineering/
10. Vivek Trivedy, Improving Deep Agents with harness engineering, LangChain, Feb 17, 2026 — https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering
11. Vivek Trivedy & Mason Daugherty, Tuning Deep Agents to Work Well with Different Models, LangChain, Apr 29, 2026 — https://www.langchain.com/blog/tuning-deep-agents-different-models
12. Simon Willison, on the definition of “agent,” Sep 18, 2025 — https://simonw.substack.com/p/i-think-agent-may-finally-have-a
13. Guo et al., From Question Answering to Task Completion: A Survey on Agent System and Harness Design, 2026 — https://arxiv.org/abs/2606.20683
14. Mitchell Hashimoto, My AI Adoption Journey, Feb 5, 2026 — https://mitchellh.com/writing/my-ai-adoption-journey
15. Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com — https://martinfowler.com/articles/harness-engineering.html
16. Anthropic, Effective harnesses for long-running agents, Nov 2025 — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
17. Prithvi Rajasekaran, Harness design for long-running application development, Anthropic, Mar 24, 2026 — https://www.anthropic.com/engineering/harness-design-long-running-apps
18. Birgitta Böckeler, Maintainability sensors for coding agents, martinfowler.com, May 27, 2026 — https://martinfowler.com/articles/sensors-for-coding-agents.html
19. Dex Horthy / HumanLayer, 12-Factor Agents — https://github.com/humanlayer/12-factor-agents