Agent Harnesses and MCP
An AI model on its own only produces text. Everything that lets it read your files, search a knowledge base, run code or send a message is supplied by software wrapped around it. That software is the harness. A useful way to remember it: the model is the engine, and the harness is the rest of the car.
What a harness does
Builds the context. On each turn the harness assembles what the model sees: the system prompt, the conversation so far, relevant files or retrieved documents, and descriptions of the tools it may use, all fitted inside the context window.
Runs the loop. It sends that context to the model and reads the reply. If the model asks for a tool, the harness runs the tool itself and feeds the result back. The model never acts directly. It only requests, and the harness decides what actually happens.
Enforces permissions. Which tools exist, which files they can touch and which actions need a person to approve are all harness decisions. Sandboxing, allow-lists and approval prompts live here, not in the model.
Manages memory. Long tasks outgrow the context window, so the harness trims, summarises or stores notes outside the model and brings back what is relevant. A knowledge base is usually exposed to the model as a retrieval tool that the harness runs.
Keeps records. Good harnesses log every request, tool call and result. That log is what makes an agent's behaviour auditable.
Model Context Protocol (MCP)
Connecting a harness to each business system used to need custom code. The Model Context Protocol (MCP) is an open standard for that connection. A system publishes an MCP server describing the tools and data it offers, and any MCP-capable harness can use it, much like a standard port for AI tools. MCP standardises the plumbing, not the safety: a connected tool still needs tightly scoped permissions, and whatever it returns is still untrusted input.
Why the harness matters as much as the model
Two products built on the same model can behave very differently, because quality, cost and safety depend on the harness. Better context management means fewer mistakes on long tasks. Tighter permissions mean a smaller blast radius when something goes wrong. Claude Code and the agent mode in ChatGPT are examples of harnesses, and so are the agent features built into many business applications.
Common failure modes
Loops that never finish and quietly run up cost. Context overflow, where the model loses earlier instructions. Permissions much broader than the task needs. And prompt injection through tool results: a web page, email or document the agent reads contains instructions, and the model treats them as its own. The defences are harness features, including step and spend limits, scoped credentials, human approval for irreversible actions, and treating everything a tool returns as untrusted data.
Questions to ask about any harness
What tools can it use, and with what permissions? What data can it see, and where is that data processed? Which actions need a person's approval? What stops a runaway loop? Is every action logged, and can you review the log?
When an AI agent disappoints or misbehaves, look at the harness before blaming the model. Most failures in practice are context, permission and tooling problems that a better harness design would have prevented.