You are watching an agent work. It reads a set of versioned instructions, calls a tool, writes a file, runs a check. Then it tries to publish something outside your systems, and the run stops and waits for a person to say yes. You go looking for the sentence in the prompt that produced that pause, and there is no sentence. The model never chose to wait. It proposed an action, and something else declined to carry it out. That something else is usually described as the plumbing between the model and its tools. It is closer to being the thing in charge.

The stage manager calls every cue

In a theatre, the actor is the one everybody watches. The person deciding what happens next sits in a booth with the book open, calling cues: lights down, this entrance now, hold until the laugh dies. The actor supplies the performance. The caller decides when that performance is allowed to happen, and what follows it.

A harness works the same way, in layers. The loop coordinates execution. The tools bound what an action can touch. The context keeps state, so work survives an interruption. The gates verify a result before it counts. The team’s own rules turn one session’s lesson into something the next session inherits. Each layer either imposes a constraint or preserves evidence.

Concretely, an agent receives versioned instructions, runs a tool whose permissions are narrow, saves a checkpoint, passes a verification it did not run itself, and updates a project rule so tomorrow starts further along. The model’s judgment enters at one point in that sequence. Everything about what happens next, whether the action lands, whether the result counts, whether the run continues at all, is settled outside it. Nobody in the theatre calls the person with the book the glue between the actors and the lights.

Feature checklists hide where authority lives

The word harness gets attached to very different products, which makes comparisons quietly meaningless. A boundary helps. The harness orchestrates the agent: dispatching tools, granting permissions, holding context, managing the lifecycle of a run. A framework helps you build one, with graphs and abstractions and an SDK. A backend serves inference, routing and hosting the weights. Real platforms combine layers, but a design keeps the boundary explicit.

The test that makes this concrete is to change one layer and watch what should not move. Swap the gateway serving the model, and which actions require approval should stay exactly as it was. Swap the framework you compose subagents with, and the agent should not gain a single new tool. If either of those shifts, authority was sitting in the wrong place, and you will find out during an incident rather than during a review.

This is also why a feature checklist is a poor way to judge a harness. What matters is where authority, state, enforcement and recovery sit in the overall flow. The two mistakes that follow from ignoring it are credit and blame in the wrong direction: giving the model credit for guarantees the sandbox provides, and assuming the limits of one runtime cover a whole session that involves more than one agent.

Control travels above the agents themselves

Once you accept that the harness decides, the question becomes how far up the deciding goes. Teams now open a session where a coding agent from one vendor works next to a reviewer from another. A layer above both starts them, keeps messages, files and terminals in sync, picks a disposable sandbox for the session, and applies policy per server, per agent or per chat: which tools are reachable, which risky actions need a human, how much a session may spend before it stops. The agents stay replaceable behind that interface, and the policy does not move when they do. A cost cap applied afterwards is an accounting record, not control.

The same instinct helps when choosing parts. Sort projects by the function they own, runtime or sandbox or protocol or tool interface or memory or evaluation, and pick pieces whose responsibilities fit together, instead of picking the repository with the most stars. The composition is the architecture, and it is yours, the way the loop is yours. The model proposes. The harness decides what happens next.