Model, harness, agent: what are we actually talking about?

At a dinner party recently, I was talking with an engineer who works in the software department of a large shoe manufacturing brand. We got into a debate about Cursor. He described it as an agent. I argued that it was an agent harness.

That exchange stayed with me because it exposed a real ambiguity. We use “model,” “harness,” and “agent” as if they describe competing products. Usually, they describe different layers of the same system.

My distinction was useful, but my correction was too absolute. Cursor provides a harness and a built-in coding agent. Saying “Cursor is an agent” can describe the experience someone uses. Saying “Cursor provides an agent harness” describes part of the architecture behind it. Cursor’s own learning guide describes both.

Three terms, three questions

A working vocabulary for modern LLM-based systems

Layer	What it does	Concrete examples
Model	Processes context and generates an answer or proposed action.	Claude Sonnet 4.5; Gemini 2.5 Pro.
Harness	Assembles context, executes permitted tool calls, and manages the loop.	Cursor’s runtime; the Claude Code runtime exposed through the Claude Agent SDK.
Agent	Uses the model and runtime to pursue a goal, responding to results.	Cursor Agent investigating a bug; a custom inventory agent investigating stock discrepancies.

These are working definitions, not a universal standard. Some teams include the selected model when they describe a harness; others reserve “harness” for the software around it. Here, I use the second meaning so we can examine each responsibility separately.

The model: capability on a call

A language model is a trained computational system. Given context, it can generate text, code, or structured output. In a tool-enabled application, that output may request an action: search a repository, read a file, or run a test.

Examples of models: Claude Sonnet 4.5 from Anthropic and Gemini 2.5 Pro from Google are named model releases. These illustrate the category, rather than recommending a current version. A model can power a chat application, a fixed workflow, or an agent.

But generating a request to run a command and executing that command are different operations. The model can propose an edit. Something outside the model must apply it to a real file.

Imagine asking: “Why does our inventory service show the wrong available quantity?” A model given the relevant code might explain a likely bug and propose a patch. Its answer can be useful even if no software has been changed. To investigate the repository and validate the fix, the surrounding application needs to provide more capabilities.

The harness: the machinery around the model

An agent harness is the runtime software that connects model calls to a working environment. A coding harness commonly handles:

• Context: instructions, conversation history, relevant files, and tool results.
• Tools: searching, reading and editing files, running commands, or accessing other services.
• Control: calling the model again after a tool result, tracking progress, and deciding when execution must stop.
• Boundaries: permissions, approval checks, execution limits, and isolation where provided.

Examples of harnesses: Cursor’s harness connects a selected model to repository search, file editing, and command execution. The Claude Agent SDK exposes the tools, agent loop, and context management that power Claude Code, letting developers use that runtime in their own applications. The SDK is the developer-facing way to use the harness; it is not itself a model.

Capabilities vary. Persistent memory, browser access, and multiple agents are optional features, not requirements for every harness.

This layer is substantial engineering. A powerful model given incomplete search results, unreliable tools, or a missing test environment can struggle. The same model with well-chosen context and reliable feedback may perform much better. Cursor describes model-specific tool and prompt tuning, plus evaluation of harness changes, in its engineering account of its harness.

That is why I would drop the word “just” from “just a harness.” The harness helps determine what the system can actually accomplish.

The agent: the system pursuing a goal

For this article, an agent is a system in which the model can choose meaningful next steps toward a goal, use available tools through the runtime, and adjust its approach based on the results.

Examples of agents: Cursor Agent is a coding agent: given a bug-fix task, it can inspect code, make edits, and run commands. A custom inventory-investigation agent is another possible example: it might inspect stock and reservation records, choose follow-up queries, and report a discrepancy with supporting evidence. The inventory agent is an illustrative design, not a named commercial product.

An agent can be paused, configured, or waiting for approval and still be an agent. An agent run is a particular execution of that system on a task.

It does not need consciousness, unrestricted access, or the ability to operate for days without supervision. A system that investigates a bug and stops before applying a sensitive change can still exhibit agentic behavior.

Follow one bug through all three layers

Consider a fictional task inspired by the industry my dinner companion works in: “Our inventory API sometimes reports negative available stock. Find the cause, fix it, and verify the change.” This is an illustration, not a claim about his employer’s systems.

1. The harness prepares the request. It supplies the task, project instructions, and available tools to the model.
2. The model chooses an investigation. It requests a search for the code that calculates available stock.
3. The harness runs the permitted search. The results become context for the next model call.
4. The model proposes a fix. Suppose it finds that a reservation is subtracted twice. It requests a targeted edit and a regression test.
5. The harness applies the allowed changes and runs the test. It returns actual output, including any failure.
6. The model responds to the evidence. It may revise the fix, investigate another path, ask for clarification, or report what passed and what remains unverified.

The model contributes decisions. The harness enables and constrains actions. The overall system’s pursuit of the task is the agent behavior. Passing one test is evidence about the fix, not proof that every inventory scenario is correct.

For a closer look inside this cycle, see how a turn works in an agent harness.

A tool call alone does not settle the question

Suppose an application always follows the same path: fetch stock levels, send them to a model for a summary, and display the answer. That is a useful AI workflow. The presence of a model and a tool does not automatically make it an agent under the definition used here.

The distinction becomes clearer when the model can decide whether to inspect reservations, compare warehouse records, or ask for a missing identifier based on what it discovers. Anthropic’s Building effective agents distinguishes predefined workflows from systems where the model dynamically directs the process and tool use.

Real applications often mix both. A fixed approval workflow might contain an agent that investigates exceptions. The useful question is how much discretion the model has at each step.

So, was my dinner companion wrong?

His description was reasonable at the product level. Mine highlighted an architectural layer. The mistake was treating those descriptions as mutually exclusive.

A more precise sentence would have been: “Cursor is an AI development product with a built-in coding agent; its harness connects the selected model to tools, context, and an execution loop.”

A brand name can cover several things. The editor interface, runtime, selected model, and agent experience do not become the same component simply because they appear in one application.

What engineering teams should ask instead

When someone demonstrates an “AI agent,” move from the label to concrete behavior:

• Which model is making decisions? Can it be changed, and does the runtime adapt to it?
• What can the system actually access and change? Look at tools and enforced permissions.
• Who chooses the next step? Distinguish fixed application logic from model-directed decisions.
• What happens after a failure? Can the system observe the result and revise its approach?
• What counts as completion? Ask for verification evidence, limits, and unresolved work.

Those answers tell you more than an agent badge. They also help diagnose failures: was the decision wrong, was necessary context missing, did a tool fail, or was the goal ambiguous?

The next time this comes up over dinner, I will start with the layers. The model generates decisions. The harness connects them to action. The agent combines those pieces to pursue a task. Understanding their relationship is more useful than winning an argument over a product label.

Sources checked 12 November 2026. Terminology varies across vendors; the definitions here are an architectural lens for LLM-based agents.