Skip to main content
You can write the harness for one job as one file: who does each step, who reviews it, where the work goes back, and where a person decides. The engines are the ones you already run. The runtime keeps the order, the record, and the returns. A domain-specific harness is the loop, the tools and the rules that make a model useful in one field: insurance intake, a company’s own integrations, a research desk. The model is the same one everyone has. The harness is the part that is yours. Most of it is process: what runs first, what checks it, what happens when the check fails, and who signs at the end.

What the file holds

The file is examples/teams/feature-delivery.ts.
The roles name the engines. The stages name the work and the files each stage may write. A review role reads a stage’s work and sends it back with findings when it is not right. A person role asks a question and waits for the answer. The run writes every step to a record as it happens.

What is yours and what is the runtime’s

Things that catch people out

  • A harness is not an agent. Claude Code, Codex and the others are the agents. This file drives them. See harnesses we drive.
  • A reviewer from another family catches more. A review by the model that wrote the work agrees with it more often. Give the review role a seat from a different provider.
  • The person’s answer is not in the file. The run pauses at the person role and carries on when the answer arrives through the callbacks client. See a person decides.

Where to go

A feature team, as a file for the same shape with its recorded run; software factory, as a workflow if you arrived from that search.