The harness: where the real work is

If the model is the easy part, the harness is where you actually spend your time. The harness is everything around the model that turns a clever text generator into something you'd let touch production. It has six jobs. Learn them as a checklist.

1. The loop. Something has to call the model, take its chosen action, run it, feed the result back, and decide whether to go again. This is the engine. The important design question is: when does it stop? A loop with no stopping condition will happily burn your budget retrying a task it can't do. Set a max number of steps and a clear success signal.

2. Context and memory. The model only knows what's in its context window right now. The harness decides what goes in: the task, relevant files, prior steps, retrieved documents. Too little and it flails; too much and it loses the thread and costs more. Memory is just deciding what to carry forward between steps, and it is a design choice you own — not something the model handles for you.

3. The sandbox. Give the agent a bounded place to act — a scratch directory, a test database, a container. If something goes wrong, you want the blast radius to be the sandbox, not your real data.

4. Tool access. Tools are how the agent affects the world, and each one is a door you're opening. An MCP gateway is a clean way to expose tools behind one controlled interface, so you can see and limit exactly what's reachable. Fewer, well-chosen tools beat a sprawling pile — we'll see why in Lesson 5.

5. Guardrails. This is where the golden rule becomes concrete:

• Read-only by default. The agent can look at anything; it writes nothing without a reason and a check.
• Spend caps. Limit tokens, API calls, and dollars per run. Loops fail in expensive ways.
• Human approval for anything risky. Deletes, sends, payments, deploys, config changes — the agent proposes, a human approves. Always.

6. Verification. The model can't judge its own work, so something external must. Run the tests. Run the linter. Diff the output against expectations. For fuzzy tasks, a second agent can review the first one's output against a rubric. If nothing checks the work, you don't have an agent — you have a confident guess with a side effect.

A plain-words picture of a safe step:

model proposes action
   -> is it read-only?  yes -> run it
                        no  -> hold -> ask human -> run only if approved
   -> verify result -> loop or stop

Notice how little of this is the model. The model proposes; the harness disposes. That asymmetry is the entire discipline.