Harness

A harness is the code around a model that turns a single response into work. It supplies the context, exposes the tools, parses what comes back, executes what is permitted, feeds the result in, and decides whether to go around again.

Why it is where the engineering lives

The model is bought or adapted; the harness is built. Two systems using an identical model behave completely differently depending on their harness, and most observed failures in agentic systems are harness failures rather than model failures — a tool result that was never checked, a loop with no turn limit, an error swallowed and retried until the budget was gone.

What a harness decides

Which tools are visible on this call and which are not. What a tool result must look like before it is accepted. How many turns before the run stops. What happens on a malformed response, a timeout, or a refusal. When to escalate to a person, and what that person receives. Whether an action is permitted at all, checked against policy that lives outside the model.

Retry and failure

Retry is a design decision, not a default. A retry after a transient network error is sensible. A retry after a model produced an invalid action is usually a signal to stop and escalate — repeating the call rarely improves the outcome and consumes budget while the failure persists.

What stays outside it

Identity, permissions, approval thresholds, and stop conditions are configuration the harness enforces, not behavior it infers. That separation is what makes an authority boundary reviewable.