--- title: "What a Harness Is" slug: "chapter-17-what-a-harness-is" kind: "chapter" order: 18 label: "Chapter 17" chapter: 17 part: "The Agent Layer" partLabel: "Part V" partNumber: 5 epigraph: "The model decides. The harness decides what the model is allowed to decide." summary: "An agent is a model running inside a loop, and the loop is called a harness. The model supplies judgement; the harness supplies everything else: the tools the model may call, the memory it may cons…" words: 1236 topics: - "The loop" - "Nine attributes of a flexible harness" - "Memory in three scopes" - "The sandbox and the network boundary" - "The same harness on every surface" - "What to demand" --- An agent is a model running inside a loop, and the loop is called a harness. The model supplies judgement; the harness supplies everything else: the tools the model may call, the memory it may consult, the limits on what it may do, the record of what it did. When people say an AI product "has agents," the quality of those agents is mostly the quality of the harness. This chapter defines the harness and lists the attributes a CIO should demand of one. ## The loop Strip away the vocabulary and every agent does the same thing. It reads its situation: the conversation so far, the page in front of it, the results of its last action. It decides one next step: answer, or call a tool. If it calls a tool, the harness executes the call and feeds the result back. The agent reads again. This repeats until it answers or runs out of allowance. The browser extension in Chapter 15 runs exactly this loop against a web page. A research agent runs it against a document store. An operations agent runs it against the systems of record through the broker. The loop is identical; what differs is the tools and the limits. That is why the harness, not the model, is where an institution's control lives. ## Nine attributes of a flexible harness A harness that an institution can trust across many agents, surfaces and years has these properties. I list them because vendors rarely do. **Model-agnostic.** The harness calls the model through the standard interface from Chapter 5, so the model is a setting. A harness welded to one model inherits that model's lock-in. **Tool protocol, not hard-wired tools.** Tools arrive through the Model Context Protocol, so any connector from Part III is available to any agent, and a new connector needs no change to the harness. **Memory with scopes.** The agent can remember, and what it remembers is organized by whose memory it is and who may see it. The next section expands this. **A sandbox with a network boundary.** When the agent runs code, it runs in an isolated environment on infrastructure the institution controls, with explicit rules about what the code may reach. **Approval modes.** The harness can be set to act automatically or to pause for a human before consequential actions, per agent, per action class. **Budgets.** A run has a maximum number of steps and a maximum token spend. When it hits either, it stops and says so. **A stop button.** A human can end any run at any time, and the harness honours it immediately. **An audit trail.** Every step, every tool call and its parameters, every approval, written to a log the institution owns. **The same runtime everywhere.** The harness behaves identically whether it is driving a browser tab, running on a desktop, or executing on a server, because it is one implementation with different drivers underneath. An agent product missing more than one or two of these is a chat interface with function calling, and the institution should price it as such. ## Memory in three scopes Memory is what makes an agent feel like a colleague rather than a search box, and it is the attribute most likely to become a governance problem if it is designed casually. A sovereign harness keeps memory in three scopes, each with its own owner and rules. **Global memory** belongs to a person and follows them across every agent in the organization: their role, their preferences, the context they have shared. It is captured from conversations when the person allows it, and the person can read, edit and delete it. **Agent memory** belongs to a person and one agent: what this agent has learned about this person, filed by category, with an extraction prompt per category that an administrator can tune. Same rights: the person sees it, the administrator can manage it on their behalf. **Shared memory** belongs to the agent and to no person: standing facts, rules and background that every conversation with that agent should start from. Our refund window is thirty days. Always cite the policy handbook. Shared memory is written by hand, by someone accountable for it, and is never extracted from a conversation, because anything placed there reaches every person who talks to the agent. The harness enforces that by having no path to write it automatically. Three gates control whether any of this reaches a conversation, and they cascade: the organization's switch, the agent's switch, and the person's own. A person who turns memory off for themselves is off, whatever the organization decided. All three stores are rows in the institution's own database, inside its perimeter, behind its access controls, exportable like everything else. ## The sandbox and the network boundary Agents that only answer can be governed by the broker. Agents that act, by running code, transforming files, calling systems in sequence, need a place to act that cannot become a liability. The sandbox is that place: an isolated execution environment, started for a run and discarded afterward, on infrastructure the institution controls. Inside it the agent can write and run a script against data too large for any context window, process a batch of documents, or orchestrate a multi-step task. The boundary around it is a network policy: by default nothing, then explicit allowances for the systems the task needs, through the broker, under the user's identity. The code the agent wrote cannot reach the internet, the institution's other systems, or the harness's own credentials unless the policy says so. Guardrail frameworks of the kind NVIDIA ships with its agent tooling add a layer inside the loop: programmable rails that constrain the model's inputs and outputs, injection defences, PII redaction. Those are valuable. They complement the sandbox; they do not replace it, because a rail is advice to the model and a network boundary is a fact about the machine. ## The same harness on every surface The attribute that ties the client layer to the agent layer is that the harness is one implementation. The browser extension drives a tab with it. The desktop application drives local applications with it. The server runs scheduled tasks with it. An agent configured once, with its memory, tools, approvals and budgets, behaves the same way wherever the person meets it, and an administrator reasons about one thing rather than three. This is also what makes the demonstrations honest. When a CIO watches the browser agent refuse a password field, that refusal is the harness's, and it holds on the desktop and the server too. ## What to demand In an evaluation, ask to see the harness, not the model. Ask to see the loop's limits set and hit. Ask to see memory in its three scopes, and a person turning theirs off. Ask to see the broker refuse a tool the agent's role does not have. Ask to see the sandbox's network policy and what happens when code inside it tries to reach somewhere it should not. Ask for the audit log of the demonstration you just watched. A vendor whose harness has the nine attributes can show you all of this in an hour. A vendor whose product is a chat window will show you the model being clever. The difference is the whole of Part V, and the next chapter puts it in the frame most buyers will recognize.