The model does not decide what it is allowed to do. The harness does.
An agent harness is the engineered layer around the model. It constructs the context, governs tool interaction, manages state, orchestrates execution, interprets feedback, verifies outcomes and enforces constraints. The model proposes a plan, writes the code, picks the tool, reads the result — but it does not decide which context it receives, which tools it may call, whether a proposed step executes, what state survives the next turn, how an output is checked, when a failure should be retried, or when control passes to another agent or a person. Those decisions belong to the system around the model, and that system is the harness. This matters because the model supplies general-purpose intelligence at inference time and the harness is what turns that inference into situated, persistent, controlled and interpretable behaviour. It matters more because the harness is a learnable layer in its own right: it can be measured, changed and improved while the underlying model stays exactly where it is, which is where most of the available reliability actually lives. Six layers do the work — identity and behaviour, runtime, observability, verification, adaptation, and governance and security — and they close into a single operational loop rather than stacking into a pipeline. This guide takes each of them apart: the control surface of seven decisions, the instruction layer as versioned code, the execution loop, planning and decomposition, context construction, the model layer and the six decisions surrounding a component you cannot change, tool mediation, state and persistence, execution environments, orchestration and control transfer, approval and human-in-the-loop design, the trace and replay, failure interpretation and recovery, the four verification gates, constraint enforcement, budgets and the economics of the loop, the adaptation loop, how to test the machinery rather than the model, governance and security, the patterns and anti-patterns that recur, and the operating model that holds it together. Five lenses per concept: what it requires, how to architect it for a bank, a flow diagram, a plain-English reading, and what it hands off next.