Agent applications depend on both the model and the environment around it. The same model can produce different results with different context, tools and settings. The surrounding layer is called a harness. These principles help a company assess it before connecting business data.
A model processes its supported input modalities, which may include more than text. An agent application uses a cycle of observation, choosing a step, using a tool and checking the result. The harness organizes context, tools, permissions and stopping conditions. Quality depends on the whole configuration. Start with a concrete process, data and a measurable result.
Model vs. agent: the difference is the loop
A model produces output from inputs and context. An application can return tool results and allow another step. Browser chat can search, work with files or use tools too; the interface location does not distinguish chat from an agent.
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 cycle describes a way of working; it does not prove the result was verified. What matters is the evidence and stopping conditions, such as a passed check, exhausted budget or handoff to a person.
Picture a customer enquiry. The agent reads the message, identifies missing context, retrieves it with an allowed tool and checks whether it actually supports the answer. The result of one step determines the next.
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. Context, notes and decision history can support continuity. Track provenance, updates and retention; incorrect records can affect later steps.
- Checks. Tests, review and approval verify specific outcomes. Confident wording is not evidence of accuracy; a model may also express uncertainty or stop.
- 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.
Claude Code and Codex combine models, tools and run orchestration. Anthropic and OpenAI also develop their own models; their work is not limited to the harness.
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:
- Chat without connected tools: works with available context; the user checks the result. Other chat modes may have tools.
- 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.
The model, settings and harness can all change the result. Compare them on the same tasks, including accuracy, review time and cost. Harness investment does not universally pay back more than a newer model. See the AI development workflow.
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. Record necessary events, permissions, changes and failures. Minimize personal data and secrets, restrict access and define retention. Copying everything an agent reads is not automatically an appropriate audit trail or proof of compliance.
Inputs as data, not commands. Emails and pages can contain malicious instructions. Separating untrusted content, restricting permissions, validating tools and requiring approvals reduces prompt-injection risk. No prompt or harness alone guarantees its elimination.
An email makes the distinction concrete: an assistant can read source material and prepare drafts, while permission to send comes only after a person reviews them. A sentence saying "never send anything" does not replace an enforced tool boundary.
What a company should take from this
Three things I say at every training session:
1. Describe the process first. What happens after an enquiry, which data is missing, who decides and what counts as failure? Compare a simple rule, conventional automation and an agent. A first pilot need not start with a custom system.
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. Assess the whole system. Alongside model quality, examine permissions, logs, verification, costs and the ability to change providers. Models and harnesses can both change; verify portability in advance.
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 processes supported inputs; an agent application may repeatedly use tools and their results.
- Harness = rules, tools, memory, checks, permissions. It's what turns a model into a usable worker.
- Results depend on model, context, settings and harness. Measure changes on the same tasks.
- 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: start with the process and data, then compare the complete solution by quality, costs and risk.
Frequently asked questions
Is an AI agent smarter than ChatGPT?
Not necessarily. Agent describes how a model and tools are connected, not a level of intelligence. ChatGPT can also have agentic features. Compare specific models, modes, permissions and results.
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
- Anthropic: Building effective agents, workflows, agents and evaluation of outcomes
- OpenAI Codex CLI, OpenAI's local coding agent