Harness engineering
The harness is everything in an agent except the model itself. Agent equals model plus harness. Birgitta Böckeler put the definition on the record in a martinfowler.com piece, and by late 2026 the term has converged from three directions at once: Quenneville’s Rails World talk named the discipline, OpenAI published an internal write-up under the same title https://openai.com/index/harness-engineering, and the Pi Durable release shipped it as vocabulary (“a harness is storage plus the machinery needed to run one or more conversations with large language models in parallel”, https://earendil.com/posts/pi-durable/).
The two by two
Quenneville’s contribution is a grid. Controls sit on either side of the agent loop, and they come in two kinds:
| Computational (deterministic) | Inferential (judgment) | |
|---|---|---|
| Feed-forward | generators, scaffold templates, project-specific scripts | AGENTS.md, skills, prompts |
| Feedback | compilers, type checkers, linters, test suites, hooks | self-review, agent reviewers, focused review skills |
Two rules make the grid work. The first: an agent treats a README as a suggestion and a harness as a rule, so any constraint that matters belongs in a tool, not in prose near the tool. The second, Quenneville’s ladder: prefer a deterministic control; when one does not exist, ask the model to configure one and then run it; reserve inferential checks for the code where being wrong does not look wrong. The Rust case reads as the grid too: rustc is an unusually strong computational feedback control, and newtypes or type-state patterns are feed-forward guidance that points the agent at it. See rust-for-agents.
The reactive system
The inversion of the chatbot frame: “when your reaction to mediocre code is to fix the harness rather than the mistake” (session abstract). A disappointing agent output is a signal about missing controls, which is the same reading Poteto gives the buzzword software factory. See environment-and-constraints, michelin-kitchen-metaphor. This is also why the vault gates itself the way it does: just lint blocking a commit is the harness, and prose telling the agent to write good prose is the README. See determinism-extraction, verifiability-and-one-way-doors.
The failure mode at the edge of the frame: when the harness itself is the product, engineering judgment becomes the scarce input, and the craft claim from the Pi release carries it. “Everyone can generate code now, not everyone can software engineer” (2026-10-12-youtube-indydevdan-pi-durable, 24:14). See skills-as-process.
What it is not
It is not prompt engineering with a better brand. The distinction Quenneville keeps drawing is between steering one generation and engineering the loop that runs hundreds of them. It is also not the scaffolding-vs-substitution scaffolding, which is about what AI does to a learner’s skill; harness engineering is about what the engineer builds around the model. The two meet at agent-verification-skill. A verification skill is a harness component that the agent can run.
Sources
- Rails World 2026 session abstract and indexed talk summary, via 2026-09-24-quenneville-harness-engineering-rails-world.
- Earendil, “Pi Durable”, harness definition, 2026-10-01: https://earendil.com/posts/pi-durable/
- Daniel Demmel, “Feedback loop engineering”, citing Böckeler, 2026-01-31: https://www.danieldemmel.me/blog/feedback-loop-engineering
- OpenAI, “Harness engineering: leveraging Codex in an agent-first world”: https://openai.com/index/harness-engineering