Harness Engineering Consolidates Into a Named Third Phase

Harness engineering has consolidated into a named third phase of agent design, after prompt engineering and context engineering, per Martin Fowler.

The shift matters because it turns a vague goal, "make the agent reliable," into five checkable layers. Those layers are tool orchestration, verification loops, context and memory, guardrails, and observability, per Fowler's write-up.

The term didn't stay Fowler's alone. He traces the same five-layer idea through Addy Osmani's writing and into LangChain's shorthand, Agent = Model + Harness, with an arXiv study behind it too.

The operating principle behind the label traces to Mitchell Hashimoto, who put it this way: "anytime you find an agent makes a mistake, you take the time to engineer a solution so that the agent never makes that mistake again."

One design rule falls out of that directly: never let the model call a tool. Instead the model returns a structured tool call. The harness checks it against a schema, checks permissions, runs it, and feeds the result back.

For builders, that's the checklist. Put a schema between the model and every tool call, check permissions first, then log each step. Skip any of those and you haven't done harness engineering, whatever you call your agent loop.