Aishwarya Srinivasan · 20-Minute Explainer
Harness Engineering
Explained in 20 Minutes
Why the teams shipping the most impressive AI systems say the model is the easy part — and why the harness, the entire layer built around the model, is what turns raw model power into dependable, directed work.
Source: youtube.com/watch?v=bsmUh5bTNZ4 · Channel: youtube.com/@aishwaryasrinivasan
Agenda
What We'll Cover
The Core Idea
- The model is the easy part — the OpenAI story
- The horse and the harness: what a model can't do alone
- Prompt vs context vs harness engineering
- A term that spread in weeks — with proof
In Practice
- Harnesses inside the ChatGPT desktop app: Chat, Work, Codex
- The five components of a production-grade harness
- A five-step roadmap to build your own
- Why the harness — not the model — becomes the product
Part 1 · The Model Is the Easy Part
They Wrote No Code for Five Months
The OpenAI story
A three-person team started with an empty repository in late August 2025 — and wrote no code themselves for five months.
- A million lines of production code
- 1,500 merged pull requests
- Every line generated by Codex, their coding agent
What they obsessed over
Not the prompt, and not even the model — the harness.
They focused on the execution environment that made the agent's work possible, reviewable, and safe.
Instructor context: Aishwarya Srinivasan — 10+ years in ML/AI as a data scientist at Microsoft, Google, and IBM; master's in data science from Columbia; developer-relations lead at Fireworks AI; co-founder of Gen Academy. Harness engineering builds on her earlier loop-engineering and context-engineering explainers.
Part 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 harness converts raw power into directed, useful work.
The model is the horse
Raw capability, no direction on its own.
Powerful and fast — but unable to do useful work unless something wraps it and directs it.
The harness is everything you build around it
- The tools it may call and the schemas for calling them
- Information piped into its context before each run
- Checks that run on its outputs
- Permission boundaries — what it can touch
- Logging that records what it actually did
Part 2 · What a Harness Is (cont.)
A Bare LLM Is a Pure Function
Strip away the product around the model and what remains is a frozen set of weights mapping input tokens to output tokens — that is the entire interface. On its own, the model:
Part 2 · Three Disciplines
Prompt, Context & Harness Engineering
Prompt engineering
What you say to the horse. Optimizes a single exchange: one instruction, one output.
Context engineering
What you let the horse see. Manages 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.
What harness engineering governs: which tools the agent gets · where its information comes from · how it validates its own work · when it stops and hands control back to a human. Neither prompt nor context engineering covers an agent running autonomously for hours, making hundreds of unsupervised decisions.
Part 2 · Origin & Proof
A Term That Spread in Weeks
Mitchell Hashimoto — HashiCorp co-founder and creator of Terraform, February 2026.
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. Only the harness changed: same weights, better environment, measurably better results.
Part 3 · Harnesses You Already Use
One App, Three Harnesses
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
Tuned for turn-by-turn conversation.
A system prompt, a few tools, memory across sessions, sandboxed Python, image generation, and safety filters.
Work — heavier harness
Now you talk to an agent, not a model.
Gathers context, plans, and runs for hours to produce finished documents, spreadsheets, and presentations.
Codex — heaviest harness
Scoped execution, feedback loops everywhere.
Explicitly granted access, AGENTS.md conventions, a terminal for builds and tests, inline diffs, PR review.
The same underlying model family behaves like three completely different products depending on which environment it runs in — and once you see it here, you will see it everywhere.
Part 3 · Chat vs Work
Thin Harness vs Heavier Harness
Chat: a thin harness for conversation
- System prompt that shapes behavior before you type a word
- Tools it can invoke — e.g. web search for fresh information
- Memory that persists facts across your sessions
- Sandboxed Python for file analysis + built-in image generation
- Safety filters running on inputs and outputs
Work: a heavier harness
- Planning loop — decomposes a goal into steps
- Connectors that take actions across your real tools
- Approval checkpoints before anything consequential
- Scheduled tasks that keep running after you walk away
- Runs for hours to finished documents and presentations
The model's raw capability did not change — the harness got heavier. Those approval checkpoints are a guardrail placed there by an engineer who decided the agent should stop at exactly that point rather than guess.
Part 3 · Codex — The Heaviest Harness
Codex: The Heaviest Harness of All
What the harness gives it
- Sandboxed execution or scoped access to a folder — you grant what it can touch
- Reads AGENTS.md at the repo root before writing a single line
- A terminal — runs your build and test suite, observes its own failures
- Inline diffs for your review; can review pull requests
- Every capability scoped, logged, wrapped in a feedback loop
Why the same intelligence acts so differently
The weights of the model did not change between tabs. The environment and the harness did — that is why the intelligence that makes small talk in Chat can autonomously refactor a codebase in Codex.
Part 4 · The Five Components
Anatomy of a Production Harness
Whenever you use Chat, Work, or Codex — or Claude Code on the Anthropic side — you are a harness customer: someone else engineered that environment for you. Almost every production system combines five components, and you feel it even when one is missing.
| Component | Role | Concrete form |
|---|---|---|
| 1 · System of record | How the agent should work | AGENTS.md / CLAUDE.md instruction files |
| 2 · Tools | What the agent can actually do | A small, deliberate set — shell, files, web, database |
| 3 · Feedback loops & verification | Checking its own work | Linters, type checks, test suites |
| 4 · Guardrails & permissions | What it is explicitly not allowed to do | Read-only scopes and approval gates |
| 5 · Observability & memory | Record of every run + state across sessions | Logs of every call; memory that persists |
Part 4 · Components 1 & 2
System of Record & Tools
1 · The system of record
A plain Markdown file the agent reads before working: project structure, conventions, build commands, and decisions your team has already made.
The OpenAI trap: without written answers — "what abstractions should I use?" — the agent guesses, and guesses wrong, repeatedly.
If knowledge lives in Slack threads and Google Docs instead of the repository, the agents cannot really see it — it might as well not exist. Everything the agent needs has to live where the agent works.
2 · Tools
Most people fall into one of two extremes.
Good harness design sits in the middle: for each tool in the set, you can justify why the agent needs it.
Part 4 · Component 3
Feedback Loops & Verification
The component most people skip — and the video is explicit that you should not. An agent needs a way to check its own work without asking you.
For code, the 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.
Not writing code?
The principle still holds: define what correct output looks like, write a script or checklist that validates it, and make that check part of every single run.
Part 4 · Components 4 & 5
Guardrails, Observability & Memory
4 · Guardrails & permissions
- Which parts are read-only?
- Which commands require approval?
- At what point does it stop and ask, instead of guessing?
- The approval prompts in ChatGPT's Work experience are this exact component, engineered at OpenAI scale
- Every serious agent tool exposes these settings — most people never touch them. Set them deliberately.
5 · Observability & memory
- Observability: 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
Part 5 · The Roadmap
Five Steps, Worked Week by Week
| Step | What to do |
|---|---|
| 1 · Create your system of record | Write AGENTS.md / CLAUDE.md this week: project structure, how to run, how to test, top five conventions — under a page |
| 2 · Build a verification loop | A linter (e.g. Ruff) plus real tests — wired to run after every change, not left to the agent's memory |
| 3 · Choose tools deliberately | Spend a week inside a serious harness (Claude Code or Codex), then connect one real system via MCP |
| 4 · Read your failures | Turn on logging; every failed run names the next piece of harness to build |
| 5 · One narrow workflow | Instruction file + small tool set + automated checks + permissions + logging — end to end, without babysitting |
Step-1 discipline: when the agent makes the same mistake twice, do not explain the fix in the chat — write it into the file permanently. Almost every line in Hashimoto's own AGENTS.md came from a past agent failure, and once a rule is in the file, that mistake essentially never recurs.
Part 6 · Where This Is Going
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, such as the latest open releases like Kimi K3. What you compete on is the environment you build around the model.
The new differentiator
Instruction files, feedback loops, permissions, and observability — harness engineering is increasingly becoming the standard for most companies.
What it really is
At the end of the day, this is all software engineering — engineering and plumbing the thing around the model.
Key Takeaways
The Complete Checklist
The End
Go Build the Harness
The model is the easy part. Everything wrapped around it — tools, context, checks, permissions, logging — is where the product is made. Write one instruction file this week, and let each failure name the next piece to build.
Source: "Harness Engineering Explained in 20 Mins!" — Aishwarya Srinivasan (youtube.com/watch?v=bsmUh5bTNZ4) · Full article and transcripts in this repo.