A checklist earns its place only if every item would actually stop you from shipping something broken. The list below is built that way. Each entry pairs a concrete gate with the reason it exists, drawn from the failure modes that sink early agent projects: vague scope, over-broad permissions, missing oversight, and no way to back out.
Use this before an agent touches anything irreversible. Run it as a literal gate, not a vibe check. If an item is unchecked, you are not blocked from learning, but you are blocked from production. The discipline of refusing to ship past an open item is most of the value.
The sections move roughly in the order you should think about them: define the job, give it the right tools, fence its access, watch it run, and keep an exit. Skipping ahead is how teams end up with an impressive agent and an embarrassing incident.
Define the Job Before Anything Else
Most agent failures trace back to a task that was never properly bounded.
Scope and success
- The task has a one-sentence definition. If you cannot state the job plainly, the agent cannot either, and neither can your reviewers.
- Success and failure are checkable. You can look at any output and say correct or wrong without a meeting.
- The cost of a wrong output is known. You have written down what one bad result costs, because that number sets every guardrail that follows.
A task that survives these three lines is a candidate. One that does not belongs back on the drawing board, as our Getting Started with AI Agents walkthrough explains in more depth.
Give It Exactly the Tools It Needs
An agent is only as safe as the actions you let it take.
Tool surface
- Each tool maps to a step the task actually requires. Spare tools are spare ways to fail.
- Every tool's inputs are validated before execution. The agent will eventually pass something malformed; catch it at the boundary.
- Destructive actions require confirmation. Anything that deletes, sends, or charges sits behind an explicit gate.
Keeping the tool surface minimal is the single cheapest way to keep an agent legible, a theme our Framework for AI Agents returns to repeatedly.
Fence the Permissions
Agents inherit the access you give them and ask no questions about it.
Least privilege
- The agent runs with the narrowest credentials that work. Not a shared admin account, not a broad service token.
- Data access is filtered at the source, not in the prompt. Row- and column-level controls live in the database, where the agent cannot talk its way around them.
- Secrets are never in the prompt or logs. Credentials flow through the runtime, not the context window.
Permission gaps are the quietest agent failures and the most expensive when they surface.
Watch It Run
An agent you cannot observe is an agent you cannot trust.
Observability
- Every tool call is logged with inputs and outputs. When something goes wrong, you need the trace, not a guess.
- A human reviews output until the correction rate is low. Trust is earned with logged evidence, not granted on day one.
- Chain length is capped. Long loops compound small errors; a hard limit forces the agent to stop and ask.
- Cost and latency are monitored. A runaway loop should trip an alarm before it trips your budget.
Keep an Exit
The teams that ship agents calmly are the ones that planned to turn them off.
Rollback and containment
- There is a kill switch. One action disables the agent without a deploy.
- You can revert any agent-made change. Reconcilable actions only; nothing the agent does should be one-way without human sign-off.
- An incident owner is named. When the agent misbehaves at 2 a.m., someone specific responds.
Before You Flip the Switch
A final pass ties the gates together.
The go decision
- Shadow mode ran clean. The agent operated alongside humans without anyone depending on it, and the results held up.
- Stakeholders know the blast radius. Everyone affected understands what the agent can and cannot do.
- Metrics for ongoing health are live. You decided how you will measure it before launch, not after the first complaint, as covered in How to Measure AI Agents.
Keep the Checklist Alive After Launch
The list does not retire when the agent ships; it becomes a recurring review.
Ongoing checks
- Re-run the permission audit on a schedule. Access creeps. A service account that was least-privilege at launch can accumulate scope as someone grants it a convenient extra permission. Re-verify quarterly.
- Revisit the scope when the task drifts. The job an agent does in month six is rarely identical to month one. When inputs or expectations change, the one-sentence definition and the success criteria deserve a fresh look.
- Confirm the kill switch still works. A disable mechanism that was never tested after a deploy is a disable mechanism you do not actually have. Exercise it periodically so you know it works when it matters.
- Recheck cost and chain-length baselines. Drift here is slow and easy to miss. What looked healthy at launch can creep into a budget problem over months without any single alarming day.
Why the recurring pass matters
Most agent incidents do not happen on launch day, when attention is highest. They happen weeks or months later, after access has crept, scope has drifted, and nobody has looked closely in a while. A checklist that runs once protects the moment you cared most; a checklist that recurs protects the moments you forgot to. Pairing this recurring pass with the monitoring in our Framework for AI Agents guardrail layer is what keeps an agent trustworthy past its first week.
Adapting the Checklist to Your Blast Radius
One list does not fit every agent, and pretending it does wastes effort or invites risk.
Scaling the gates
- Sandboxed experiments can run with the scope and observability items satisfied and lighter rollback, since nothing real is at stake.
- Internal, reversible tasks add the permission and oversight items in full, because the agent now touches real systems even if mistakes are recoverable.
- External or irreversible tasks require every item, with particular weight on approval gates, rollback, and a named incident owner, because a mistake reaches a customer or cannot be undone.
The skill is matching the rigor to the stakes. Over-applying the full list to a sandbox slows learning; under-applying it to a customer-facing agent invites the incident the checklist exists to prevent. Use the blast-radius framing from our AI Agents Trade-offs, Options, and How to Decide breakdown to calibrate.
A common calibration mistake
The error teams make most often is calibrating to the agent's intended use rather than its possible use. An agent built for an internal, reversible task can still reach an external system if its tool surface is wider than the task requires, which quietly raises its real blast radius above the one you planned for. Calibrate to what the agent can actually do given its tools and permissions, not to the polite description of what you meant it to do. When the two diverge, trust the tools, because that is what the agent will trust.
Frequently Asked Questions
Do I need every item before any deployment?
For anything touching production or irreversible actions, yes. For sandboxed experiments where nothing real is at stake, the scope and observability items matter most while rollback can be lighter.
What is the most commonly skipped item?
Source-level data filtering. Teams trust the prompt to keep the agent away from sensitive data, but a prompt is a suggestion, not a boundary. Real controls belong in the data layer.
Why cap chain length?
Long tool-call chains let small early errors compound into confidently wrong results. A hard cap forces the agent to stop and surface uncertainty instead of building on a bad foundation.
How long should a human stay in the review loop?
Until logged correction rates fall to a level you are comfortable with for that task's blast radius. High-stakes tasks may keep a human indefinitely; low-stakes ones can graduate quickly.
Is a kill switch really necessary for a small agent?
Yes. The cost of building one is trivial and the cost of not having one during an incident is high. Even small agents can loop, overspend, or send the wrong thing at scale.
Key Takeaways
- Treat the checklist as a literal gate; an unchecked item blocks production, not learning.
- Bound the task, minimize tools, and fence permissions at the data source before worrying about the model.
- Earn autonomy through logged review and shadow mode rather than launching on confidence.
- Cap chain length and monitor cost so small errors and runaway loops surface early.
- Always keep a kill switch, a revert path, and a named incident owner before flipping the switch.