WHAT A HARNESS IS

EXAMPLES Example 1: A command-line coding agent. A command-line interface (CLI) is a program you use by typing text commands in a window rather than clicking buttons. Suppose a coding agent runs in such a window. You type, "Fix the failing test in the checkout module." The harness takes your request and builds the first message for the model, including the standing rules and a description of the available tools. The model replies that it wants to run the command that lists the project files. The harness checks the permission rules, sees that listing files is allowed, runs the command, and sends the list back to the model. The model asks to open the checkout file, the harness opens it, and so on. Each of these steps, the loop, the command execution, and the feeding back of results, is the harness. The model only wrote text requests and reasoning. If the model asked to run a command that deletes everything, the harness could refuse, because the rules are in the harness, not in the model. Example 2: The control plane in customer support. Imagine a company with three specialized agents: one for billing questions, one for technical problems, and one for escalations to human staff. A ticket arrives that reads, "I was charged twice and now the app will not open." The control plane examines the ticket, perhaps by using a small model call to classify it, and decides that the billing agent should handle the first part and the technical agent the second. It sends the ticket to the billing agent first. Suddenly the billing agent crashes because a database is unavailable. The control plane notices the failure, retries once after a short pause, and, when that also fails, routes the ticket to the escalation agent with a note explaining what was tried. The user is never left in silence. No individual agent decided any of this, because the control plane did. Example 3: The brain without a body. A human brain cannot move a hand unless nerves, muscles, and a skeleton carry out the command. In the same way, a model cannot read a file or send an email without the harness providing the hands. Suppose a model writes the sentence, "I will now email the customer." Nothing has happened yet, because the sentence is only text. The harness must recognize it as a request for the email tool, check that sending is permitted, call the email service, and report back whether it succeeded. Only then has the email been sent. Beginners often assume that when a model says it did something, it did. A good harness engineer knows that only the harness can make real things happen, and that a model's claim of an action is not proof that the action occurred. Example 4: One model, two harnesses. Consider a chat widget on a company website and an autonomous coding tool. Both could call the very same underlying model. The chat widget's harness keeps answers short, forbids any tool use, filters offensive language, and stops after one reply. The coding tool's harness allows file edits and command execution inside a sandbox (a fenced-off area where mistakes cannot damage anything outside it), keeps long histories, runs for hours, and checkpoints (saves a restore point of) its progress. Users would describe these two products as feeling completely different, even though the engine inside is identical. The difference is almost entirely the harness.