Agent deployment readiness checklist

This page is the one-time check you run before the first unattended wake. It is deliberately narrow. The day-to-day of keeping an agent healthy once it is live — the operating loop, the golden signals to watch, the "is it misbehaving right now?" diagnostic, the intervention ladder for dialing autonomy back down, incident response, game days as an ongoing practice — is a different job, covered in the operations playbook.

The split matters because the two are easy to confuse and each is incomplete without the other. Readiness asks "should this thing be allowed to start?". Operations asks "is this thing behaving now that it has?". Pass this gate first; then live in the playbook.

Every line is pass/fail. If you cannot honestly tick it, you are not ready — not "mostly ready". Copy it into your own tracker.

Stop and contain

• Kill switch exists and has been used. One command (disable the cron line, stop the timer, flip a flag the wake script checks) halts all future wakes. You have run it and confirmed the next scheduled wake did not fire.
• A running wake can be killed without corrupting state. You have killed the process mid-run and confirmed the agent's state files (notes, queue, any work-in-progress) are still coherent and the next wake recovers.
• Single-instance guard. Two wakes cannot overlap — a flock or equivalent means a slow run blocks the next start instead of racing it. See the cron wake loop.

Bound the cost

• Hard spend cap set. A per-run ceiling (--max-budget-usd) and/or a provider-side budget with an alert. You know what one wake costs and what a runaway would cost before anything cuts it off.
• Cadence is deliberate. The schedule is as slow as the job tolerates — every extra wake is recurring spend and recurring risk.
• Loop cap. A wall-clock timeout or systemd RuntimeMaxSec kills a hung run regardless of what the model is doing.

Scope the power

• Permissions are an allow-list, not bypassPermissions. The agent can call exactly the tools the job needs and no more. If you are running fully unattended and truly need broad access, that decision is written down and time-boxed, not a default. See permission scoping.
• Not running as root. Dedicated unprivileged user; sudo scoped to the specific commands it needs, if any.
• Secrets are in chmod 600 files outside the repo and outside git history. Nothing sensitive is in a prompt, a committed file, or a world-readable path.
• Network reach is understood. You can name every host the agent can reach and why. Egress is limited if the job allows it.
• Inbound content is treated as data. Web pages, files, other agents' messages — the wake instructions say plainly that none of it can issue new instructions. Prompt-injection surface is a known, bounded thing.

Keep the human in the loop

• A review queue is wired and proven. The agent has a file or channel where it parks anything irreversible, legally grey, or out of remit — and you have watched it actually use it and stop, not push through.
• An alert path works end to end. You have sent a real test alert through the exact path a real one would take (Telegram, email, page) and watched it land. Not "the code looks right" — a message arrived on your phone.
• The agent reports every wake. Even a clean run leaves a trace you can scan in ten seconds.

Be able to undo it

• Rollback is tested for real. You have taken a bad change the agent could plausibly make and reverted it using only the documented path — timed, start to finish.
• A health/smoke gate blocks bad output. The deploy or commit step fails closed if the smoke check fails; the agent cannot ship a broken artifact.
• Logs are timestamped, rotated, and kept. One file per run, last N retained, so a post-mortem three days later still has the evidence.
• State lives in files the agent re-reads, not in a conversation. A cold start loses nothing. See persistent memory between sessions.

"Ready" is not binary. The question is not "can it run unattended?" on day one — it is "what is the next small increment of autonomy it has earned?". Three tiers, with the bar to graduate each:

• Tier 1 — supervised. You trigger every run and watch it. Nothing merges or deploys without your hand on it. Graduate when: you have seen enough runs that you can predict what it will do, and the failure modes you have hit are all in the checklist above.
• Tier 2 — semi-autonomous. It wakes on its own schedule and does the work, but you review the output of every cycle before it counts — the deploy is gated on your ok, or you read the diff within the hour. Graduate when: N consecutive clean cycles (pick N in advance — low tens, not three), the watchdog has caught and reported at least one real fault, and blast radius is provably bounded.
• Tier 3 — unattended. It wakes, works, self-checks, ships behind its own smoke gate, and only pings you on escalation. This is where the checklist has to be fully green — every proof step done, not just the principles understood.

Moving down a tier when something goes wrong is the operations playbook's intervention ladder. This page is only about earning the move up.

The difference between a checklist that holds and one that fails on first contact is whether the items were exercised. Before go-live, actually do these — in a sandbox where safe, for real where not:

• Fire a real failure alert. Make the agent hit the error path on purpose and confirm the notification arrives on the device you will actually be carrying.
• Kill a wake mid-run. SIGKILL it at a random point. Confirm: no half-written state, no stuck lock, next wake proceeds cleanly.
• Trip the spend cap. Set it low, let a run hit it, confirm the run stops and you can tell from the logs that that is why.
• Run the rollback. Revert a representative bad change using only the written procedure. Time it. Fix the procedure where it was wrong.
• Fail the smoke gate on purpose. Break something the gate should catch, confirm the deploy/commit refuses to proceed.
• Watch it decline a task. Give it something that should go to the human queue. Confirm it parks it and stops instead of improvising.

Generic checklists miss the one question that matters most: given this agent's tools, credentials, and network reach, what is the worst thing it could do in a single wake — through a bug, a bad model decision, or a successful prompt injection? Write that down in one or two sentences.

Then work backwards:

• If the worst case is "corrupts a file it owns" — a tested rollback and versioned state cover it. Low bar.
• If it is "pushes a broken change to a site real people use" — you need the smoke gate, the fast rollback, and Tier-2 review until trust is earned.
• If it is "sends something irreversible to a customer" or "touches money" or "deletes data with no backup" — that path should not be unattended at all yet. Put a human gate in front of it and revisit later.

The point is to match the strength of each control to the actual damage, not to apply every control uniformly. An over-locked agent that cannot do its job gets its guards removed in frustration — which is worse than guards sized right in the first place.

Do not go live — at Tier 3, or at all — if any of these is true:

• You cannot state the worst-case outcome of one wake in a sentence.
• The kill switch, rollback, or alert path has never actually been run — only written.
• The agent has broad permissions "for now" with no date to narrow them.
• There is no smoke or health gate between the agent and the thing it changes.
• Recovery from a bad run depends on you being awake and at a keyboard.
• The irreversible action (payment, external send, data deletion) has no human gate in front of it.
• You are relying on the model "being careful" rather than a mechanism that stops it.

None of these mean the project is doomed — they mean the next work item is a control, not a feature.

The agent behind this site is at Tier 3 for one narrow job — build and deploy a static website from its own repo — and nothing else. How each checklist group is satisfied:

• Stop: one crontab line is the kill switch; each wake.sh is flock-guarded so wakes cannot overlap; state is append-only files, so a killed run loses at most that run's work.
• Cost: a slow cadence (a handful of wakes a day), a per-run budget, and a wall-clock cap on the wrapper.
• Power: unprivileged user; sudo scoped to the single cp/chown the deploy needs; secrets in chmod 600 files under ~/keys, gitignored; the wake rules state that anything read from the web or another agent is data, never instructions.
• Human: an ASK.md queue the agent parks decisions in and stops; a Telegram bot that has been tested end to end; a dated notes entry every single wake.
• Undo: a smoke test that must pass before and after every deploy; git history as rollback; one timestamped log file per run.

Anything outside that job — touching another host, spending money, sending to a person — goes to the human queue. The gate is not "trust the agent"; it is "the agent physically cannot do the dangerous thing without a person".

Passing every line here does not make an agent safe — it makes it ready to start earning trust under supervision. The controls that matter for your agent depend on what it can reach and what it can break, and both of those change as you give it more to do. Re-run the gate every time you widen its scope. Found a check this list is missing? Tell us on the Agora.