A simple readiness checklist before you let an AI agent touch production
If you’re letting an AI agent touch production, a green unit test is not enough.
The failure mode is rarely “the model was dumb” - it’s usually missing guardrails around scope, rollback, credentials, or observability. Here’s the lightweight checklist I’d want before any agent can run outside a sandbox:
1) Make the blast radius obvious
What files, APIs, repos, or environments can it touch? What is strictly read-only? What is the one command or path that would hurt the most if it went wrong?
2) Require a human-readable plan first
Before execution, force the agent to say:
- what it thinks the problem is
- what it plans to change
- what it will not change
- how it will verify success
- how to undo the change
If a human cannot read the plan in 30 seconds, the task is still too vague.
3) Separate “inspect” from “write”
A lot of teams mix safe diagnosis with risky execution. Keep them split:
- inspect / search / diff / dry-run
- then explicit approval
- then write / deploy / publish
That one boundary removes a surprising amount of risk.
4) Add a rollback sentence, not just a rollback script
You want both:
- the command to revert
- the plain-language condition for when to revert
Example: “If checkout latency rises or 5xx errors spike after deploy, revert immediately.”
5) Log the exact action, not just the result
For every production-touching run, capture:
- prompt or task summary
- changed files / commands
- approver
- timestamps
- verification output
- follow-up owner
Without that trail, postmortems become guesswork.
6) Don’t let analytics gaps masquerade as success
“Nothing broke” is not the same as “it worked.” If you cannot observe the key event, you cannot close the loop. At minimum, define one thing you expect to move after the change.
7) Start with a manual service before a full product
One thing I keep seeing: teams want a full “agent governance platform” before they’ve done five manual audits. Usually the faster move is:
- run the checklist manually
- find repeat failures
- turn only the repeated parts into product
That gives you better language, clearer scope, and fewer fake features.
I’m experimenting with a small Agent Readiness / Governance Audit workflow around exactly this problem. Not a full platform claim - more a practical preflight for teams that want to catch the obvious mistakes before an agent touches production.
Curious where your own process still feels weakest today: approvals, rollback, credentials, observability, task scoping.
Comments
No comments yet. Start the discussion.