Ship your first three systems

A system, in this book, has three parts. A task with a clear start and end. A rule that says what a good result looks like. A person who reviews the result before it goes anywhere that matters.

Skip the third part and you have a risk. Skip the first two and you have a demo.

The build loop

1. 1Point the system at one brain fileGive it company.md, rules.md and the process file for this task. Nothing else. More context is not better context.
2. 2Run it on last week's real workTake ten real inputs your team already handled. Do not invent examples. Invented examples are easy, and real ones are not.
3. 3Compare, line by linePut the system output next to what your team produced. Mark each difference as system wrong, human wrong, or rule unclear.
4. 4Fix the brain, not the promptFor each "system wrong", ask what the brain was missing. Add it to the file. Run all ten again.
5. 5Turn on reviewWhen the reviewer trusts four of five outputs and checks one in under five minutes, switch it on for live work with the reviewer in the loop.

Expect it to be wrong the first time. That is the loop working. The brain gets better with every correction, and the next system benefits from all of them.

Three shapes that work first

Pick one shape from your hour-leak sheet. Small, useful and boring is the right target.

• An answerer. A support agent that replies from your documents and flags what it cannot answer.
• A preparer. A research step that drafts the briefing before a sales call.
• A filler. A reporting step that pulls numbers and writes the weekly update.

Write the review rule down

Reviewing sounds obvious until it is skipped on a busy Friday. Put it in the rules file so the system and the reviewer both know the contract.

# Rules

## Support first reply
- The system drafts. A person sends.
- Reviewer: support lead, twice a day, 10:00 and 15:00.
- If the system is unsure, it writes "NEEDS HUMAN" and
  the reason. It never fills the gap with a guess.
- Refunds, legal threats and press: always a person.

When a system keeps failing

If the same case fails after three fixes, the task is probably not rule-based. Go back to the hour-leak sheet and check the "can I write the rule" column. Swap it for the next task on your list. No shame in that. A killed system is cheaper than a distrusted one.