Workflow diagrams
Harness Engineering Explained in 20 Mins!
Section 2 · What a harness is — and why a model alone cannot do real work
1. The Horse and the Harness: Raw Power into Directed Work
A horse is powerful and fast — but raw power is not useful work. The harness is the equipment that converts raw power into directed work. In this analogy the model is the horse, and the harness is everything you build around it.
A frozen set of weights
A bare LLM, by itself
- Has no persistent state
- Cannot execute code
- Cannot read a file or make an API call
- Cannot verify its own output
A pure function: tokens in, tokens out.
The plumbing around the model
The same model, in a harness
- Tools and call schemas
- Context loaded per run
- Checks on its outputs
- Permissions and guardrails
- Logging and memory
Directed, useful work — everything you experience as “AI doing useful work”.
!
Better results without a better modelIn a clean experiment, one engineer improved the coding performance of 15 different LLMs in a single afternoon — without touching a single model. Same weights, better environment, measurably better results.
Section 2.3 · Where harness engineering sits next to prompt and context engineering
2. Three Disciplines: Prompt, Context, and Harness Engineering
Prompt engineering optimizes a single exchange. Context engineering manages what the model can see. Harness engineering covers everything else that keeps the horse on the track — the gap the other two disciplines do not fill.
Layer 1 of 3
Prompt engineering
What you say to the horse — one instruction, one output.
▼
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 — the deliberate design of the execution environment for long, unsupervised runs.
Section 3 · Finding the harness in the ChatGPT desktop app
3. Chat, Work, and Codex: Three Harnesses in One App
The same underlying model family behaves like three completely different products depending on which environment it runs in. The headline shipment was not a new model — it was a heavier harness.
Chat
thinnestTurn-by-turn conversation — still a harness, just tuned thin.
Work
heavierThe same app with a toggle flipped — now you are talking to an agent.
Codex
heaviestBuilt for autonomous engineering — every capability scoped, logged, and looped.
!
Approval checkpoints deserve attentionThey are a guardrail — a harness component placed by an engineer who decided the agent should stop at exactly that point rather than guess. This detail returns when the five components are laid out.
Section 4 · The five components of a production-grade harness
4. The Five Components of a Production-Grade Harness
Whenever you use Chat, Work, or Codex — or Claude Code on the Anthropic side — you are a harness customer. Almost every production system uses some combination of these five components, and you feel it when one is missing.
Component 1 of 5
1
System of record
How the agent should work, written down where the agent works — not in Slack threads.
2
Tools
What the agent can actually do — a small, deliberate set you can justify for each one.
3
Feedback loops and verification
The component most people skip: a way to check its own work without asking you.
4
Guardrails and permissions
What the agent is explicitly not allowed to do — and at what point it stops and asks.
5
Observability and memory
A record of every tool call and decision, plus useful state carried across sessions.
!
Component 4, at product scaleThe approval prompts in ChatGPT's Work experience are exactly this component — designed at OpenAI scale. Every serious agent tool exposes these settings, and most people never touch them. Set them deliberately.
Section 4.3 · Feedback loops and verification — and Step 2 of the roadmap
5. The Verification Loop: An Agent That Checks Its Own Work
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 ever look.
Step 1 of 6
1 · Plan
Break the goal into steps
→
2 · Act
Edit, run, call — take an action
→
3 · Verify
Checks fire after every change
→
4 · Hand off
Work returns to you
✕ a check fails
↺Fixthe agent corrects its own work, then verification reruns
Press “Run the loop” to walk one full cycle — a failing check, a fix, and a clean hand-off.
↺
Why this mattersAgents should discover their own mistakes before you do. Define what correct output looks like, write a script or checklist that validates it, and make that check part of every single run — with hooks, not by relying on the agent to remember. If your agent is not writing code, the principle still holds: the check just takes a different shape.
Section 5 · A five-step roadmap to building your own harness
6. The Five-Step Roadmap: From One File to One Workflow
Theory is useful — but this roadmap is meant to be worked through week by week, and it ends with a graduation project: one narrow workflow running end to end without you babysitting it.
Step 1 of 6
1
Create your system of record — this week
Write down how the project is structured, how to run it, how to test it, and your top five conventions — under a page. In Codex it is AGENTS.md; in Claude Code it is CLAUDE.md (the /init command writes a starting point). Then adopt Hashimoto's rule: when the agent makes the same mistake twice, do not explain the fix in chat — write it into the file permanently.
2
Build a verification loop
A linter like Ruff plus a handful of real tests in Python — the same idea with standard tooling in JavaScript. Configure the checks to fire after every single change, e.g. with Claude Code hooks, so they run automatically instead of relying on the agent to remember.
3
Choose tools deliberately
Spend a week inside one serious existing harness — Claude Code or Codex — and study when it asks for permission, how it uses the instruction file, how it runs tests. Then connect one real system you use daily via MCP, and for every connection ask the harness question: what is the worst thing the agent could do with this access — and how have I prevented it?
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 — the single highest-leverage habit in the whole video. Every failed run tells you exactly which piece of the harness to build next.
5
Build one complete harness for one narrow workflow
The graduation project. Pick one repetitive, well-defined task you will do every single week and build the full loop around it: instruction file, a small set of tools, automated verification, clear permissions, and logging.
✓
Outcome
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 you.
↺
Step 4 feeds back into steps 1–3Each failed run names the next piece of the harness to build: a missing instruction, a missing check, or a tool the agent should never have had access to. As the video puts it — your harness roadmap is written in your failure logs.