AI model vs agentic harness: what actually drives performance

An AI model is a brain in a jar; the agentic harness is the body around it — tools, memory and the agentic loop of plan, act, observe, repeat. Most recent performance gains came from the harness, not the model, because a model can shine in one harness and stall in another. Choosing both separately is the orchestration decision.

The same model can feel completely different

Two AI products can feel completely different while running the same model. A model used as a simple chatbot is one thing; the same model inside a developer tool with file and terminal access suddenly works for hours on software tasks. The difference is the harness — the packaging around the model.

An AI model alone is a brain in a jar: capable, but trapped. It cannot open files, run code or search the web on its own. The capability emerges from what is built around the model — the agentic harness.

The practical implication is that most of the performance gains in recent months came from the harness, not the model. The benchmark gaps between the top labs have shrunk to a few points; when one product clearly beats another, the explanation is usually the packaging.

The three components of the harness

  1. Tools — the arms and legs of the model. File access, code execution, web access, computer use, the command line, and MCP as the standard for connecting external services. A model without tools can think; it cannot do.
  2. Memory — the model's working and long-term memory. Persistent instructions like an AGENTS.md loaded at every start, context compaction when the window fills, and search-based context that loads only what is needed instead of everything.
  3. The agentic loop — plan, act, observe, repeat. The model decides the next step, the harness executes it, results flow back, and the loop runs from seconds to hours. Modern harnesses add verification: continuous tests, screenshots, review models — a model that checks its own work runs longer without drifting.

The separation

Model vs harness, side by side

DimensionAI modelAgentic harness
RoleThe brain in the jarThe body around it
OwnsKnowledge and reasoningTools, memory, the loop
Recent gainsSmall lab-to-lab gapsMost of the performance wins
Failure modeWrong answerDrifts off course
ChoiceWhich model for the taskWhich harness for the model

The boundary is fluid: capabilities that used to live only in the harness — long-term planning, self-verification — are increasingly trained into models, while behaviours that were model properties are increasingly shaped by harness conventions and project files. Choose both deliberately.

The question that replaces 'is AI good at coding?'

Once model and harness are separate in your mind, the question changes. Instead of 'is AI good at programming?', you ask: which model in which harness for which task? A model can excel in one harness and stall in another, because the harness decides what the model can reach and how it verifies its work.

That is the orchestration decision. It is also the independence argument: choosing model and harness separately keeps you from being locked into one ecosystem, and lets you combine the best model with the best harness for each job.

Executable artefact

The harness makes the model reach further

The same underlying model, in a harness with tools and a loop, does work a bare API call cannot. The difference is the wrapper, not the weights.

# A model alone — a single stateless answer
curl https://api.example.com/v1/chat \
  -d '{"model": "frontier-1", "messages": [{"role":"user","content":"fix the bug"}]}'

# The same model in a harness — tools, loop, verification
opencode run "fix the failing test in src/, verify it passes" \
  --model provider/frontier-1 --thinking

The harness adds the file access, the terminal, the loop and the verification. The model supplies the reasoning. Neither alone is the product.

Model choice decides the ceiling; harness choice decides how much of it you reach. The most expensive mistake is pairing a great model with a harness that makes it stall.

A good model in the wrong harness can stall. The pairing is the decision.

The Pexon view: multi-harness orchestration

Our position is that model and harness must be chosen separately, and that the orchestration layer is where we add the value. We are not bound to one harness — we pick the right one for the use case, build the tools, memory and loops as part of the platform, and route the right model to the right task: frontier for strategy, cheap for volume.

The honest caveat is that harness choice is critical and verification is mandatory. Without continuous testing and review, an agent drifts off course. And because the boundary between model and harness is moving, flexibility is part of the architecture: what lives in the harness today can be in the model tomorrow.

The honest risks. The model alone does not decide — the harness often makes the difference, so comparing only models misses the real lever. Harness choice is critical: a good model in the wrong harness can stall. Verification is mandatory — without continuous tests and review, an agent drifts. The boundary is fluid, so plan for flexibility. And operation is decisive: harness configuration, memory and loops must be maintained and monitored.

Sources: Anthropic — Building effective agents. Read 2026-08-28. Vendor documentation changes; verify against the current release.

Keep reading

Questions we get asked about model and harness choice

What is an agentic harness?

The packaging around a model that turns it into an agent: tools for files, code, web and computer use, memory for persistence and context, and the agentic loop of plan, act, observe and repeat with ongoing verification. The model is the brain; the harness is the body.

Which matters more — the model or the harness?

Both, but the recent performance gains have come mostly from the harness: better tools, memory management and smarter loops with verification. The model gaps between the top labs are small. The question to ask is which model in which harness for which task.

Why should I choose model and harness separately?

Because a model can excel in one harness and stall in another — the harness determines what the model can reach and how it verifies its work. Choosing them independently keeps you from being locked into a single ecosystem and lets you combine the best of both.

Is verification really part of the harness?

Yes, and it is where modern harnesses earn their keep. Continuous testing, screenshots and review models keep an agent on course over long runs. A model that checks its own work runs longer without drifting — that capability lives in the loop, not the weights.

Next step

Get the model-harness pairing decided on your work

Two weeks, fixed price. We run your real tasks through the model-harness candidates, score the results, and hand over the pairing that fits each workflow. The pairing is yours whether or not we build it.