An LLM alone is an engine bolted to a concrete floor. The harness is what makes it a car.
A raw LLM with no wiring around it is close to useless — an engine in a crate. Everything that turns that engine into something that runs your business, reviews your PRs, and preps your calls is the harness. And like a car, some people buy it off the lot, some tune it like an F1 machine, and some build it from scratch.
Harness engineering is the practice of building the system around an AI model that makes it useful. The model is the brain; the harness is everything else — the prompt scaffolding, the memory, the tools it can reach, the automation that runs it, and the tests that check its work. The term became popular through Anthropic’s agentic stack, but the idea is tool-agnostic: it applies to Claude Code, ChatGPT, Codex, Cursor, or any agent you wire up.
The failure mode of a bare model is that it can answer but not act, and it forgets everything the moment you close the window. You prompt it with vague instructions, it has no way to reach your calendar or your repo, and every useful thing you got from it was luck. Harness engineering is the fix: you give the agent the context it needs, the tools to act, the automations to run without you, and the evals to know whether its output is any good. The delta between a model and a harness is the difference between a toy and a tool you ship with.
There are three tiers, set by where you start. Off-the-shelf apps like ChatGPT and Claude — you tweak the trim: system instructions, memory, a few connectors, your files. Next, Claude Code and its kin — you are tuning a racing car, editing config, writing skills, wiring hooks, and you need real expertise to drive it at speed. At the top, you build your own harness with an API and custom code around the model — total freedom, total responsibility. Most people will live in tier one and two; the skill is understanding which tier you are in and pulling the right levers.
# context: CLAUDE.md # loaded into every conversation, automatically > Every time you use a skill, end the session with > one concrete suggestion for improving that skill.
# This single line taught the agent to never let a skill go stale. # Claude reads CLAUDE.md at the start of every session, # so the instruction rides along without being re-pasted.
CLAUDE.md (or AGENTS.md for other tools) is the simplest context lever: anything in it is auto-loaded every session. Shaw’s example — one line telling the agent to propose skill improvements — is a self-maintaining harness.
# tools: connectors via MCP # connect Gmail + Google Calendar + HubSpot, then: > Rank my warmest and coldest leads from the last 30 days. > Check sales calls, CRM notes, and email threads.
# The agent reads across three sources and answers # without you exporting anything or pasting a single row. # This is the difference between context and tools: the agent # goes and GETS it instead of waiting for you to hand it over.
This is Shaw’s lead-ranking example. Connectors (Claude’s term) are MCP servers under the hood — a standard Anthropic open-sourced in Nov 2024 so any assistant can reach external apps through the same protocol.
# automations: scheduled + event-triggered /schedule "every morning: prep today’s calls" # git pre-push hook fires Claude Code to review before push
# Scheduled: a daily prep task pulls meeting data, runs web # search, checks email, writes one Notion page. # Event: a git hook / Claude hook fires on specific triggers # e.g. delete the screenshots an agent left in the repo.
These are Shaw’s two automation patterns. `/schedule` is time-based (daily call prep, nightly code review); hooks are event-based (on session exit, on push, on any trigger). Hooks only live in the coding agents, not in off-the-shelf chat apps.
| Flag | Meaning |
|---|---|
CLAUDE.md / AGENTS.md | auto-loaded context file — guidance, standards, knowledge, injected every session |
skills | a folder of files with a SKILL.md prompt that loads only when relevant (progressive disclosure) |
MCP / connectors | standard for giving the agent tools to reach external apps: Gmail, Notion, Google Drive, Slack, Jira, HubSpot |
/schedule | time-triggered automation: run a task every morning, every night, on a cron |
hooks | event-triggered automation: on session exit, on config change, on push — only in coding agents |
evals | tests that tell the agent whether its output is good — the loop that removes you from the review |
The word "harness" for the system around a model comes straight from the agent world, popularized by Anthropic as it shipped Claude Code (Feb 2025) and its agentic tooling. Shaw Talebi’s video "Harness Engineering Explained in 22 Minutes" is a clean public codification of the idea, framing it as the car-to-engine analogy and naming the levers: context, tools, automations — then the bonus lever, evals. The term spread because it names something every power user was already doing but had no word for.
The stack assembled piece by piece. The Model Context Protocol was open-sourced in November 2024, giving agents a standard way to reach external tools. Claude Code launched as a research preview in February 2025 and went fully general availability in May. Claude Skills arrived in October 2025, bringing the progressive-disclosure pattern — the agent sees the name and description of every skill, but only loads the actual files when a task needs them. The timeline matters because each release moved a lever (context, tools) from manual to standard.
Andrej Karpathy’s autoresearch repo went viral as the proof of concept for evals. Instead of writing train.py himself and iterating by hand for a PhD, he wrote a program.md file — instructions for an agent to optimize train.py autonomously. It ran overnight, launched around a hundred experiments, and, according to Shaw’s telling, produced a train.py that outperformed what Karpathy did by hand. The repo pulled in 26,000+ stars in under a week. It is the cleanest public demonstration that building an eval loop beats being the loop.
Without evals, every interaction is a human loop: you send a request, the agent produces output, you judge it, you send feedback, repeat until satisfied. That caps your throughput at your attention span. Evals replace your judgment for checkable outputs with an automated test. The agent produces output, runs the eval itself, fixes, re-runs, and only hands the result to you once it passes. You review final results rather than every intermediate draft. The loop changes from "you review everything" to "you review what passes the test."
The genius of skills is that they solve the context-budget problem automatically. Instead of loading every reference, asset, and script into every conversation (a firehose that burns your context window), the agent only sees the name and description of each installed skill up front. When a task matches, it pulls the SKILL.md and the specific files it needs. Your proposal skill’s logo in the assets folder, your Keynote-editing script, your API connector — all available, none of it cluttering the context until it is relevant.
Shaw’s closing mental model is worth stealing: before you ship a harness, put yourself in the agent’s shoes. Given the context you provided, the tools you exposed, and the automations you set up, could you complete the task? If yes, the harness is probably good. If no, you know exactly what to improve — more specific context, a missing tool, a hook you forgot. It shifts the question from "how do I do this task" to "how do I make the agent able to do this task, reliably." That is the whole mindset shift of harness engineering.