A coding agent is a model plus everything built around it. That surrounding code is called the harness. It decides which tools exist, which ones need permission, what goes into the prompt each turn, how long a run may last, and whether a run counts as finished. Two agents on the same model behave differently because their harnesses differ.
Why the harness matters more than the model
Benchmarks pin a model to a fixed scaffold so results can be compared, and that works for measuring the model. It tells you almost nothing about what you will experience, because your experience is set by the scaffolding that is not held constant. Give a strong model a harness with no timeout and it will hang on an interactive prompt for ten minutes. Give a modest model a harness that feeds back the real test output every turn and it will often finish the job.
This is why the same model can feel sharp in one product and useless in another. The industry has started calling work on this layer harness engineering: treat the scaffolding as an artifact you design, test and improve every time the agent makes a mistake you do not want it to repeat.
Image goes here
/blog/coding-agent-harness-anatomy.png
Annotated diagram of harness components around a language model
Show generation prompt
Editorial technical exploded diagram, 16:9, flat vector, top-down. A central circle (the model) with five labeled arms radiating outward, each arm ending in a small outlined box holding a single abstract glyph: a wrench (tool execution), a padlock (permissions), a stack of layered lines (context assembly), a hard drive cylinder (persistence), a checkmark (verification). Thin leader lines point outward to blank annotation ticks. Charcoal (#121212) background, grey (#8c8c8c) line work, indigo (#5560d4) highlights on the verification arm, ordered-dither dot texture in the negative space, generous margins. Mood: technical, anatomical. No readable text, no logos, no watermark.
The five jobs a harness does
1. Tool execution
The model emits a structured request to call a tool. The harness actually runs it, captures stdout, clips it to something the next prompt can afford, and returns it. A harness can only execute the tools it has code for, which is why bash is the general-purpose one: it lets the model build whatever specific tool it needs at run time instead of you pre-building every one.
2. Permissions
Every tool call with a side effect passes a gate. The cheap version is an allow or deny on a tool name. The better versions classify the specific command, let you edit it before approving, and turn an approval into a reusable rule. Where this gate sits matters: if the mode check runs after the permission prompt, a tool the mode forbids will still interrupt you before it is refused.
3. Context assembly
What the model sees each turn is assembled: system prompt, project instructions, tool schemas, conversation, thinking, tool output. Long runs force compaction, where older history gets summarised to make room. Compaction is the most dangerous moment in a long task, because that is when project rules quietly vanish mid-job, and it is where a harness either shows you what it dropped or loses your instructions silently.
4. Persistence
If every event and tool result is written to disk during the run rather than at the end, a crash becomes a resume instead of a lost afternoon. The same store is what lets you replay a run afterwards and see which step produced which line.
5. Verification
The harness, not the model, can run your test command when the agent says it is finished and attach the real exit code. This is the piece with the clearest payoff, because models report success when no test ever ran.
What the harness gets wrong
The recurring complaints about coding agents in 2026 are almost all harness complaints rather than model complaints. A run keeps calling the same tool with the same arguments until the budget is gone. A rewrite balloons past what you asked for because nothing enforced a scope. A permission prompt appears for git status while a destructive command sails through because the matcher was a string prefix. None of these are intelligence problems.
“Ask for a null check and you get a new utils directory, a custom error class, a retry wrapper for robustness, a config flag nobody requested, and three files renamed while it was there.”
the most-cited complaint in community digests of agent usage, 2026
How Quaka's harness is built
Quaka's loop is written in Rust rather than layered on top of a CLI, which means the checks are code rather than instructions in a prompt. Modes, path scoping, command classification, parallel scheduling and pricing all run in Rust before anything touches your disk. The test suite went from 24 to 71 cases as the trajectory and scheduling work landed.
- Modes are enforced, not suggested. Ask, Plan, Review, Build and Debug each have a tool allowlist applied by the runtime, so a read-only mode never sees a write tool.
- Reads run in parallel, writes serialize. Consecutive read-only calls are dispatched together while writes keep the model's order, which is a pure scheduling function with its own tests.
- A loop guard catches itself. The same tool with identical arguments three times, or five consecutive tool errors, pauses the run with a way to steer instead of burning your budget.
- Everything is journaled live. Events land on disk before and after each tool run, so resume after a crash is trustworthy rather than optimistic.
If you want to see what a harness is responsible for in practice, the verified completion post is the clearest example of one job most tools skip.
Get an invite
Quaka is in private beta.
One email when your invite is ready. macOS, Windows and Linux, bring your own key.
Read the source on GitHubCommon questions
What is the difference between a model and an agent harness?
The model is the part that produces text and decides what to do next. The harness is the program around it that offers tools, runs them, gates them behind permissions, assembles the prompt each turn and records the run. You buy a model by token, but you experience an agent through its harness.
Does a better harness make a weaker model usable?
Often, yes, within the model's limits. Feeding back real command output, keeping context tight and stopping loops early lets a mid-tier model finish tasks it would fail at in a sloppier harness. It does not close the gap on hard reasoning, which is where benchmarks still separate models.
Why do agents forget project instructions partway through a task?
Because the harness summarised the conversation to free up context and the instructions were in the part that got summarised. The fix is harness work: re-send project files verbatim after every compaction, let the user pin messages that must never be compressed, and show what the summary dropped.