The AI harness

A current agent is a loop: the model looks at a goal, chooses a tool, reads the result, and chooses again until it stops. Left unbounded, that loop is a liability. The harness is the set of limits designed around the loop. Tools are few and named in the person’s language. Each tool has an input the interface can show. A step budget ends the run. A permission list says what may be read. A review gate sits in front of anything that sends, deletes, pays, files, or publishes.

This is interface work, not only infrastructure. While a tool runs, the screen shows the tool’s name and the fact it is in progress. When it returns, the screen shows the result the model will use next. A person can stop the loop without guessing which request is in flight. A harness that only exists in logs is an operations feature. A harness a person can see is a design.

Every tool is a door. Search, read a file, query a record, draft a message, create a task: each door needs a label, a scope, and a failure. Designers who treat tools as an implementation detail ship a product whose behavior changes whenever a new function is registered. The tool list is the map of what the product can do, and it belongs in the same review as the navigation.

Harvey’s category, legal tech, is a clear case. The useful tools are the ones a practice already has: the matter, the document, the history of the work. A general web search inside a filing tool is a different product and usually the wrong one. Perplexity’s tools are retrieval and citation. Claude’s strongest tool, in the 2025 class, is the document in front of the person. The harness should make that specialty obvious, so the empty state can say what will actually happen.

A practical split keeps harness design honest. Reading, summarizing, and drafting can proceed and then be shown. Writing to another system waits. The wait is a screen: here is the exact change, here is where it will land, here is the control that applies it. Batch approval is allowed when every item is visible. Silent approval is how a harness becomes a script the person did not write.

Irreversible actions get a plainer treatment than reversible ones. Sending a message, moving money, and submitting a form do not share a button style with “try a different phrasing.” The visual weight should match the consequence. Undo, when it exists, is described in the confirmation, including the cases where undo is impossible.

A harnessed run produces a record: the goal, the tools called, the results used, and the draft that came out. That record is how a person audits a decision later, and how a team debugs a bad run without replaying it from memory. Design the record as a document, with headings and timestamps, and keep it attached to the object it changed.

Failure is part of the record. A tool that times out, a permission that was missing, a step budget that ended the loop: each of these is a state with a sentence and a next action. Retry is specific. “Try again” on the whole mystery is how people lose the thread. “Search again without that filter” is a harness that respects the person who has to finish the job.