13.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. Asking for those things in advance can save the week. Before the first run, check that these eight things exist, each with a person’s name next to it.
1. A named process and outcome
Requires: One named process and a one-sentence outcome.
Decides: What done means, so the system cannot optimize for looking finished.
Read next: Section 13.5, Day 1.
2. A safe place to write
Requires: A place the system may write that customers do not read from — a branch, a drafts folder, a spreadsheet.
Decides: The blast radius of a wrong run.
Read next: Chapter 14, the isolation control.
3. A scoped credential
Requires: A credential scoped to that place and to the read sources, with an expiry date.
Decides: What a confused or compromised run can reach.
Read next: Chapter 14, the credential control.
4. Written guidance and exclusions
Requires: A guidance file — AGENTS.md, a SKILL.md, or a one-page equivalent — with the exclusions written in.
Decides: What every run is told; it enforces nothing.
Read next: Chapter 6, the instruction tree.
5. An approval point outside the model
Requires: An approval point that exists outside the model — a protected branch, a send button only a person holds.
Decides: Which actions return to a person before they take effect.
Read next: Chapter 10, the approval map.
6. A place for the evidence
Requires: A place the evidence lands — a folder, an evaluation sheet, a trace_id.
Decides: Whether the week can be reconstructed by somebody else.
Read next: Chapters 8 and 16.
7. A budget with an owner
Requires: A budget line with an owner — a per-key cap, a prepaid balance, or a review limit with a person responsible for stopping the run.
Decides: When the system stops for money rather than for error.
Read next: Chapter 15, the budget as a permission.
8. Someone to receive the handoff
Requires: A person who is not you, named now, who will receive the handoff.
Decides: Whether you are building an orchestration or a habit.
Read next: Section 13.5, Days 6–7.
What the list decides is narrow. It does not tell you whether the process is worth delegating; that is the triage in Chapter 15, and a twenty-minute task done once a month may not repay the setup and review effort. It does not tell you whether the model is good enough; you find that out on Wednesday, with evidence. What it does is convert the week’s likely failures from surprises into scheduled work.
If you do 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. One 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.