7.3 Before you touch a tool
The ten ways assume a few things already exist, and in my experience the first week fails on Tuesday far more often than on Friday — not because the model was weak but because there was nowhere for its work to land, no credential narrow enough to hand it, and nobody named to read what came back. Each of those is a half-hour of setup if you know to ask for it and a lost week if you discover it mid-run. So before the first run, check that these eight things exist, each with a person’s name next to it.
| What has to exist | What it decides | Where the book covers it |
|---|---|---|
| One named process and a one-sentence outcome | What done means, so the system cannot optimize for looking finished | Section 13.5, Day 1 |
| A place the system may write that customers do not read from — a branch, a drafts folder, a spreadsheet | The blast radius of a wrong run | Chapter 14’s isolation control |
| A credential scoped to that place and to the read sources, with an expiry date | What a confused or compromised run can reach | Chapter 14’s credential control |
A guidance file — AGENTS.md, a SKILL.md, or a one-page equivalent — with the exclusions written in |
What every run is told; it enforces nothing | Chapter 6’s instruction tree |
| An approval point that exists outside the model — a protected branch, a send button only a person holds | Which actions return to a person before they take effect | Chapter 10’s approval map |
A place the evidence lands — a folder, an evaluation sheet, a trace_id |
Whether the week can be reconstructed by somebody else | Chapters 8 and 16 |
| A budget line with an owner — a per-key cap, a prepaid balance, a number on a sticky note | When the system stops for money rather than for error | Chapter 15’s budget as a permission |
| A person who is not you, named now, who will receive the handoff | Whether you are building an orchestration or a habit | Section 13.5, Days 6–7 |
What the list decides is narrow. It does not tell you whether the process is worth delegating — Chapter 15’s triage does that, and a task done once a month fails it at almost any price. It does not tell you whether the model is good enough; you find that out on Wednesday, with evidence. And it does not make the first run safe by itself, because a checklist is text. What it does is convert the week’s likely failures from surprises into scheduled work.
Two rows deserve a note for the reader who does not run the infrastructure. The scoped credential and the approval point are the two things you will have to ask somebody else for, and both have names your IT department already knows — a read-only scope, a shared folder with write access for one account, a branch that requires review. Ask for them by name on Monday. If you cannot get a scoped credential by Wednesday, that is the finding of the week, and it belongs in the register under what stops the work. Do not substitute your own login. The most common way a first week becomes an incident is a personal credential, with everything that person can reach, handed to a system that was supposed to read one mailbox.