People say "the AI wrote my code". What actually wrote your code is a harness: a program that calls a model in a loop, gives it tools, executes what it asks for, and feeds the results back.
Understanding that split explains a lot of otherwise confusing behaviour, and it is the difference between a good coding agent and a bad one built on the same model.
The loop
Stripped to its essentials:
1. Send the conversation to the model, along with a list of tools it may use.
2. The model replies with text, or with a request to use a tool.
3. If it is a tool request, run the tool and append the result to the conversation.
4. Go to 1, until the model replies with no tool request.
That is it. Everything else is detail, and the detail is where all the difficulty lives.
What the harness owns
The tools. A model cannot read a file. It can emit a request that says "read this file", and something else has to actually do it. The set of tools is chosen by the harness: read, write, edit, run a shell command, search, fetch a URL. A model with no tools can only talk.
Executing them. Running a command, capturing its output, deciding what to do when it takes ten minutes or prints 400,000 characters.
The gate. Deciding which tool calls happen automatically and which need a human first. See permission models.
Context. The model sees a fixed-size window. The harness decides what goes into it: which files, how much of the conversation, what project instructions. This is most of why one harness feels smart and another feels forgetful on the same model.
The transcript. Recording what happened, so you can read it and so the conversation can be resumed.
The interruption. Letting you stop a turn mid-flight without corrupting the state, which is harder than it sounds and is where a lot of harnesses are weak.
Interactive tools, and why they are special
Most tools do something and return a result. A few exist to ask you something, and they do not work like the others: the answer is not a result the tool computes, it is a value the client collects from a human and hands back as though it had been the input all along.
Asking the user a question works this way, and so does proposing a plan for approval.
If a harness does not implement them, it does not merely look bad. It hangs. The model waits for an answer that no code path can ever produce. This is the single most instructive bug in the category, because it is invisible in a demo and fatal in real use.
Client, harness, model
Three layers, often confused:
- The model is Claude. It produces tokens. It has no filesystem and no memory between calls.
- The harness is the loop, tools and policy above. Claude Code is a harness.
- The client is what you look at. A terminal, an editor extension, or a desktop app.
A client can add a lot without touching the model: several sessions at once, isolation between them, a diff view worth reading, a place to answer a permission request that is not a stream of text.
What makes a harness good
- It never hangs. Every path that can block settles: on an answer, on an interrupt, on a close, on a quit.
- It settles its own state. If a turn dies mid-tool, the tool is marked interrupted rather than spinning forever. A spinner that never stops is worse than an error.
- It streams correctly. A partial message and the final authoritative one have to be recognised as the same thing, or you get duplicated paragraphs when a delta is lost.
- It respects project instructions. A
CLAUDE.mdin the repository should mean the same thing in every client. See CLAUDE.md explained. - It is honest about what it cannot do. Rewinding a conversation is the good example: the model's context lives server side and cannot be truncated, so an honest harness says a rewind starts a fresh session rather than implying an undo.
Where Fleet fits
Fleet is a client over Claude Code's own SDK. It does not replace the harness, it wraps it: one harness per session, each in its own worktree, with the permission gate, the plan gate and questions surfaced as things you can actually answer.
The parts it adds are the ones a terminal cannot: several sessions at once with isolation that holds, a review panel where notes anchor to lines, and an orchestrator that is itself an agent.