Harness engineering is the discipline of designing everything that surrounds the model: the instructions, tools, context, permissions, execution environment, and feedback loops that determine what a coding agent can see, do, check, and recover from.

OpenAI named the practice in February 2026, describing how it prepared specifications, tools, feedback, and repository structure around Codex rather than tuning the model itself. Ryan Lopopolo's AI Engineer talk gives the operator's account of the same preparation. The field had been converging on the idea — Anthropic's guidance on effective agents treats the agent as model-plus-scaffolding, and HarnessTax then measured the harness as a variable in its own right.

Why the harness is a product decision

The same model produces different outcomes under different harnesses. HarnessTax compared 21 model–harness pairs on SWE-bench Lite and Terminal-Bench 2.0 and reported roughly a five-fold spread in token cost for comparable task success — a bounded result (two benchmarks, one-attempt scoring), but enough to show the wrapper is not a neutral detail. The harness moves cost, failure shape, and what a reviewer must still check.

That makes the harness a choice with an owner, not an inherited default. A team can accept its provider's wrapper, adopt a minimal open harness such as Pi — four tools: read, write, edit, bash — or engineer its own for a specific work class. The right answer depends on the work, the risk, and the evidence the team can produce.

What the harness includes

  • Instructions and skills — the standing guidance and versioned recipes the agent loads.
  • Tools — what the agent can actually do: read, write, run tests, open tickets, query internal systems.
  • Context engineering — which code, decisions, and rules the agent sees, and what stays out.
  • Permissions and environment — the sandbox, credentials, spend limits, and stop conditions.
  • Feedback and evals — the checks that let the agent prove its own work before a person is asked.

What harness engineering is not

It is not prompt engineering alone — a prompt is one instruction inside a much larger system. It is not model selection — the model is a component the harness routes around. And it is not sufficient by itself: the AI Engineer counterpoint Harness Engineering Is Not Enough argues that faster generation still needs architecture, review, maintainability, and human judgment around it. A Smol News scan of harness-level evaluation and secure execution shows the same boundary from the tooling side.

Where it fits in a software factory

In SWFT's working architecture the harness is one layer of the factory: it determines how well a worker executes a task brief, while intake, proof, release, and the learning loop decide which work deserves a run at all. For the cost angle, read HarnessTax as a factory cost lever; for the surrounding system, read How an AI software factory works.