Topic 5

The model and the harness

An agent is two pieces of software with different jobs. The model makes judgment calls. The harness, the code around the model, does everything else: defines the tools, runs them, handles failures, manages the context, enforces limits, and records what happened.

Predict first

Your agent sometimes calls `refund` with an amount larger than the charge. Where's the most reliable fix?

A check in the harness: reject any refund call whose amount exceeds the charge, before it runsA sentence in the prompt: “never refund more than the charge”A bigger modelMore examples

Model versus harnessStep 1 / 2

Scroll sideways to see the whole diagram

The model makes the judgment calls, one step at a time, from what's in its context.

Text version

The model makes the judgment calls, one step at a time, from what's in its context.
Everything else is ordinary software around it: the harness. This module is mostly about that column, because it's where reliability comes from.

Anthropic's "Building effective agents" (2024) gives three principles for agents: keep the design simple, make the agent's planning steps visible, and carefully design the agent-computer interface: the tools, their documentation, and how they're tested. All three are harness work.

That's what “harness engineering” means in this module's title. Models improve from release to release; the harness is the part you control, and most failures in this module (wrong arguments, retried writes, a context that drops the goal, a loop that never ends) are fixed there.

Quick check

Which of these belongs in the harness rather than in the model's instructions?

“Be polite to customers”“Think before you act”“Use the policy tool when unsure”A limit of 20 steps per task, enforced by stopping the loop