Harness Engineering
Harness Engineering
Explained in 20 Minutes
Why the teams shipping the most impressive AI systems call the model "the easy part" — and why the layer built around it, not the model itself, is where dependable, directed work actually comes from.
Source: youtube.com/watch?v=bsmUh5bTNZ4 · Channel: Aishwarya Srinivasan (@aishwaryasrinivasan) · Article + transcript in this repo
Agenda
What We'll Cover
The Idea
- The model is the easy part — the Codex story
- What a harness is: the horse and the harness
- Why a model alone can't do real work
- Prompt vs context vs harness engineering
- Where the term came from — and the 15-model experiment
In Practice
- Finding the harness in the ChatGPT desktop app: Chat, Work, Codex
- The five components of a production-grade harness
- A five-step roadmap to build your own
- Closing argument: the model is the commodity, the harness is the product
Section 1 · Where Value Is Really Created
The Model Is the Easy Part
"Which model should we use?" is the wrong question. The hard part — and the part where value is actually created — is everything wrapped around the model.
The Codex story
A three-person team started from an empty repository in late August 2025 and wrote no code themselves for five months. They ended up with a million lines of production code and 1,500 merged pull requests — every line of it generated by Codex, their coding agent.
What they obsessed over
Not the prompt, and not even the model. It was the harness: the execution environment that made the agent's work possible, reviewable, and safe.
Section 2 · What a Harness Is
The Horse and the Harness
A horse is powerful and fast — but raw power is not useful work. Without a harness it cannot pull a cart or plow a field. The model is the horse; the harness is everything you build around it.
Bare model alone
A frozen set of weights mapping tokens to tokens — a pure function: tokens in, tokens out. That is the entire interface.
Same model in a harness
Directed, useful work. Boiled down: the harness is the plumbing around the model.
Section 2 · Where Harness Engineering Sits
Prompt, Context & Harness Engineering
Three disciplines, each governing a bigger span — from a single exchange to the whole autonomous run.
Prompt engineering
What you say to the horse.
One instruction, one output. It optimizes a single exchange.
Context engineering
What you let the horse see.
What gets retrieved and what fits inside the context window.
Harness engineering
Everything else that keeps the horse on the track.
Which tools the agent gets, where its information comes from, how it validates its own work, and when it stops and hands control back to a human.
Neither prompt nor context engineering addresses what happens when an agent runs autonomously for hours and makes hundreds of decisions without supervision — that gap is exactly what harness engineering fills.
Section 2 · Origins & Evidence
A Term That Spread in Weeks
Better results without a better model
One engineer took 15 different LLMs and improved the coding performance of all of them in a single afternoon — without touching a single model. The only thing that changed was the harness. Same weights, better environment, measurably better results.
Section 3 · The ChatGPT Desktop App
Three Harnesses in One App
In July 2026, OpenAI merged the Codex app and the ChatGPT app into one desktop application with three experiences. The headline shipment that day was not a new model — it was a harness.
Chat — thin harness
System prompt, web search and a few tools, memory across sessions, sandboxed Python — tuned for turn-by-turn conversation.
Work — heavier harness
Planning loop, connectors that take actions, approval checkpoints, scheduled tasks — an agent that runs for hours to produce finished work.
Codex — heaviest harness
Scoped folder access, AGENTS.md conventions, a real terminal for builds and tests, inline diffs and PR review — autonomous coding.
The same underlying model family behaves like three completely different products depending on which environment it runs in.
Section 3.1 · Chat — A Thin Harness
Even a Chat Window Is a Harness
Chat feels like just talking to a model — but a thin harness is at work, tuned for the conversations that happen in a chat window.
Section 3.2 · Work — A Heavier Harness
Work: You're Talking to an Agent, Not a Model
The same application with a toggle flipped: Work gathers context from your files and connected applications, decomposes a goal into steps, and runs for hours to produce finished documents, spreadsheets, and presentations. The model's raw capability did not change — the harness got heavier.
Planning loop
A goal is decomposed into steps the agent works through.
Connectors
Links into your actual tools, with the ability to take actions across them.
Approval checkpoints
The agent pauses before doing anything consequential.
Scheduled tasks
Work that keeps running even after you walk away.
Approval checkpoints are a guardrail placed by an engineer who decided the agent should stop at exactly that point rather than guess — a detail that returns in the five components.
Section 3.3 · Codex — The Heaviest Harness
Codex: Scoped, Logged, Wrapped in Feedback
The heaviest harness of the three — and, for technical viewers, the most instructive.
Every capability is scoped, logged, and wrapped in a feedback loop.
Section 4 · Anatomy of a Production-Grade Harness
The Five Components
Whenever you use Chat, Work, Codex, or Claude Code, you are a harness customer — someone else engineered that environment for you. Almost every production system uses the same five components, and you feel it if one of them is missing.
Section 4.1–4.2 · Components 1 & 2
The System of Record & the Tool Set
1 · System of record
Instruction files — CLAUDE.md or AGENTS.md in the project root: plain Markdown the agent reads before working, holding project structure, conventions, build commands, and the decisions your team has already made.
The OpenAI team hit this trap directly: without written answers, the agent guesses — and guesses wrong, repeatedly. Knowledge in Slack threads and Google Docs might as well not exist; the agent cannot really see it. Everything the agent needs has to live where the agent works.
2 · Tools
What your agent can actually do: run shell commands, edit files, search the web, query a database.
Most people fall into one of two extremes:
- Access to everything → behavior becomes unpredictable
- Access to almost nothing → the agent talks but doesn't act
Good harness design sits in between: a small, deliberate set where you can justify why the agent needs each tool.
Section 4.3–4.5 · Components 3–5
Checks, Limits & the Record
3 · Feedback loops & verification
The component most people skip — and you should not. An agent needs a way to check its own work without asking you. In code that machinery already exists: a linter, a type checker, or a real test suite that runs automatically after every change, so the agent observes its own failures and fixes them before you even look at the output.
4 · Guardrails & permissions
What the agent is explicitly not allowed to do: which parts are read-only, which commands require approval, at what point it stops and asks instead of guessing. The approval prompts in ChatGPT's Work experience are this exact component at OpenAI scale. Every serious agent tool exposes these settings — most people never touch them.
5 · Observability & memory
Observability is a record of everything the agent did — every tool call, every decision, every error. Memory carries useful state across sessions, because the model itself cannot carry anything. When a run goes wrong — and it will — the record is the only way to reconstruct what happened, instead of guessing.
Section 5 · A Five-Step Roadmap
From One File to One Workflow
Theory is useful, but how do you actually go build one? The roadmap is meant to be worked through week by week.
The roadmap is not linear forever: each failure names the next fix, and your harness roadmap is written in your failure logs.
Section 5.1–5.2 · This Week
Step 1: The File. Step 2: The Loop.
Step 1 — create your system of record
Codex (CLI or desktop tab) and Cursor read AGENTS.md at your repository's root automatically; Claude Code reads CLAUDE.md — the /init command generates a starting point.
Write down four things: how the project is structured, how to run it, how to test it, and your top five conventions. Keep it under a page.
Step 2 — build a verification loop
In Python: a linter like Ruff plus a handful of real tests; the same idea applies in JavaScript with standard tooling. Configure the agent to run checks after every change — in Claude Code, hooks fire them automatically instead of relying on the agent to remember.
Not writing code? Define what correct output looks like, write a script or checklist that validates it, and make it part of every run.
Section 5.3–5.5 · Steps 3–5
Study a Harness, Read Failures, Graduate
Step 3 — choose tools deliberately
Spend a week inside one serious existing harness — Claude Code or Codex — and study how it behaves: when does it ask for permission, how does it use your instruction file, how does it run your tests?
Then connect one real system you use every day, via MCP. For every connection ask the harness question: "What is the worst thing the agent could do with this access — and how have I done anything to prevent it?"
Step 4 — read your failures
Turn on whatever logging your agent tool provides. When a run goes wrong, read through what the agent did, step by step. It might sound tedious — it is the single highest-leverage habit in the entire video.
Every failed run tells you which piece to build next: a missing instruction, a missing check, or a tool the agent should never have had. Your harness roadmap is written in your failure logs.
Step 5 — one narrow workflow
The graduation project: pick one repetitive, well-defined task you do every single week and build the full loop around it — an instruction file, a small set of tools, automated verification, a clear set of permissions, and logging.
One workflow, end to end, running reliably without you babysitting it. Do that once and you understand the discipline at a level no blog post can teach.
Key Takeaways
The Complete Checklist
Closing Argument
The Model Is the Commodity,
the Harness Is the Product
In 2026 and 2027 everyone has access to roughly the same frontier intelligence — especially with open-source models. What you actually compete on is the environment you build around the model.
Source: "Harness Engineering Explained in 20 Mins!" — Aishwarya Srinivasan (youtube.com/watch?v=bsmUh5bTNZ4) · Channel: youtube.com/@aishwaryasrinivasan · Full article in this repo