What is the difference between a coding agent and a harness?
Agent equals model plus harness. The harness is the half you control.
A coding agent is the complete system a user interacts with, and a harness is everything in that system except the model. The usual shorthand is Agent equals Model plus Harness. So Claude Code is an agent, and the part of Claude Code that assembles context, defines tools, runs the loop and enforces permissions is its harness. The distinction matters because the model is the part you cannot change and the harness is the part you can.
Three layers, not two
Böckeler's version has three concentric circles: the model at the centre, the builder harness that the agent's vendor ships around it, and the user harness that you build on top with your own tests, linters, skills and conventions. Most discussion of harnesses conflates the second and third, which is why teams sometimes conclude they cannot influence the harness at all. The outer ring is entirely yours.
What belongs to the model
Reasoning, code generation, instruction following, and the knowledge baked in at training time. You select it and you can route different roles to different models, but you cannot modify it. When a model genuinely cannot do something, no harness rescues it.
What belongs to the harness
Which files reach the context and in what order. Which tools exist and what their results look like. Whether a shell command runs immediately or waits for approval. Whether a failed attempt lands in your working tree or an isolated worktree. What tests run afterwards and whether their output is written for a model to act on. All of it is engineering, and all of it is yours.
The design principle worth stealing
Anthropic's harness-design article makes the sharpest point in the literature: every component in a harness encodes an assumption about what the model cannot do on its own, and those assumptions are worth stress testing, both because they may be wrong and because they go stale as models improve. Their own write-up describes removing a sprint construct and context resets on a newer model because it no longer needed them.
Where Lucid Train is unusual
It is a harness that can run other harnesses. Claude Code, Codex, Cursor and OpenCode are selectable as execution engines per tab, with each CLI's native permission model mapped onto one set of approval modes, and Lucid Train also exposes its own tools over MCP so those CLIs can call back into it. That makes the outer harness portable across whichever inner harness you prefer.
Which layer owns what
| Concern | Layer |
|---|---|
| Reasoning quality | Model |
| Training knowledge | Model |
| Which files enter context | Harness |
| Tool definitions and results | Harness |
| Approval policy | Harness |
| Isolation of failed attempts | Harness |
| Tests, linters, review | Harness (yours) |
| Conventions and skills | Harness (yours) |
| When a turn ends | Harness |
Questions
Related
- What Is a Coding Harness?Everything in the agent that is not the model. The part you can actually change.
- Harness Engineering vs Context EngineeringOne is a component of the other, and confusing them is why teams optimise the wrong thing.
- Is Claude Code a Harness?Both, and the confusion is in the question rather than the answer.
- Is GitHub Copilot a Harness?Two products under one name, and only one of them is a harness.