WritingCerebrasCerebraspublished Oct 19, 2026seen 4d

A Smarter Model Won T Save Your Bad Harness

Open original ↗

Captured source

source ↗

A Smarter Model Won’t Save Your Bad Harness | Cerebras Skip to main content

Oct 16 2026 A Smarter Model Won’t Save Your Bad Harness Sarah Chieng William Ryan Sherif Cherfa

An agent is roughly a model inside a harness, operating in an environment. The model supplies the intelligence. It reasons, makes decisions, writes code, and decides what actions to take next. The environment is the actual computer, repository, browser, or container where this work happens, and the user (sometimes another agent) is the one providing the goals and providing guidance when needed. The harness decides what the model can see, what actions it can take, how results get fed back into the next inference, and when work is actually done.

You can think about harness engineering as the system you build around a model to make it an engine for completing real work. It does not matter how intelligent a model is. Without a harness, it is simply a token-generating machine. Harnesses are what makes that intelligence actually useful. A harness is what transforms the model into an agent. There are many types of harnesses. Some are tuned towards different types of work Personal work: Openclaw and Hermes are primarily personal agents, they're embedded into external applications (Telegram, Discord, iMessage). Coding: Typically these harnesses run in the terminal, or in code editors. There are harnesses designed for reinforcement learning and research, harnesses for finance, marketing, and many other verticals. Knowledge Work: ChatGPT Work and the Claude Desktop App are great examples of this. While many also use them as coding agents, these apps have a plethora of tools and plugins that allow you to connect your agent to tools such as Slack, Notion, Gmail, Sheets, Teams, Clickup, and dozens more - all with the goal of supporting general knowledge work.

ChatGPT Work from OpenAI (pictured) has a robust ecosystem of plugins available for generalized work and software engineering.

But fundamentally, they all share the same skeleton. Today we're going to breakdown the layers of an agentic harness to gain a better understanding of the tools of our crafts. What is a harness? Large Language Models accepts inputs, then uses those inputs to generate the next token, it then appends the last generated token to the inputs, and the loop continues, until it decides it's done. On their own, they cannot: use a computer maintain durable state search the web run shell commands read, edit, or create files execute code or verify what they produced even works

If a large language model is a brain, the harness is its body. When you give a query such as:

Your prompt does not just go straight to the model and come back as a magically completed patch. The harness compounds many inference calls in a feedback loop that looks like this:

That loop is what we call the “agent.” And each step outlined here requires quite a bit of engineering

The harness generally owns: Prompt construction - system/developer instructions, repo instructions, user prompt. Context selection - which files, previous messages, tool outputs, memories, diffs, etc. are visible. Tools - shell, file editing, search, web, MCP tools, Git, testing. Tool schemas - how those capabilities are described to the model. Tool execution - actually translating the model's intent into actions. Agent loop - deciding how tool results get returned and triggering the next inference. State - remembering what's happened across steps/sessions. Orchestration - spawning specialized or parallel agents. Hooks - deterministic execution of scripts on pre-defined triggers (linting, blocking dangerous commands, code review). Memory - personal context gets stored and injected into model prompts to help agents "remember" previous sessions. Context compression - deciding what gets summarized or discarded as the session grows. Planning - plans, TODO lists, subgoals. Permissions/sandboxing - what the agent is allowed to execute. Error handling - retries, failed commands, timeouts. Verification - tests, linting, checking whether changes work. Termination - deciding when the agent turn is actually finished. Constraints - rules that dictate what the agent can, and cannot do.

The Harness Can Change the Result If you've used the same model in two different coding tools, you've probably felt this already. The model may be the same, but the experience and quality of outputs can be dramatically different. One paper, Stop Comparing LLM Agents Without Disclosing the Harness , reports that Claude Opus 4.5 scored 45.9% under a standardized SEAL scaffold but 55.4% when used through Claude Code on SWE-bench Pro.

Table 1 in Stop Comparing LLM Agents Without Disclosing the Harness And complexity is not always king. Sometimes a smaller tool schema can improve an agent more than additional layers of orchestration. More recently, Prime Intellect released their coding harness. Built on Pi, Prime Agent has managed to outperform the harnesses their models were trained to use.

Source: Prime Intellect’s Prime Agent Announcement

The moral of the story here is this: a benchmark telling you “Model A beats Model B” can sometimes actually really be unintentionally misleading if the same harness was not used for both tests. Context (and the harness) matters. A benchmark result belongs to a model-harness pair. If the harness changes, the result can change too. And as harnesses become more ambitious, they also make more model calls. That is where fast inference starts to matter.

Artificial Analysis Harness Comparison Here you can see clearly: the same model varies wildly in performance depending on the harness. The Harness is an Inference Multiplier Look at the list of things a harness owns : planning, looping, retries, verification, testing, compaction, orchestration, review. Every single one of these requires another model call, costing tokens, but more importantly time. A validation pass might catch bugs, but it also doubles runtime. Subagents may parallelize some of this work, but the orchestrator still has to plan, dispatch, and synthesize these results, and all of those steps are sequential. Every model call adds latency, and in a mostly serial agent loop, the rough budget looks like this:

If one step is slow, ten steps become unwatchable. But by contrast, if the model steps are fast, the harness has room to do more useful work before the agent stops feeling interactive. The distinction...

Excerpt shown — open the source for the full document.

Notability

notability 5.0/10

Substantive engineering blog post from Cerebras, no traction info