THE THREE DISCIPLINES AROUND THE MODEL

HARNESS ENGINEERING Harness engineering is the practice of designing everything outside the model so that an agent runs reliably. It includes the loop that repeatedly calls the model, the tools the agent can use, the rules about what it is permitted to do, the budgets for time and money, the logging that records what happened, the checks that verify results, and the recovery plans for when things go wrong. Notice that context engineering is part of harness engineering, since the harness is what actually builds the context at each step. Likewise, the system prompt, which is a piece of prompt engineering, is something the harness manages and inserts. So the three disciplines nest. Prompt engineering lives inside context engineering, and context engineering lives inside harness engineering. The harness engineer has to understand the inner circles well, and then go further to handle things that prompts and context alone cannot solve, such as permissions, retries, budgets, and observability. A good way to see the difference is to imagine an agent that runs shell commands, meaning typed instructions to the computer's operating system, for hours with nobody watching. No prompt, however clever, can guarantee that such an agent will never run a dangerous command. A harness can, because it sits outside the model, intercepts each command, and checks it against rules before allowing it. This idea, that important protections should be enforced by code outside the model rather than requested politely inside the prompt, is one of the deepest principles of the field.