Harness Engineering, Explained: What It Adds to Prompts and Context

Three terms now compete for the same job: prompt engineering, context engineering and harness engineering. Read enough posts and each one sounds like it replaces the previous one. I read the primary sources, in date order, to see what is actually claimed and where the authors disagree.

Short version: they are three scopes of the same effort, and in my reading the newest one, the harness, is the part that makes a correction stick.

Transcript

Prompt, context, harness: every week someone says the newest term replaces the others. It doesn't. In my reading, they're three scopes of one job. The words of one instruction. Everything the model sees. And the system around it, which decides what goes in and checks what comes out. The earliest use of the newest term that I found is Mitchell Hashimoto, on the fifth of February twenty twenty-six. His rule: whenever the agent makes a mistake, engineer a fix so it never makes that mistake again. A better prompt helps once. A rule in your agents file helps most sessions. A test that fails the build helps every time. Birgitta Böckeler at Thoughtworks splits a harness in two. Guides steer before the agent acts. Sensors check after. With only guides, you never learn whether the rules worked. With only sensors, the agent keeps repeating the same mistakes. The sources don't agree on which one contains which, so those neat rings are a simplification. Every source is in the blog post, and the full breakdown is in the video linked below. Next: agents file, skills, or MCP.

Watch the full 9-minute video on YouTube: https://youtu.be/5DALkKtFEKo.

Three scopes, one job

A simple way to hold the three terms apart is by what you are controlling:

• Prompt engineering is the words of one instruction.
• Context engineering is everything the model can see at one step: the prompt, the conversation so far, retrieved documents, tool definitions and tool results. Anthropic's engineers describe it as curating the optimal set of tokens at inference time, and call it the natural progression of prompt engineering.
• Harness engineering is the system around the model that decides what goes into that context, what the agent may do, and whether its output is accepted, over many steps.

Who said what, and when

Many explainers skip this part. Dates are from the pages I read, except where marked.

Date	Who	What
18 Jun 2025 (approx.)	Tobi Lütke	Says he prefers "context engineering" to "prompt engineering".
25 Jun 2025 (approx.)	Andrej Karpathy	Endorses the term. Simon Willison's 27 Jun 2025 post collects both.
29 Sep 2025	Anthropic	"Effective context engineering for AI agents" calls it the natural progression of prompt engineering.
26 Nov 2025	Anthropic	"Effective harnesses for long-running agents" calls its Agent SDK an agent harness and describes scaffolding for long-running work, without a formal definition.
5 Feb 2026	Mitchell Hashimoto	In "My AI adoption journey", names engineering the harness as step five.
11 Feb 2026	OpenAI	"Harness engineering: leveraging Codex in an agent-first world".
17 Feb 2026	Birgitta Böckeler	A first-thoughts memo on martinfowler.com.
10 Mar 2026	LangChain	"The Anatomy of an Agent Harness" defines a harness as everything except the model.
2 Apr 2026	Birgitta Böckeler	The full article: guides, sensors and the user-built harness.

Two notes on this. The Lütke and Karpathy dates are decoded from the IDs of the posts that Simon Willison links, so treat them as approximate. And the OpenAI page refused my fetch tool, so what I know about it comes from InfoQ and from Böckeler's description. The headline numbers in that post, about a million lines of code and about 1,500 pull requests, are OpenAI's own and I have not checked them.

What Hashimoto actually meant

Hashimoto's definition is the most practical of the lot, and it is a practice, not an architecture. When an agent makes a mistake, engineer a fix so that it never makes that mistake again. He gives two forms: a line in AGENTS.md that answers each bad behaviour, and small scripted tools, such as one that takes screenshots or runs only the relevant tests, paired with a note telling the agent they exist. He also says he is not sure an industry term exists yet.

That one idea is what separates harness engineering from the other two. A better prompt helps once. A better context helps for a task. A fix written into the repository helps every time.

Guides and sensors

Böckeler's article gives the clearest vocabulary for what a harness contains. She writes that an agent is a model plus a harness, and that the engineering effort you control is the outer layer built for your own project. That layer has two kinds of controls:

• Guides act before the agent does anything: AGENTS.md, skills, code mods. They steer.
• Sensors act after: linters, structural tests, AI review. They check.

Each can be computational, meaning deterministic code such as a linter, or inferential, meaning another model making a judgment. Her argument is that you need both directions. Guides alone never find out whether the rules worked. Sensors alone leave the agent repeating the same mistakes.

Where the sources disagree

Here the sources contradict each other, and the three-rings picture hides it.

• On which contains which, Böckeler's February memo, describing OpenAI's setup, lists context engineering as one of three harness components. Her April article says that engineering a user harness is a specific form of context engineering. LangChain calls harnesses largely delivery mechanisms for context engineering, yet its harness also includes tools, sandboxes and orchestration.
• On what counts as a harness, LangChain says everything that is not the model. Anthropic has no formal definition, though it calls its own Agent SDK an agent harness. Böckeler means only the layer a team builds on top of a tool's built-in harness, and Hashimoto means a practice.
• Is prompt engineering dead? Anthropic calls context engineering a progression, not a replacement. Simon Willison's June 2025 post argues that "context engineering" names the skill better than "prompt engineering". None of the pages I read says prompting no longer matters. The "prompting is dead" line comes from secondary posts I did not cite.

My reading, labelled as such: the layers overlap. A lot of harness work is feeding the right information into the model, which is context engineering. But a harness also does things that are not context at all, such as sandboxing, permissions, deterministic checks in CI and retries.

Which fix is it? A decision procedure

This is the part I would use on a Monday. When an agent gets something wrong, ask three questions in order.

1. Was it a one-off? If the instruction was unclear, fix the prompt. That is the cheapest fix.
2. Did the model lack information? If it could not see something it needed, or it was buried in noise, fix the context: load the right file or trim a bloated tool list.
3. Will it happen again? If the same mistake keeps coming back, add a harness control. Pick a guide if you can tell the agent in advance, such as a line in AGENTS.md, or a sensor if you can only catch it afterwards, and prefer a deterministic check over another instruction. The same AGENTS.md line is context when you write it for one task and a guide when you keep it so the mistake cannot recur.

1. Agent makes a mistake→
2. One-off? Fix the prompt→
3. Missing information? Fix the context→
4. Keeps recurring? Add a guide or sensor

An illustration, not a real repository: the agent keeps running the wrong test command. Telling it in the prompt works today. Putting the command in AGENTS.md is better. A pre-push hook that runs the right tests and fails the push if they do not pass means it no longer matters what the agent remembers. A local hook can still be skipped, for example with git push --no-verify, so run the same check in CI as well.

Examples of each. Most come from the sources named in this post; the first two prompt items are common practice, not a quote from any of them.

• Prompt: give a few diverse, canonical examples instead of a long list of edge cases, which is Anthropic's advice. Common practice adds a stated reason for each rule and a request to say when the model is unsure.
• Context: just-in-time retrieval instead of preloading, compacting a nearly full window, structured notes in a file, a sub-agent that returns a short summary, fewer and less overlapping tools.
• Harness: a custom linter that rejects bad code, structural tests that enforce architecture, a progress file the agent reads at the start of each session and a feature list where the agent may only flip a pass or fail flag after a real test run (both from Anthropic's November 2025 post), and a separate evaluator agent instead of letting the agent grade its own work (Anthropic, March 2026).

Common mistakes

The sources name several. Declaring victory early, or marking a feature done without testing it, is one Anthropic describes in its November 2025 post. Letting the agent edit the tests is another. Böckeler warns against trusting AI-generated tests as your check on behaviour, because they are not yet good enough. And a harness with only guides or only sensors fails in the ways described above.

A harness is not permanent

Anthropic's March 2026 post on long-running application development makes a point worth remembering: every piece of a harness encodes an assumption about what the model cannot do on its own. When the model improves, some of those assumptions go stale. Their advice is to re-test and strip out parts that are no longer needed. Put a date in your calendar to do that at the next model release. In that post Anthropic compared a single agent run against its full harness on one task: the solo run took 20 minutes and cost about $9 and the app was broken, while the full harness took about six hours and cost about $200 and worked. That is Anthropic's own test on one task, so read it as an illustration, not a benchmark.

What to do on Monday

1. Keep a list this week of every mistake your agent repeats.
2. For each one, take the cheapest fix that works: a line in AGENTS.md, then a script, then a check.
3. Add one deterministic sensor, such as a linter or test run, in a pre-commit or pre-push hook.
4. Make "done" testable: the agent may only mark something finished after a real run.
5. Use a separate reviewer, a second agent or a person, instead of letting the agent grade itself.
6. Trim your instruction file, and pick one number before you start, such as failed CI runs or rework, so you can tell whether it helped.

What the evidence does and does not show

A February 2026 study of 2,853 GitHub repositories (arXiv 2602.14690) found that context files were the most common way teams configure coding agents, while skills and sub-agents were rare. It measures how often teams use these controls, not whether they work. I did not find a study that shows harness engineering improves outcomes in general, and OpenAI's and Anthropic's own numbers are self-reported.

Further reading

• Mitchell Hashimoto, My AI adoption journey, 5 February 2026: step five, the earliest use of the term I found.
• Birgitta Böckeler, Harness engineering: first thoughts, 17 February 2026, and the full article, 2 April 2026.
• Vivek Trivedy, The Anatomy of an Agent Harness, LangChain, 10 March 2026.
• Anthropic, Effective context engineering for AI agents, 29 September 2025.
• Anthropic, Effective harnesses for long-running agents, 26 November 2025, and Harness design for long-running application development, 24 March 2026.
• OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026.
• Simon Willison, Context engineering, 27 June 2025.
• Galster et al., Harness Engineering for Agentic AI Coding Tools: An Exploratory Study, arXiv, February 2026.
• My own articles: What Is a Harness Engineer?, AGENTS.md: One Rulebook for Cursor, Claude Code and Codex, and the sequel, AGENTS.md, Skills or MCP: What Each One Is Actually For.