Page 5 of 13 · What the agent can do, and what keeps it honest
Harness engineering
A harness is everything around the model that turns it into an agent. Harness engineering is designing that system on purpose: the guides that steer the agent before it acts and the sensors that let it correct itself after. It became a named discipline in early 2026, and it is where most reliability gains come from.
1 runnable sample1 prediction4 questions
Level 1 · The rules
The seven layers of a harness
Claude Code, Codex, Cursor and Gemini CLI are harnesses. The same model behaves differently in each because these layers differ.
Level 1 · The rules
Two harnesses: the builder's and yours
Part of the harness ships inside the product: its system prompt, tools, retrieval and loop. The part you control is the outer harness for your codebase. Martin Fowler's site describes it as concentric rings: model in the middle, builder harness around it, user harness outside.
Builder harness
built by the agent's makers
- Core system prompt and loop
- Built-in tools, compaction, subagents
- You choose it, you don't edit it
- Why one agent beats another on the same model
User harness
built by your team
- AGENTS.md, skills, custom tools and MCP servers
- Permissions, hooks, linters, tests
- Specific to your system and conventions
- Where your engineering effort pays off
Level 2 · Why it works
Guides and sensors
Guides act before the agent does: they anticipate mistakes (feedforward). Sensors act after: they detect mistakes and feed the result back so the agent corrects itself (feedback). Each can be computational (deterministic code) or inferential (another model judges).
| Computational (code decides) | Inferential (a model decides) | |
|---|---|---|
| Guide · before | Scaffolds, templates, generators, a bootstrap script | AGENTS.md conventions, skills, reference docs |
| Sensor · after | Type checker, linter, tests, structural tests, a blocking hook | A reviewer agent, an LLM judge with a rubric |
Prefer computational sensors where they exist: they are fast, cheap and give the same answer every time. Use inferential ones for what code cannot judge, such as readability or whether a spec covers the request.
def lint(code): return [] if "print(" not in code else ["no print statements in library code"]def types_ok(code): return [] if "-> int" in code else ["public functions need a return type"]attempts = [ "def total(xs):\n print(xs)\n return sum(xs)", "def total(xs):\n return sum(xs)", "def total(xs) -> int:\n return sum(xs)",]for round_no, code in enumerate(attempts, start=1): problems = lint(code) + types_ok(code) print(f"round {round_no}:", problems or "all sensors pass") if not problems: break
[ OUTPUT ]
Press Run to see the output this code printed when the course was built.
Level 3 · Mastery
Where to put a rule
The most useful harness decision you will make, again and again. Match the strength of the mechanism to the cost of the mistake.
"Use pnpm, not npm."
AGENTS.md
Cheap mistake; a reminder is enough.
"Follow our release checklist."
Skill
Long procedure, needed only sometimes.
"Never hand-edit migration files."
PreToolUse hook
Expensive mistake; must be enforced, not requested.
"Never touch production credentials."
Permissions + sandbox
Catastrophic; remove the capability entirely.
Level 3 · Mastery
Keeping a harness healthy
Every repeated failure becomes a control
When the agent makes the same mistake twice, add a guide or a sensor so it cannot happen a third time.Instructions fade, enforcement doesn't
Long instruction files get skimmed and their tail is ignored. Move anything critical into a check.Watch for drift
As a harness grows, guides and sensors start to contradict each other. Audit it like code, and let agents help maintain it.The repo is the interface
When agents write most code, the repository itself becomes how humans and agents communicate: docs, tests and structure carry intent.
Predict the output
Level 1 answer before you look
Check your understanding
Levels 1 to 3 open a question to see the answer
What is the difference between a guide and a sensor?
A guide acts before the agent does, steering it away from mistakes (AGENTS.md, skills, templates). A sensor acts after, detecting mistakes and feeding them back so the agent self-corrects (tests, linters, review agents).
Why prefer computational sensors?
They are deterministic, fast and cheap, so the agent gets the same reliable signal every time. Inferential sensors are slower, cost tokens and can be wrong, so use them where code cannot judge.
Two teams use the same coding agent and model. Why do their results differ?
Their user harnesses differ: instructions, skills, tools, permissions, hooks and the checks their codebase runs. The builder harness and model are the same.
Where should "never touch production credentials" live?
In permissions and a sandbox that remove the capability entirely. A catastrophic mistake should be impossible, not discouraged.