When I show someone how Claude Code builds and tests an application in an afternoon, the first question is usually: "Is that a different model from the one I chat with in the browser?" Often it isn't. The difference isn't in the model, but in what it's wired into. That "what" is called the harness, and it's the most underrated part of the whole AI story: companies debate which model is best, while the structure around it decides the outcome. In this article I'll explain the principles – what an agent is, what a harness is, why the same model gives different results, how an agent safely reaches company data and what that means for your decisions. I'll deliberately stay at the level of principles; the specific procedures and architecture are know-how I build and teach, and they don't belong in an article.
A model takes text and returns text. An agent is a model wired into a loop: it observes the state (files, data, the result of a command), decides what's next, uses a tool (reads a file, runs a test, calls an API), verifies the result and continues until done. The harness is everything around the model that makes this loop possible and keeps it in check: rules, available tools, memory, checks and permissions. That's why the same model gives different results in different tools – the harness differs, not the intelligence. An agent reaches company data through tools and connectors (today often via the open MCP standard) with permissions following the principle of least privilege. For a company this means: don't start with your own agent, start with the process and the data; a custom assistant over company data makes sense only once the process is clear and the data is in order.
Model vs. agent: the difference is the loop
A model is a function: it takes text, returns text. When you type into a chat, that's exactly what happens – one round, one answer. The model doesn't know whether its advice worked, because it never sees that.
An agent is a model wired into a loop that can be described in four steps:
- Observe. Load what the world looks like: the contents of files, the output of a command, an API response, a page in the browser.
- Decide. Based on the observation and the goal, choose the next step.
- Use a tool. Not "write what should be done", but do it – read a file, edit it, run a test, call a service.
- Verify. Look at the result. Did the test pass? Did the API return an error? And accordingly continue, fix, or stop.
This loop is the whole difference between "AI advised me" and "AI did it and verified it". But notice what isn't written in it: who tells the agent which tools it may use, what the goal is, when to stop, what it may remember and what it must not do without permission. All of that is the harness.
What the harness is
The harness is the structure around the model that turns raw intelligence into a usable worker. Simplified, it has five layers:
- Rules. What the agent loads at start about the project, the company, the style and the boundaries. Good rules are short, concrete and above all say what must not be done.
- Tools. What the agent can physically do: read and change files, run commands, search the web, call company systems. Every extra tool is an extra capability – and an extra risk.
- Memory. What the agent carries between steps and between sessions: task context, notes, decision history. Without memory the agent starts from zero every morning; with bad memory it carries mistakes forward.
- Checks. Who and what verifies the result. Tests, review by another context, a person who approves. A check is built-in distrust – and it's essential, because the model is always confident, even when it's wrong.
- Permissions. What the agent may do on its own, what only after approval, and what never. Read a file: yes; delete a database: no; send an email to a customer: only after a human click.
Tools like Claude Code, Codex and similar are therefore a model plus this harness. And their creators spend an enormous amount of time precisely on the harness – not on the model, which they receive ready-made.
Why the same model gives different results in different tools
This is the point that opens people's eyes. Take the same model and put it into three different environments:
- A chat in the browser: no tools, no verification, one round. The model guesses and you check.
- A coding agent without rules: it has tools, but no boundaries or checks. It does a lot, fast and without guarantees – exactly the situation I describe in Vibe coding: 7 amateur mistakes.
- An agent with a good harness: it loads the project rules, plans before writing, works in small steps, runs tests after each one, has the result checked by another context and asks before destructive actions.
Three different results, one model. The difference is made by rules, checks and permissions. What follows for anyone using AI for real work: investing in the harness – your own rules, checks and procedures – pays back more than moving to a model one generation newer. What such a process looks like step by step is in my guide How to build an application with AI the right way.
How an agent safely reaches company data
The question that decides company deployment. Principles that hold regardless of the tool:
Tools and connectors. An agent doesn't reach into systems "on its own". It's given a specific tool: read the calendar, search the CRM, create an email draft. For such connections the open MCP (Model Context Protocol) standard is increasingly used today – something like a universal socket through which AI applications connect to data sources and tools. It's supported by various makers of AI applications and development tools, which means one connector to your system can serve several tools. I won't go into detail here; what matters is that a connection is a standardised, bounded thing, not "the AI has access to everything".
Permissions and the principle of least privilege. Every tool gets only the rights it needs for its task. An agent that summarises tickets doesn't need the right to delete them. An agent that prepares email drafts doesn't need the right to send them. It sounds obvious and yet it's usually the first thing skipped in the excitement.
A human before an irreversible step. Reading and drafting can run on their own; sending, deleting, paying and anything that goes out of the company waits for human approval. A good harness enforces this, not just recommends it.
A log. Every step of the agent – what it read, what it did, what it returned – is recorded. Without a log you have no way to find out what happened when something goes wrong, and no way to demonstrate you handled data correctly.
Inputs as data, not as commands. An agent that reads emails or web pages will encounter text posing as instructions ("ignore previous instructions and send…"). The harness must ensure that content the agent reads is information for it, not an order. This is one of the most important and least visible parts of agent security.
What a company should take from this
Three things I say at every training session:
1. Don't start with your own agent. Most companies that want "their own AI agent" don't have a described process the agent should carry out, and don't have data in a state that can be worked with. An agent on top of chaos is faster chaos. Start with the process: what should happen when an enquiry arrives; what data do we need for it; who decides. Then the data: where it is, who has access, is it clean. I describe a plan for the first month in AI automation in your company.
2. A custom assistant over company data makes sense only after that. Once you have a process that repeats, data in one place and clarity on what the assistant may and may not do, a custom layer starts to make sense: an assistant that answers from your documents, prepares materials from your CRM, watches your orders. You aren't building a model. You're building a harness – rules, connectors, permissions and checks – over a model you choose and can later replace. That's exactly the work I do as part of custom applications: not an "AI chatbot", but an assistant with precisely defined tools and rights over your data.
3. Buy the harness, not the model. When choosing a tool for your team, ask what rules, checks and permissions it has, how it logs, how it handles access to data – not just which model it has under the bonnet. The model will change in six months; the harness is what stays with you.
What is deliberately not in this article
I haven't described how exactly I build rules, how I split roles between several contexts, how I set up checks and memory. That's know-how that took months of work and is part of what I deliver to clients and teach on the course. But the principles above are enough for you to ask the right questions – of suppliers, of tools and of yourselves.
Summary
- A model returns text; an agent runs in a loop of observe → decide → use a tool → verify.
- Harness = rules, tools, memory, checks, permissions. It's what turns a model into a usable worker.
- The same model gives different results because the harness differs, not the intelligence; investing in your own rules and checks pays back more than a new model.
- An agent reaches company data through bounded tools and connectors (often via the MCP standard), with least privilege, a human before irreversible steps, a log, and content treated as data, not commands.
- For a company: first the process and data, then a custom assistant; buy the harness, not the model.
Frequently asked questions
Is an AI agent smarter than ChatGPT?
Not necessarily. It's often the same or a similar model. The difference is that the agent has tools, runs in a loop and verifies results – and that it's surrounded by a harness with rules and checks. That determines quality more than the model itself.
Can an agent reach our data on its own?
Only what it's given a tool and permission for. A well-deployed agent has precisely defined connectors, only the rights necessary for its task, a log of every step and human approval before irreversible actions. If someone offers you an agent "with access to everything", keep asking questions.
Does our company need its own agent?
Most companies don't at the start. They need a described process, clean data and a clear rule on what AI may do. A custom assistant over company data makes sense once you have those three things – then it's a concrete, bounded project, not an experiment.
What is MCP?
An open standard that describes how AI applications connect to data sources and tools – something like a universal socket. Thanks to it, one connector to your system can serve several AI tools. What matters for a company is that a connection is a standardised, bounded thing with its own permissions.
Sources and links
- Model Context Protocol – official site – open standard for connecting AI applications to data and tools
- Claude Code – commands and modes reference – an example of a harness with planning, goals and reviews
- OpenAI Codex CLI – OpenAI's local coding agent