Harness Engineering

Cole Medin published a talk recently called Harness Engineering: What Separates Top Agentic Engineers Right Now. It is a 17-minute breakdown of what the harness around a coding agent actually consists of and why it matters more than the model underneath.

I have been thinking about this framing since I watched it. Not because the ideas are new, most of them map directly to patterns I use daily, but because Cole draws a clear line between the components that most people treat as one blob and the ones that actually differentiate engineers.

The model is the smallest part of the stack

Cole's opening point: one teardown of Claude Code found that roughly 98% of it is the harness, not the model. The model is the inference engine. The harness is everything else: rules, skills, hooks, sub-agents, MCPs, codebase search, the prompt construction pipeline.

This changes how you think about failures. When an agent writes bad code, the instinct is to blame the model and wait for the next one. Opus 5 will fix this. GPT-6 will understand my conventions. This is cargo-cult thinking. The model is not the bottleneck. The harness is.

Cole calls this "system evolution." Every LLM mistake is an opportunity to improve your harness. If the agent does not know a convention, add it to your rules. If it runs a destructive command, add a pre-tool hook that blocks it. If it ignores your code style, add a lint gate that enforces it in code rather than instructing it in prose. The fix is never "wait for a better model." It is "make your harness better."

The two levels of harness engineering

Cole breaks harness engineering into two levels.

The first is the AI layer around a single session. Rules, skills, hooks, MCPs, sub-agents — these six components let you define context and processes within one coding session. You pick the coding agent (Claude Code, Codex, Cursor) but you build this layer yourself. This is where the agent skills and sub-agent patterns I have written about live. Every skill file, every AGENTS.md rule, every pre-tool hook is a piece of harness engineering.

The second level is orchestrating multiple coding agent sessions into one workflow. This is where the real leverage is. Instead of handing one massive PRD to a single session and watching it get overwhelmed, you split work into focused tasks and chain sessions together with handoff documents. Each session stays token-efficient. Each one has a clear scope. The output of one becomes the input of the next.

This maps directly to the agent loop system I run daily. The orchestrator decides which agents to run, in what order, with what inputs. It is not a prompt. It is a scheduler, a quality gate runner, a context manager. Cole calls this the Ralph loop. I call it the outer loop. Same idea.

What the harness mindset changes

The biggest shift in thinking is this: when you treat harness engineering as the primary skill, every failure becomes legible and fixable.

Before this mindset, an agent generates bad output and you tweak the prompt manually. Maybe it works, maybe it does not. You have no idea why, and the fix is ephemeral, trapped in a chat session that disappears when the window closes.

After this mindset, the agent generates bad output and you identify which layer of the harness failed. Did it violate a convention? Add the convention to AGENTS.md. Did it run an unsafe operation? Add a hook that blocks the command. Did it lose track of context? The session was too long. Split the work into smaller sessions with handoff documents.

The fix is permanent. It lives in the harness. The next run inherits it.

Where I have been doing this without naming it

Reading Cole's breakdown, I realized I have been doing harness engineering for months without calling it that. Every time an agent in my orchestrator gets something wrong, I fix it in a skill file or a quality gate. The compound engineering pattern Simon Willison describes is the same thing: after every project, document what worked so future agent runs get better.

Some examples from my harness:

My CLAUDE.md has a section that tells agents not to run npm run build without also verifying the output. This came from an agent that shipped a static export with missing pages because the build succeeded but the output was incomplete. The fix was not a better prompt. It was a rule in the harness.

My quality gates run lint, typecheck, and build verification before any PR opens. The content pipeline runs an SEO audit and a humanizer pass. None of this is in the model. It is all harness.

My software factory pipeline uses sub-agents with separate skill files for each phase. The planner cannot see the implementer's context. The reviewer cannot see the planner's context. Each phase is a focused session with its own harness. The orchestrator stitches them together.

Where the leverage is

If you are still treating your coding agent as a chat interface and blaming the model when it gets things wrong, you are leaving leverage on the table. The model is the smallest part of the stack. The harness is where the engineering happens.

Start with the first level: rules, skills, hooks, sub-agents. Add one rule for every recurring failure. Write one skill file for every repeatable task. Build one quality gate for every class of bug the agent introduces. The harness compounds. Every fix stays fixed. Every session gets better than the last.

When you outgrow single-session workflows, build the second level. Orchestrate multiple sessions. Use handoff documents. Let an agent plan, another implement, another review. Each one operates in a focused context. Each one gets harness improvements from the previous run.

The goal is not to find the perfect model. The goal is to build a harness that makes the model you have good enough.