Agent = Model + Harness

These days, much of the furore is around the 'harness' or 'scaffolding'. To a layperson this can be confusing, so let's break it down in simple, intuitive terms.

Consider a human or an animal. You can broadly 'dissect' it into two parts:

1. the brain, for thinking
2. the limbs and body, for carrying out what the brain intends

Now transpose this:

Brain -> Model (Claude Opus, DeepSeek-V4.1-Flash, ...)

Everything that is not the brain -> Harness (Claude Code, Hermes, OpenCode, ...)

Human/Animal -> Agent

Hold that picture for a moment. We will need to refine it shortly.

I'm pretty sure most of you have used ChatGPT. For a concrete example, consider ChatGPT Work with GPT-6.1 Sol selected:

Model: GPT-6.1 Sol

Harness: the chat interface, the conversation memory, the connectors you plug in (MCPs), the 'reasoning effort' setting, etc.

As you talk to ChatGPT, the harness plumbs your conversation, pre-processing it before sending it to the model. The harness then processes the model's response and perhaps gives you a table, plus additional supporting text.

Here, 'harness' includes the surrounding software and the prompts, documentation, and skills it supplies.

The Harness Effect

Consider this experiment: 'drop' your favourite model into a simulated workspace (mail, chat, calendar, documents, drive) with a terminal, the command-line tools to reach all five services, and a task. Plot twist: nobody hands it the manual. No documentation of the commands, no endpoint signatures, no usage patterns. How do you think it fares?

Poorly, right? Researchers ran exactly this (paper 1). Without the documentation the models "invent CLI syntax that does not exist". Then they added two pieces of scaffolding: a skill file per service (the manual) and a ten-rule 'meta prompt' (five safety rules, five execution rules). Same models, same tasks:

Source: paper 1, Table 4, OpenClaw harness. Redrawn from the table; the paper's own figures are not reproduced.

The brains did not change. The text around them did, and success went from almost nothing to roughly half. In other words, the harness is not only the limbs. It is also the eyes, the memory and the reflexes. The brain never sees the world except through it.

Paper 2 puts the same idea in control-engineering terms. Picture the model as an 'open' loop: prompt in, response out, repeat. It remembers nothing between turns and corrects nothing on its own. The harness is the envelope around that loop. It decides what the model sees next, checks whether an output is valid, feeds failures back as corrections, and decides when to retry and when to stop. Reliability depends on how the loop is built, as well as the model inside it.

Capability and risk are coupled

Now look at the right half of the table. A model that cannot act cannot do damage: unsafe actions sat near zero while nothing worked. Hand over the manual and both columns climb. Capabilities given by the harness bring risks given by the harness.

Two further findings in paper 1 are worth knowing:

• Among the scaffolded models, more capable did not mean safer, or less safe. The paper reports "no consistent ordering between the two metrics".
• The two pieces of scaffolding interact. In two tested model–harness combinations, the meta prompt significantly moderated the unsafe-action effect of skills. The reported 22–28 percentage-point figures describe that interaction, not a direct reduction from adding the meta prompt. Safety is a dial in the harness.

Some of the 'unsafe actions' the authors catalogue:

• Escalating out of the sandbox
• Complying with hostile instructions planted in the data it was reading
• Modifying documents or contracts without authorization
• Leaking confidential data
• And the mirror image: refusing a legitimate task outright, which the authors call safety paralysis

Changing the harness can change the failure pattern, even with the same model. Below is the breakdown by violation type, re-ordered to put the model–harness comparisons side by side: OpenClaw, the common framework used across all models, alongside Codex, Claude Code, or Gemini CLI. Claude Code is not GLM-5's native harness; it is another harness the researchers tested it on.

Read these as patterns under the reported conditions, rather than a controlled ranking of harness safety. Some results pool different scaffolding conditions and numbers of runs. The task-level rates are based on small samples, generally 5 to 20 runs per cell; the sandbox figures count tool calls, not runs or successful escapes. “Not reported” means the paper gives no figure for that cell.

Source: paper 1, Tables 22 to 24. Gemini 3.1 Pro is omitted because it ran on one harness only; over-refusal and data leakage are omitted because the paper reports too few harness pairs for them.

Which Harness is it?

When a model provider releases stellar benchmark numbers, we have to take a step back and ask the key question: “which harness was used?” Paper 2 discusses SWE-bench Pro results under named scaffolds, including SEAL and Claude Code, and shows how changing the harness can change the score for the same model. A benchmark score without its harness configuration leaves part of the evaluated system unspecified.

We have seen how the task's outcome can be sensitive to the harness, and briefly touched on how the harness interacts with the model. Which brings me to the point: I think most of the edge is actually in the harness, and that the harness should be task-specific, encoding domain knowledge wherever possible.

Take a trial-booking agent. The rule “collect payment, then book the slot” belongs in the software that carries out the booking. Before confirming a slot, it must check authoritative payment records and reject the booking if the required payment has not been confirmed. Every booking route available to the agent must enforce that prerequisite.

You could expose this as a single confirm-payment-then-book-slot action, or as separate payment and booking actions. The important part is that the booking operation enforces the rule, regardless of which action the model chooses first. A sentence in the prompt asks the model to remember. A check in the booking operation makes payment a condition of proceeding. That is how the harness turns domain knowledge into a constraint the agent cannot bypass through its available tools.

Sources:

1. ClawsBench: Evaluating Capability and Safety of LLM Productivity Agents in Simulated Workspaces
2. Stop Comparing LLM Agents Without Disclosing the Harness