25. Quick-Reference Checklists

Every chapter of this guide has ended with a checklist. This chapter pulls those checklists into a single place, reorganized by the phase of the agent’s life where each item actually gets used, and links each item back to the chapter where the full reasoning lives.

The checklists are designed to be used, not admired. If you print one, it should fit on a page. If you paste one into a pull-request template, it should be short enough that reviewers actually read it. If you hand one to a new engineer on day one, they should be able to tell, within a week, which items their current project has and which it doesn’t.

The point of a checklist is not to prove that the system is safe. It is to prevent the specific class of mistakes that teams under pressure consistently make — the forgetting, the skipping, the “we’ll add that later” — which compound into the anti-patterns in Chapter 22. A checklist turns a habit that requires discipline into one that requires only honesty.

How to Use These Checklists

Four rules get the most value out of them:

Use the right checklist for the phase. The “before production” checklist is not the same as the “during development” one. Running the wrong checklist at the wrong time produces false confidence in one direction and false anxiety in the other.
Read each item honestly. An unchecked box is information. A box checked because it was almost true, or because someone had a meeting about it once, is not.
If an item is checked, you should be able to name the evidence. Not the aspiration, not the plan, not the ticket — the artifact in the repository or the run in the log that proves the item is done. “Where is the test?” “Where is the kill-switch code?” “Where is the scope brief?”
If an item does not apply, write that down. A deliberate N/A with a one-line reason is fine and common. A silent skip looks identical to a forgotten item and should be treated as one.

The four lists below are cumulative. Items from earlier phases do not stop applying just because the phase has moved on — they become ongoing obligations. The “ongoing operations” list is the smallest because it assumes the first three have been done and are still true.

Before Building

You are still in design. No code has been written. The worst mistakes you can make right now are mistakes of shape — choosing the wrong architecture, skipping the scope brief, signing up to build a system that should not exist. These items are cheap to do now and expensive to fix later.

If more than two of these items are not done, you are not in the “before building” phase — you are in the “design” phase that comes before it. Go back.

During Development

You are writing code. Tools are being implemented. The system prompt is evolving. The first tests are being written. The worst mistakes you can make now are mistakes of foundation — skipping observability, deferring safety controls, letting the test environment drift from the real one.

A good rule: if observability is not already in place when the first tool is wired up, pause and add it. Every hour of development against a blind agent is an hour of work you will repeat later when you cannot figure out what went wrong.

Before Production

The agent works in the sandbox. Tests pass. Someone is about to propose shipping. This is the most dangerous moment in the agent’s life, because the gap between “works in the sandbox” and “works in production” is exactly the gap that produces the worst incidents. These items are the graduation gate — if any of them is unchecked, the agent is not ready.

The rule for this list is stricter than the others: no exceptions without a named decision-log entry. An unchecked item at this gate is a decision. Write it down. If it is unwritten, it is not a decision, it is an oversight, and the graduation is not yet earned.

Ongoing Operations

The agent is in production. People are using it. New versions are shipping. The worst mistakes you can make now are mistakes of drift — losing track of what the agent does, ignoring the monitoring, letting the documents rot, skipping the regression work. These are the cheapest items on this page and the ones most often forgotten.

The ongoing list is the one that decays fastest. Teams usually start it with enthusiasm and slowly lose items to the friction of production work. The defense is to treat ongoing items as scheduled rituals — on the team calendar, assigned to owners, with a visible history — rather than as a cultural aspiration. A checklist that lives in someone’s head has no way to catch its own decay.

The Single-Page Summary

When all four checklists above are too much, print this. It is not a substitute for the full lists; it is the minimum floor. A team whose answer to any of these eight questions is “no” should not be running an agent in production.

THE AGENT GRADUATION TEST — SINGLE-PAGE VERSION

1. Can you describe, in one paragraph, what the agent will never do?
   → Scope brief with an out-of-scope list. (Ch 4)

2. Is every critical invariant enforced in code, not just in the prompt?
   → Tool-layer and infrastructure-layer enforcement. (Ch 2, 12)

3. Can you replay any single run from the trace logs?
   → Observability from day one. (Ch 10)

4. Does the agent escalate instead of guessing when uncertain?
   → Explicit escalation paths with typed reasons. (Ch 11)

5. Is there a kill switch, and has someone used it in the last quarter?
   → Hard-stop and graceful-stop mechanisms. (Ch 13)

6. Have adversarial and prompt-injection tests run against it recently?
   → Red-team and chaos test suites. (Ch 15, 16)

7. Does an honest known-limitations list exist, and is it tied to evals?
   → Limitations that pass the stranger, support, and eval tests. (Ch 24)

8. Was a checkpoint written in the last month?
   → The discipline that catches drift. (Ch 21)

If any answer is "no," the agent is not ready.

Eight questions. The full lists above are how you earn each “yes”; this is the question form you carry in your head.

Anti-Pattern: Check-Box Compliance

Symptom: The team runs through the checklist the day before launch and marks items complete based on a loose interpretation — the eval suite “kind of exists” (a dozen test cases in a notebook), the kill switch “is in the plan” (ticket filed), the behavior spec “is in the README” (two paragraphs). Every box is checked. The agent ships. Two weeks later, an incident reveals that none of the boxes were honestly checked.

Why it hurts: A dishonest checklist is a dishonest artifact, and dishonest artifacts are worse than no artifact at all because they create the appearance of readiness without the substance. The team feels more confident than they should, the reviewers rely on the checklist as evidence of due diligence, and the incident that follows produces the most painful class of post-mortem: one that ends with “we knew we were supposed to do this and we said we had.”

Fix: For every checked item, name the evidence. A specific file path, a specific test name, a specific commit hash, a specific document URL. “Where is it?” is a reviewer’s question, and the answer should be one click, not three sentences of explanation. If an item cannot produce its evidence in under thirty seconds, it is not checked. Build the habit early — during the “during development” phase — so that “before production” is not the first time anyone is asked to produce receipts. The goal is not to fail teams at the gate; it is to make honest passes cheap enough that dishonest ones stop being tempting.