What is an agentic coding harness?
Published 2026-09-20 · Blazorly docs
An agentic coding harness is the runtime around a language model that turns a coding task into tool calls, file edits, commands, and a session you can resume. The model writes tokens. The harness owns the loop: which tools exist, how results return, how context is compacted, how a stop or crash is recorded, and whether a second agent can join the work. In one line: agent = model + harness. Blazorly is that harness as a local binary with a chat UI and a headless CLI. You bring the provider and the key.
Why the word “harness”
A language model can generate a patch in a chat window. That is not an agent. An agent needs a loop that can call tools, look at the results, update a plan, ask for approval on risky actions, keep a growing context from exploding, and keep going until the task is done or someone stops it. The surrounding machinery is the harness. The term has been used that way across open-source CLIs, IDE agents, and research write-ups through 2025–2026: the harness is the agent without the model.
That split matters because most of the product difference between coding agents is not the base model. Two teams on the same API will get different outcomes if one drops cancelled turns, the other keeps them; if one dumps every tool schema into every request, the other gates the list; if one treats a crash as “start over”, the other reloads a truthful log.
What the harness owns
- The loop — assemble prompt, stream, dispatch tools, write a turn ending with a reason.
- Tools — bash, files, search, web, LSP, MCP, sub-agents. Policy on what they may touch.
- Session — a durable log, not a chat buffer in RAM.
- Context — compaction, token metering, what the model is allowed to see next turn.
- Control — Stop, timeout, permission prompts, plan mode.
- Surfaces — UI, CLI, editor protocol. Same loop underneath.
What you own: the workspace, the provider, the key, and the decision to hit Stop.
What Blazorly is in that picture
Blazorly is a model-agnostic coding harness. It does not sell inference. It runs on your machine, talks to DeepSeek, OpenAI, Anthropic, xAI, Ollama, LM Studio, or a custom OpenAI-compatible route, and keeps provider keys from leaking across routes. The default surface is a browser UI at localhost:5080. The same binary runs headless (blazorly run), serves ACP for editors, and serves JSON-RPC for automation.
Three design bets, written down so they can be wrong in public:
- Interruption is a state. Stop, timeout, and process-kill must leave a log that reloads. See durable sessions.
- Delegation stays in the parent chat. Swarms and reviewers are children, not a second product. See multi-agent.
- Install is a binary. Six platforms, checksum, atomic swap. No SDK required to use it.
Harness vs IDE vs hosted agent
| Shape | Where the loop lives | Typical tradeoff |
|---|---|---|
| IDE agent (Cursor and similar) | Inside the editor | Best inline diffs; you take the IDE. |
| CLI / TUI harness (Claude Code, Aider, OpenCode) | Terminal on your machine | Scriptable; UI is the terminal. |
| Hosted cloud agent | Vendor infrastructure | Zero install; your repo and keys leave home. |
| Blazorly | Local process, browser UI + CLI | You operate the binary; you pick the model. |
A short example
You type: “Add a /health endpoint and cover it with a test.” The harness, not the model, decides which tools to offer, records read of the routing file, records edit, runs dotnet test under the permission preset, and writes turn/end {completed}. If you hit Stop during the test, bash is killed, the tool result is stored as aborted, and the partial assistant text you already saw stays in the transcript. That last sentence is the harness. The model only wrote the patch.