Skip to main content
// Learn / Concepts

What is an AI agent harness? Plain-English_

An agent harness is the software that wraps a language model and turns it into something that can take real actions — edit files, run commands, remember between turns, recover from errors. Claude Code, Cursor, Cline, Aider, and OpenClaw are all harnesses. The model inside is roughly the same. The harness around it is doing the work you actually feel.

Why it exists

A bare language model cannot do anything on its own.

The model is a function. Text in, text out. It does not have memory between calls. It cannot open a file. It cannot run a command. It does not know what day it is. If you call the raw Claude API and ask it to "refactor the authentication module," it will produce text describing a refactor. It will not actually change any code. It cannot. There are no hands.

Everything you experience as "AI doing something" — the file actually got edited, the command actually ran, the test actually passed — is the harness doing that work. The harness reads your file, gives the relevant parts to the model, takes the model's response, parses it for instructions, executes them, checks the results, and decides whether to call the model again. The model is one step in a much bigger loop.

Harnesses exist because someone has to do that loop. You could write it yourself — and a lot of people have, badly — or you could use one of the production-grade harnesses that has been refined over thousands of hours of real use. That is the trade. Every AI coding tool you have heard of is essentially a different opinion about how that loop should work.

What it actually does

The five jobs of an agent harness

1. Context management

The model has a finite context window. Your codebase does not fit. The harness decides what to put in — which files, which conversation history, which system instructions — and what to leave out. Good context management is most of what makes a harness feel "smart." Bad context management is most of what makes it feel "dumb."

2. Tool exposure

The harness defines which tools the model can use — read file, write file, run command, search the web, query a database, call an MCP server. Each tool is a declaration the harness makes to the model: "if you want to do X, ask me to call this tool." Tool design is opinionated work. The same job (editing a file) can be exposed as one big tool or five smaller ones, and the design choice changes how the model behaves.

3. The agent loop

After the model responds, the harness has to decide: are we done, or do we call the model again? If the model used a tool, the harness runs the tool, feeds the result back to the model, and re-asks. If the model made an obvious mistake, the harness can catch it and re-prompt. The shape of this loop — how many turns, what triggers another turn, what counts as "done" — is the heart of the harness. It is where every harness differs most.

4. Memory and state

Some things should persist across sessions: project conventions, prior decisions, things the user explicitly asked the AI to remember. The harness manages this. Different harnesses have wildly different memory models — some write to a file you can edit, some have a structured store, some have no persistent memory at all and start fresh every session.

5. Lifecycle hooks

Good harnesses let you customize behavior at specific points — before a tool call, after a file edit, when the session starts, when an error happens. These hooks are how teams encode their own conventions ("always run the linter after editing a file," "never push to main without confirmation"). The more thoughtfully a harness exposes these, the more it can be made to fit a specific team's workflow.

How harnesses differ

Five harnesses, five very different opinions

Here is a quick read on the ones most people compare. None of these are exhaustive — read each tool's own docs for the current state — but the shape of the differences is the point.

Claude Code

Terminal-based, agentic, opinionated about file editing. The default Anthropic experience for coding. Strong default skills system, native MCP support, good for long-running multi-step tasks. Pairs naturally with Claude as the model (it is the harness Anthropic built around their model).

Cursor

A fork of VS Code with AI baked in deeply. More IDE than terminal. Excellent for in-editor edits, quick refactors, and chat-while-coding. Tool calling is solid but less aggressive about taking multi-step action than Claude Code. Lets you swap models freely.

Cline

An open-source VS Code extension. More agentic than Cursor, more visual than Claude Code. Sits inside your existing editor instead of replacing it. Good fit for teams already on VS Code who want agentic capabilities without changing their setup.

Aider

Terminal-based, focused tightly on git-aware file editing. Minimal opinion about agent loops — it is more "AI that edits files for you" than "agent that takes initiative." Excellent if you want precise control and small, reviewable diffs.

OpenClaw

A community-extensible fork of Claude Code. Same core terminal-agent experience, with a plugin system that lets the community add capabilities the upstream tool does not have. Good for people who want Claude Code's defaults plus the ability to extend.

None of these is "best." Each is the right answer for a different workflow. Solo devs hacking on side projects tend to prefer Claude Code or Aider for the terminal speed. Teams doing PR-driven work tend to prefer Cursor or Cline for the IDE integration. Tinkerers prefer OpenClaw because they can extend it.

When to pick which

A rough decision guide

If you… Start with
Live in the terminal and want serious agent capability Claude Code
Want an IDE-first experience with great inline AI Cursor
Use VS Code and do not want to switch editors Cline
Want minimal magic and precise git-aware edits Aider
Want Claude Code's defaults plus the ability to extend it OpenClaw
Are setting up an agency or team and need consistency Pick one, standardize, write skills

For the head-to-head matchups, read Cline vs Cursor, Claude Code vs Codex, or OpenClaw vs Claude Code.

FAQ

Common questions about agent harnesses

Is "agent harness" an official industry term?

+

It is a working term that has caught on in the AI engineering community over the past year, particularly among people building agentic tools. There is no formal standards body. Other names you will see include 'agent runtime,' 'agent framework,' 'agent loop,' and 'agent scaffolding.' They mean roughly the same thing: the surrounding software that turns a stateless language model into something that can take multi-step actions. The word 'harness' caught on partly because it captures the right idea — it is the thing you strap onto the model to make it pull a workload.

Is Claude Code the same as Claude (the model)?

+

No, and this is the most common confusion. Claude is the language model — the thing Anthropic trains and serves via API. Claude Code is the agent harness that wraps it for terminal-based coding work. The model is one component inside the harness. When people say 'Claude Code is good at X,' they almost always mean 'the combination of the Claude model plus the Claude Code harness is good at X.' Swap out the harness — say, use the same model in Cursor or Cline — and the experience changes significantly.

Can I use Claude Sonnet in a different harness?

+

Yes. The Anthropic API exposes the models, and any harness can call them. Cursor lets you pick Claude as the model. Cline does too. Aider supports Anthropic models. The model is portable. What is not portable is everything else the harness does — how it manages context, when it decides to use tools, how it handles file edits, what it does on error. The same Claude Sonnet behaves visibly differently in three different harnesses because the rest of the system is doing different work.

Why does the same model feel smarter in some tools than others?

+

Because most of what you experience as 'AI quality' is harness quality. The model is one input. The harness decides what context to give the model, what tools to expose, when to ask the model again, how to handle the model's output. A harness that gives the model good context and crisp tools makes the model look brilliant. A harness that floods the model with junk or hides important state makes the same model look stupid. This is why people swap harnesses without swapping models and feel like they got an upgrade.

Do I need to understand harnesses to use AI for coding?

+

No to use, yes to choose. If you have already picked a tool you like, you do not need to think about this. If you are picking — or your team is — understanding what makes a harness good is most of how you decide. The model question is usually 'which family' (Claude vs GPT vs open weights). The harness question is the bigger one: which tool, which workflow, which integration points. Spending an hour on harness comparisons before committing pays for itself many times over.

Are open-source harnesses better than commercial ones?

+

Different tradeoffs. Open-source harnesses (Aider, Cline, OpenClaw, plus various community forks) give you full control — you can read the code, modify the loop, add tools, change behavior. Commercial harnesses (Cursor, Claude Code, GitHub Copilot) optimize for polish and out-of-the-box experience. For solo devs who like tweaking, open-source often wins. For teams that need things to just work, commercial often wins. The choice is more about your tolerance for fiddling than about quality.

How fast is this changing?

+

Quickly enough that anything written here will be partially out of date in three months. The shape of harnesses is stabilizing — most of them now have similar features (file editing, tool calling, memory, MCP support). The specifics — which one is best at what — shifts constantly. If you are picking today, pick based on the workflow that fits your team and accept that you might switch in six months. That is fine. The skills and knowledge transfer.

// Ask the duck

Want the right harness picked for your team?

Picking a harness is one decision. Configuring it well — skills, MCPs, hooks, defaults that match how your team actually works — is the other ten. Tell the duck what your team does, what they use today, and what is broken about it. You will get a real recommendation, not a "depends on your needs."