Two AI products can use the same underlying model and still feel like different generations of software. In one product, the model answers a question and waits. In another, it reads a repository, runs commands, checks its work, and keeps going until it has completed a software task.
The model matters, but it does not explain the whole difference. The surrounding system decides what the model can see, what it can do, what it remembers, how long it can work, and how its output is checked. That surrounding system is often called the agentic harness.
A useful way to think about an agent is simple: an AI agent is a model operating inside a harness. The model supplies the reasoning and generation. The harness connects that capability to a goal, an environment, and a controlled process for taking action.
The same model can produce a different product
Imagine placing the same language model in two applications. The first application sends it a message and displays the reply. The second gives it access to project files, a terminal, documentation, tests, and a record of previous steps. It also lets the model choose the next action after seeing each result.
The model has not changed. Its working conditions have. One application asks it to produce an answer. The other gives it a way to perform a task.
This is why product comparisons based only on the model name are incomplete. A capable model inside a weak harness may lose track of the goal, use tools badly, or stop before checking its output. The same model inside a well-designed harness can gather the right context, recover from errors, and produce evidence that the work is complete.
Model, product, and agent are not synonyms
The terminology gets blurred because product names and model names are often discussed together. ChatGPT is a product. GPT models are models that products can use. Claude is used as both a model-family name and a product name, so the surrounding context matters.
A model is the trained neural network that receives input and generates output. On its own, it does not reach into a laptop, open a private file, browse a website, or execute a command. An application must expose those capabilities and return the results to the model.
This is the brain-in-a-jar part of the analogy. The brain may be capable, but the jar defines what reaches it and what it can affect. An agentic harness gives the brain senses, tools, working practices, and boundaries. The analogy is imperfect, but it captures the key point: intelligence and agency are related, not identical.
An agent goes beyond a single response. It can direct parts of its own process, choose tools, observe results, and adjust its next step. The autonomy is still bounded by the harness, the permissions it grants, and the goal set by the user.
The five jobs of an agentic harness
Different products divide these responsibilities in different ways, but a useful harness usually performs five jobs.
- Assemble the right context. The harness supplies system instructions, user requests, relevant files, documentation, retrieved records, and recent tool results. Good context management is selective. Loading everything at once can crowd out the information that matters.
- Expose tools and an environment. Tools let the model read and write files, run code, search the web, query a database, call an API, or operate software through computer use. A coding harness may provide a shell and an isolated workspace. A customer-support harness may provide account, order, and ticket tools instead.
- Preserve useful state. A model call does not create durable memory by itself. The harness stores thread history, project instructions, plans, and task state, then supplies the relevant parts later. During long sessions, it may compact older context so the task can continue without carrying every raw tool output forward.
- Run the control loop. The model chooses a next step, the harness performs the permitted action, and the result returns to the model. The model then plans again. This plan, act, observe, and adjust cycle may run once or continue for hours.
- Enforce boundaries and verification. The harness controls filesystem access, network policy, credentials, approvals, time limits, and sandboxing. It can also make tests, screenshots, static analysis, or a second review pass part of the working loop. These checks do not guarantee correctness, but they make unsupported completion claims harder to hide.
The design of each part affects the result. A tool with an unclear description can lead the model to call it incorrectly. A poor retrieval system can provide plausible but irrelevant context. A loop with no stop condition can waste time. A verification step that checks only whether code compiles can miss whether the feature meets the user's goal.
What MCP standardises
The Model Context Protocol, or MCP, is often mentioned in the same conversation as agentic harnesses. It solves a narrower problem. MCP defines a standard way for a host application to connect to servers that expose tools, resources, and prompts.
That makes integrations more portable. A service can expose a tool through MCP instead of building a separate custom connector for every compatible host. The host still decides whether to connect, which capabilities to accept, what context to share, and when the model may use the tool.
MCP is therefore part of the connection layer, not the whole harness. It does not decide the agent's goal, manage the complete loop, compact the conversation, or prove that an action is safe. Those remain responsibilities of the host and the wider product design.
Why the distinction matters
Once the model and harness are treated as separate parts, several confusing AI discussions become easier to evaluate.
Asking whether "AI is good at coding" is too vague. A better question is whether a particular model, inside a particular coding harness, can work in your repository with the right tools, constraints, and verification. The same applies to customer support, research, finance, operations, and other workflows.
Model upgrades still matter. Better reasoning, instruction following, and tool use raise the ceiling of what an agent can do. But product capability can also improve without changing the model. Better context selection, clearer tools, safer permissions, durable task state, and stronger verification can all change the outcome.
This also explains why a model leaderboard is not a product evaluation. Benchmarks can tell us something about the model under defined conditions. They do not tell us whether a product can access the right data, survive a long task, recover from a failed command, respect company policy, or show evidence for its answer.
How to evaluate an AI product
Leaders choosing an AI product should examine the harness as closely as the model. I would ask seven questions.
- Context: What information can the system retrieve, and how does it decide what to include?
- Tools: What actions can it take, and are the tool interfaces clear enough for reliable use?
- State: What persists across steps and sessions, and how can users inspect or remove it?
- Control: When does the agent act independently, stop, or ask for approval?
- Security: How are credentials, private data, network access, and execution environments isolated?
- Verification: How does the system test outputs and show evidence instead of merely reporting success?
- Fit: Does the whole system match the actual workflow, risk level, and accountability model of the organisation?
These questions reveal product differences that a model name cannot. They also make pilots more useful because the evaluation measures the work system rather than the quality of a few chat responses.
The boundary is moving
The line between model and harness is not fixed. Some behaviours that once required elaborate orchestration are increasingly trained into models. Models are becoming better at planning across long tasks, choosing tools, noticing errors, and following structured working methods.
The movement goes both ways. Behaviour that appears to come from the model may actually depend on project instructions, tool design, context ordering, or a hidden review step. A product team can shape consistency and judgment through the environment even when it cannot change the model weights.
That is another reason to avoid treating the model as the entire product. The practical unit of capability is the complete system that receives a goal and produces a checked result.
FAQ: models and agentic harnesses
Is ChatGPT a model or an agentic harness?
ChatGPT is a product that can use different models and product-level capabilities. Depending on the mode and task, those capabilities may include tools, memory, browsing, file handling, or agentic workflows. Referring to ChatGPT as a model hides those layers.
Is MCP an agentic harness?
No. MCP is a protocol for connecting host applications to servers that expose tools, resources, and prompts. A harness may support MCP, but it still needs to manage context, state, the agent loop, permissions, and verification.
Can a better harness make the same model perform better?
Yes, on a defined workflow. Giving the model relevant context, reliable tools, persistent task state, clear boundaries, and meaningful checks can improve completion quality. That does not make the harness a substitute for model capability. It means the two parts multiply each other's strengths and weaknesses.
The bottom line
The model is only half the agent. It supplies the intelligence that interprets the goal and chooses what to do next. The harness determines what information reaches it, what actions are available, how the work continues, and whether the result earns trust.
The brain will keep getting smarter. The jar is changing too. For anyone building, buying, or governing AI systems, understanding both parts is now a practical requirement.