Day 1 · Lesson 2 of the series
The lever that actually moves a task along the dial.
Lesson 1 left you with a dial and a promise: something moves a task along it. This is that something. And it reframes a reflex most builders get wrong: reaching for a better model when the fix is almost always in the harness.
From Lesson 1: what single factor most sets where a task sits on the build dial?
Verification, tests for the deterministic part, evals for the rest. Hold that thought: the harness is where those checks physically live.
A raw model is not an agent. It becomes one when something wraps around it and gives it state, tool execution, feedback loops, and enforceable constraints. That wrapper is the harness:1
Agent = Model + Harness
The temptation is to treat the model as the system: new model, smarter agent; old model, dumber agent. That intuition is wrong, and it leads to the wrong investments. The behaviour you experience from Claude Code, Cursor, Codex, or Antigravity is dominated by what the harness does, not just by which model is underneath. The harness is the team's surface area, not the model provider's.1
On Terminal Bench 2.0, one team moved a coding agent from outside the Top 30 to the Top 5 by changing only the harness, no model change at all. A separate LangChain study raised a coding agent's score by 13.7 points by tweaking only the system prompt, tools, and middleware around a fixed model.2 Same brain, different scaffolding, different league.
Six components. You already touch most of them. The value is naming them, so when something breaks you know which one to inspect.1
1 · Instructions & rule files — who the agent is, what it cares about,
what it must never do. AGENTS.md, CLAUDE.md, skill files, sub-agent prompts.
# AGENTS.md
Stack: Python 3.12, FastAPI, Postgres. Tests: pytest.
Hard rules:
- Never write secrets to code or logs.
- No new dependency without a one-line justification in the PR.2 · Tools — the functions, MCP servers, and APIs it can call, plus the prose telling it when and how. (Day 2 is entirely about getting this right.)
3 · Sandboxes & execution environments — where its code actually runs, and what it can and cannot reach (e.g. a container with no network except the package registry).
4 · Orchestration logic — sub-agent spawning, model routing, hand-offs: a cheap fast model for test generation, a frontier model for architecture. (This is also the economics lever: you don't pay frontier prices to fix a typo.)
5 · Guardrails / hooks — deterministic code that fires at lifecycle points: before a tool call, after a file edit, before a commit. The place for things the agent should never forget but often does.
# .hooks/pre-commit — runs as code, not as a polite request
if git diff --cached | grep -E '(api_key|password)\s*='; then
echo "BLOCKED: possible secret in commit"; exit 1
fi6 · Observability — logs, traces, evals, cost and latency metering. Without it, there's no way to tell whether the agent is doing well or quietly drifting.
trace: refund-agent run #4821
tools: lookup_order ✓ check_policy ✓ issue_refund ✗(gate: needs approval)
tokens: 3,140 in / 412 out cost: $0.018 latency: 2.3sHere is the line to internalise: "When an agent does something wrong, the first instinct is to blame the model. More often, the failure traces back to a missing tool, a vague rule, an absent guardrail, or a context window stuffed with noise." Most agent failures, examined honestly, are configuration failures.2
So when your agent misbehaves, triage the harness before reaching for a bigger model:
Missing tool? → it literally couldn't do the thing
Vague rule? → it never knew the constraint
Absent guardrail? → nothing deterministic stopped it
Noisy context? → the signal got buried in tokens
↑ most failures resolve here, model untouchedThis closes the loop. The artifacts that moved the refund agent rightward on the dial (the
AGENTS.md spec, the tests, the evalset, the CI gate) are harness
components (1, 5, and 6). "Configuring the harness" is the act of moving a task
from vibe toward agentic. The dial measures the outcome; the harness is the knob.
Guardrails/hooks are a local V Validation seed; observability is a local E Evidence + T Transparency seed. But in the harness they're build-time and advisory: they live in your repo and protect your session. VERDICT makes the same ideas runtime and enforced: a hook becomes a live policy gate; a trace becomes an immutable org-wide audit log; a kill-switch (R), which no harness component gives you, stops a deployed agent.
Ladder read: a harness with observability gets an individual agent to L2 Observed: you can see it. It does not reach L3 Controlled: that needs enforced gates + a named owner, which live above the harness, at the org. A great harness is necessary but not sufficient for governance.
Start a ten-line AGENTS.md today: stack, conventions, hard rules, workflow.
Add one rule every time the agent does something it shouldn't repeat. The harness compounds.
Make the harness shared infrastructure in the repo: AGENTS.md, hooks, and eval suites reviewed in PRs and versioned like any code, so agent behaviour is reproducible across teammates, not locked in one person's head.
Invest in the harness as a cross-team asset: reusable prompts, skill libraries, MCP connections, eval harnesses. Build it once, refine it many times. That's where compounding value lives.
Recall, don't re-read.
A pre-commit check that blocks a hard-coded password is which harness component?
A hook: deterministic code firing at a lifecycle point (before commit). It runs as code, not as a request the model can talk its way around, which is exactly why it's also the build-time seed of VERDICT's V Validation pillar.
Your agent ignored a constraint it was never actually told. Most honest first suspect?
"Never told" = a missing or vague rule file, a configuration failure. Most agent failures are. Reaching for a bigger model leaves the gap in place.
Adding observability (traces, cost, drift) to your harness most directly enables —
Observability = Evidence/Transparency → it gets you to L2 "Observed". Note what it does not do: stopping live is Runtime Control (R), a named owner is Identity (I), separate pillars, above the harness.
Next time an agent disappoints, say it out loud: "which harness component is missing?" before you touch the model dropdown. Nine times in ten, that question ends the debugging.
The harness framing is sharpest in Addy Osmani's writing and the benchmark write-ups he draws on: Osmani, "Agentic Engineering" and his "My LLM Coding Workflow". For the harness-effect evidence, the Terminal-Bench results are worth a look.
Up next → Lesson 3: The Factory Model. Zoom out from the machine to the whole assembly line. If the harness is the central machine, the factory is the system you actually build: specs, agents, gates, feedback loops. Your output stops being code.
Related: Glossary: harness · Agent = Model + Harness · The Governance Layer · ← Lesson 1: The Spectrum