Harness vs loop engineering vs context engineering

What is a harness?

On its own, a language model takes input and produces text. It cannot run code, carry state from one conversation to the next, or reach anything that appeared after its training. To do those things, it needs a setup built around it: a loop that calls the model again and again, tools it can call, files it is given in every session, and checks that test its output. That setup is called a harness.

Of the sources we read, the broadest definition is in LangChain’s post: “A harness is every piece of code, configuration, and execution logic that isn’t the model itself.” Coding agents run on such a layer too: OpenAI calls the layer that provides the agent loop and execution logic the “Codex harness”, and Anthropic calls the layer that powers Claude Code an “agent harness”.

Harness engineering is the work of designing that setup. We build one ourselves: diffox is an AI code review tool for pull requests. The examples below come from its review pipeline and from the loop it runs over the life of a pull request (a separate post explains how it works).

How the sources define harness engineering

The term is new, and the sources we read define it in different ways. The table gives each source in its own words, with its date.

Source: each post’s own page, 15 October 2026.

Hashimoto describes a habit, and in the same paragraph writes that he does not know whether there is an accepted term for it yet. LangChain draws a boundary instead: everything outside the model is the harness. One tells you what to do; the other tells you where to look.

Two details are not in the table. The formula “Agent = Model + Harness” appears in LangChain’s post, not in Hashimoto’s. And the word “harness” predates the term: on 26 November 2025 Anthropic called the Claude Agent SDK a “general-purpose agent harness”. None of the five Anthropic posts we read uses the phrase “harness engineering”.

What you change at each layer

The four terms are not interchangeable; they are four nested layers. As Anthropic defines them, prompt engineering is about how you write and organise a model’s instructions. Context engineering is about choosing and maintaining the set of tokens in front of the model during inference, including everything that gets there besides the prompt. The context is everything the model sees in that call.

We found no primary source that credits context engineering to one person. The two uses we read are from June 2025: on 19 June Tobi Lütke wrote that he preferred the name to “prompt engineering” (“the art of providing all the context for the task to be plausibly solvable by the LLM”), and on 25 June Andrej Karpathy agreed. Anthropic’s definition is dated 29 September 2025.

Harness engineering sits one layer further out. It is not only about what the model sees; it also designs what happens after the model answers: which checks the output goes through, how the work is split, what changes when a mistake repeats. Each layer contains the one inside it: according to LangChain, today’s harnesses are largely a way of delivering good context engineering. Loop engineering sits one layer further out still. It designs not a single run but many runs over time, and it gets its own section below.

What a harness is made of

The posts we read use different names for the parts. Each of the six groups below appears in at least two sources.

The loop is at the core. Anthropic describes agents as models that use tools in a loop, based on feedback from their environment. In the Agent SDK post, the loop’s steps are: gather context, take action, verify the work, repeat. Tools and observability let the model see the result of its work: in the repository OpenAI describes, the agent can read logs, metrics and traces. Sub-agents split the work; according to Anthropic, each takes on a focused task with a clean context window.

Checks are a separate part, because you write them, not the model. According to the Agent SDK post, the best feedback is a set of clearly defined rules for the output, plus an explanation of which rules failed and why. OpenAI enforces its architectural rules mechanically, with custom linters and structural tests.

What is loop engineering?

A harness is about a single run. Loop engineering asks one more question: who runs the agent, when, and who decides whether the work is done? Addy Osmani gave it its name in a post on 7 June 2026: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

The term grew out of two remarks. The same day, Peter Steinberger suggested designing loops that prompt your agents instead of prompting them yourself. And according to Osmani, Boris Cherny, the head of Claude Code, had said “My job is to write loops”. Neither used the phrase “loop engineering”; the name came from Osmani’s post.

Source: each post’s own page, 15 October 2026.

The sources agree on six parts. The arXiv review lists them as triggered runs, stop conditions a machine can check, persistent state files, verifier sub-agents, token budgets and points of escalation to a human.

• Trigger. What starts a run: a timer or an event.
• Stop condition. A criterion a machine can check to decide the work is done: the tests pass, the list is empty.
• State. The record that carries over from one run to the next; it lives outside the context window.
• Verifier. A checker separate from the agent that does the work.
• Budget. A limit on turns or tokens; once it is reached, the loop stops.
• Escalation to a human. Where work the loop cannot solve lands on a person.

Anthropic’s post shows three of the parts working together. Each time Claude Code tries to stop, a separate evaluator model checks the condition. It sends Claude Code back to work until the goal is met or the number of turns you set is reached. As Osmani puts it, the agent that wrote the code is then not the one grading it.

The sources disagree on one point: which loop is “the loop”? The review separates the two. In the agent loop, the model calls tools within a single run and acts on the results; that loop is part of the harness. Loop engineering deals with the structures that start, check and restart those runs over time. Some vendor posts use the word in the first sense, and Anthropic’s engineering blog also defines the harness as “the loop that calls Claude”. In this post, loop has the second meaning.

The term itself has not settled yet either. The same review says it is still open whether loop engineering is a new discipline, a passing technique or a marketing label. In July 2026 a successor was even proposed, under the name “graph engineering”.

What a harness looks like in a code review tool

diffox’s review pipeline shows how the parts fit together. A pull request goes through four stages before it turns into comments, and each stage shows one idea of the harness.

Context & routing is what the harness gives the model before it starts work. The specialist agents get four things: the diff, the files before and after, the pull request’s description and, if your repository has one, its rules file (AGENTS.md or CLAUDE.md). The rules file is read from the branch the pull request will merge into, not from the pull request’s own branch, so a pull request cannot change the rules of its own review. No instruction in a prompt guarantees that; where the file is read from does.

Specialist review is where the work is split up. “Is there a bug in this?” is a broad question, so diffox has specialist agents read the same change. There are 17 of them on the team, each with its own instructions and each looking for one thing: one for logic errors, one for concurrency problems, one for a test that tests nothing.

The harness also decides what the output looks like. A finding only counts if it says three things: what it claims, what goes wrong and when, and the code the claim rests on, quoted verbatim. Agents do not give line numbers; diffox finds the line itself by searching the file for the quote.

Select & publish is a separate step. Every finding has a class: Critical, Warning or Suggestion. The pull request gets what you need to fix, that is critical findings and warnings. Suggestions wait on the Findings page in the console for a while, and you can publish any of them from there. A review never blocks a merge.

A check the model cannot talk its way past

The third stage, Evidence checks, is where the harness idea shows most clearly in this example. A language model can write something convincing but wrong: it quotes a line that is not in the file, objects to code the pull request did not touch, or raises the same problem three times in three different sentences. This stage ties every finding to the file itself rather than to the model’s word.

The checks are plain code, not a model call: the same input gets the same answer every time.

• The finding’s quote is looked up in the file. A quote that is not there has no line to point to. If it is found on a line the pull request did not change, the finding is out of scope.
• Findings that raise the same objection at the same place are merged into one.
• If a finding says the code contradicts some text, its second quote is looked up word for word as well.

The model cannot argue with the quote check, because the check weighs no arguments; it just looks for the quote in the file.

You can also have one model check another, but the result is still a model’s judgement. Anthropic writes that in early runs its evaluator model found real issues, then talked itself into deciding they did not matter and approved the work anyway. That is why testing in code whatever can be tested in code is a separate part; questions that need judgement stay with the model.

In a small project, the same idea takes a few lines. The example below is not diffox’s code; it only shows the pattern.

# EXAMPLE: searches the file for the quote the model gave
def quote_exists(finding: dict, files: dict[str, str]) -> bool:
    quote = finding.get("quote", "").strip()
    source = files.get(finding.get("file", ""), "")
    return bool(quote) and quote in source

The loop that runs over a pull request

A single review goes through a harness; a pull request goes through many reviews. Code gets written, diffox reviews it, the code changes and is pushed again. Whether a person or a coding agent writes the code, that is a loop, and each of its six parts has a counterpart in diffox’s code.

The real lesson of this loop is in two choices. First, the verifier does not treat a change as a success. When a finding’s lines change, the comment only gets a note saying which commit changed them. It never says “fixed”, because rewritten code can still contain the bug. A paper from June 2026 sets the same condition for its stopping rule: never mistake an error for a success.

Second, you choose the stop condition. Automatic reviews stop at a per-pull-request limit, which you can change in the console’s Settings tab. After that, you ask for a new review by mentioning diffox in a comment. The merge decision is yours too: a review never blocks a merge. That is where the loop hands over to a human.

How a harness grows out of mistakes

A harness is not built once and left alone. Hashimoto describes two routes: a line in the rules file for simple mistakes, and a tool written in code for the rest. He writes that every line in his own project’s rules file came from something an agent did wrong.

OpenAI’s post describes the same loop inside a team: Codex writes all of the product’s code, and the engineers build the environment. When the agent struggles, they treat it as a signal: they find the missing tool, guardrail or document and add it to the repository. When documentation is not enough, they move the rule into code. They keep the rules file short: an AGENTS.md of about 100 lines, a table of contents rather than an encyclopedia.

It works the other way too. According to Anthropic, every part of a harness encodes an assumption about what the model cannot do on its own, and those assumptions can go stale as models improve. When a new model arrives, the harness is re-examined and any part that is no longer load-bearing is removed.

Building this tool, we picked up three habits from this loop in our own repository:

• Every rule is written down with the mistake that led to it. A rule with no reason beside it gets deleted by the first person it bothers.
• We trust a test only after we have seen it turn red with the fix reverted. A test that tests nothing is green too.
• When we change a check written in code, we rerun its old and new versions over stored results. No new paid run is needed, and we see every case where the two versions disagree, one by one.

Where to start in your own project

To start, you do not need to pick a framework or switch models. A harness already runs inside the coding agent you use; you add your own project’s parts to it.

First notice the mistake, then pick the cheapest fix. For a simple mistake, that is a line in the rules file. If the mistake keeps happening despite the rule, move the rule into code: a linter rule, a test, a script. Anthropic’s general advice applies here too: find the simplest solution, and add complexity only when you need it.

The same order applies to your first loop: first make sure a single run is reliable, then write the stop condition and its limit. Anthropic’s advice is clear: stop when the goal is reached or the maximum number of turns is hit. To keep token usage under control, a loop needs clear boundaries.