Skip to main content
You can answer this with a file. A domain-specific harness is the loop, the tools and the rules that make a general model useful for one job: insurance intake, a research desk, a company’s own integrations. The model is the same one everyone has. The harness is the part that is yours, and most of it is process: what runs first, what checks it, what happens when the check fails, and who signs at the end. The file below is examples/teams/feature-delivery.ts. The phrase comes from the observation that products built on a model end up owning the process around it rather than the model. What that process looks like in code is a workflow:

The three parts, and where each lives

Things that catch people out

  • It is not an agent. Claude Code, Codex and the others are the agents, each with its own inner loop. The harness for a job drives them. See what is an agent harness.
  • The person is part of the harness. A job that ends in a human decision writes that decision in as a role, so the run pauses there; the answer arrives through the callbacks client.
  • The record is the audit. Every step is written as it happens, so the run can be read back later. See how a run is recorded.

Where to go

Domain-specific harnesses for the use case in full; a feature team, as a file for a recorded run.