Agent Harness Engineering
There is a decomposition that has quietly become the standard way to talk about agent systems, and it fits on one line:
Agent = Model + Harness.
The model reasons about a problem and decides what to do next. The harness is everything else — the software that turns those decisions into actions, and that decides which decisions are allowed to become actions at all. It is the runtime shell around the model: the code that receives a structured tool call, validates it, checks it against a permission policy, executes it inside some isolation boundary, caps and shapes the result, writes that result back into the model's context, and records the whole thing so a human can reconstruct what happened. Swap the model underneath a good harness and you still have a working agent. Swap the harness out from under a good model and you have a chat window.
This subject treats the harness as its own architectural layer, with its own design decisions, its own failure modes, and its own engineering discipline — because in practice that is where most agent reliability and essentially all agent security actually live. agent-architectures-and-the-agentic-loop is the sibling subject and the right thing to read first: it covers the decision shape of an agent (observe → decide → act → repeat, ReAct, plan-act-observe-reflect, when not to build an agent at all, budgets and termination). That subject says, in one line, "the model proposes; something else executes it after a permission check." This subject is about that something else: what it is made of, how its layers compose, what it costs, and how it fails. The loop is the algorithm; the harness is the execution substrate the algorithm runs on.
The framing matters because of a single asymmetry that recurs throughout everything below. A model that declines to do something dangerous is expressing a preference. A harness that will not execute it is enforcing a control. Preferences can be argued with — by a clever prompt, by an injected instruction inside a web page, by an ambiguous task description. Controls placed outside the model cannot be argued with, because the thing doing the arguing has no access to them. Every serious harness design decision is ultimately an application of that asymmetry: move the thing you actually need to be true out of the model's judgment and into code.