Is Your AI Agent Ready to Run Unattended? A 10-Point Production Checklist

A demo answers one question: can this system complete this example? Letting it run unattended asks a harder one: when it fails, will anyone know, how much damage can it do, and can it be recovered without creating a second problem?

This is the checklist I use on my own systems and on client automations before anything runs without a person watching. Each item has a test you can actually run, and the scorecard at the end turns them into a go, a limited pilot, or a no.

The examples come from defects I found and fixed in my own projects. They are evidence of specific behaviour, not a security certification, and not every item belongs in every small pilot.

Why "the agent said it finished" is not evidence

The unit you are evaluating is not the model's answer. It is the model working inside software that gives it tools, keeps state, applies permissions and decides when a task is done. Anthropic's guide to evaluating agents draws the line between what an agent reports and what actually changed in the environment.

For a business, that line is the whole game. A drafted reply, a queued reply, a sent reply and a correctly sent reply are four different outcomes. A dashboard that calls all four "success" hides exactly the information you need.

My own work orchestrator is built around that rule: a task is not complete until a verification command exits zero, whatever the model says. Each run has a hard budget ($1.50 per run and $5.00 per day), and after three failed attempts it stops and escalates to me instead of looping. None of those limits is clever. They are what makes it safe to leave running overnight.

1. Write down what "done" means

Test: can you state the input, the output and the stopping point in three sentences?

For an enquiry-triage agent: read one permitted inbox, draft a response with references to the source material, and put it in a review queue. Sending is out of scope until a named person approves it.

Then list what counts as failure. A plausible reply with an invented deadline is a failure. An unclear request routed to an exception queue is probably a success. "Automate support" is not a task; it is too big to price, test or debug.

2. Map everything it can reach

Test: a table of every account, key, folder, database and external service the workflow can touch, with read, write, delete and send marked separately.

Mark what is needed now and what is merely convenient for later. Then separate instructions from enforcement: a prompt telling the agent not to touch a folder is not a permission boundary. A credential that can only do the one operation is.

The OWASP Top 10 for Agentic Applications is a good list to challenge that table against.

3. Attack the approval step, not just the button

Test: try to trigger each approval-gated action without approval, from every entry point, without launching the real operation.

In my Sentinel project, all 167 existing tests passed. Inspection still showed that the default command-approval setting was not enforced everywhere, and the command-line path could silently approve familiar command names. Recognising a command's name said nothing about whether its arguments were harmless. The fix applied the approval check in the CLI, the controller and the executor, and the regression suite grew to 179 passing tests.

The lesson generalises: a check that exists only in the interface disappears the moment another integration calls the same function. Test malformed requests, cancelled approvals, dry runs and a caller that bypasses the usual screen.

4. Keep a small evaluation set, with a held-out half

Test: 20–50 real, authorised examples with the expected outcome and the evidence needed to accept it. Keep a portion you never use to tune prompts.

Include the ordinary case, incomplete requests, conflicting information, an unavailable dependency, and inputs that should be escalated. Score failures separately rather than as one number: a reply can be well-written and factually wrong, or accurate and sent to the wrong person. A good average must not hide a broken permission.

5. Check that the evidence supports the claim

Test: plant a conflicting date and a quoted instruction from a customer in your fixtures, and see what the system does with them.

A citation proves a source exists, not that it says what the answer claims. A model can quote a real sentence and still get wrong who is responsible or when something is due. Make uncertainty something an operator can act on: "needs review because two dates conflict" is useful, a bare confidence percentage usually is not.

6. Make retries safe

Test: force a timeout after the receiving service has accepted a request. Does a retry create a duplicate?

Ask what identifies a unique task, where its delivery state is stored, and how an operator resolves an uncertain result. Use idempotency keys where the receiving API supports them, and a reconciliation step where it does not. Then set a hard retry limit, after which the system stops, keeps its context and asks for help. An endless loop is not persistence; it is a bill.

7. Make monitoring tell the truth

Test: feed the monitor delayed, partial and historical data, and check what it shows.

In NexusTerm, a transcript parser stamped historical entries with the current time, so old work appeared active. The file watcher also moved past partially written records, which could lose an event permanently. The fix used the recorded timestamps and only advanced past complete records; the Xcode build and 24 tests passed, including a real file-notification test.

For a business workflow, know whether a timestamp means created, received, processed or completed. Show unknown and stale states as unknown and stale. A heartbeat that looks fresh because someone refreshed the page is worse than no heartbeat.

8. Measure cost per accepted outcome

Test: total cost of a pilot divided by outcomes that passed the acceptance check.

Include model calls, retrieval, other APIs, retries, hosting, and the human time spent reviewing and fixing. Illustrative arithmetic, not a client result: a pilot that costs $60 and produces 30 accepted tasks costs $2 per task. If only 15 are accepted, it is $4. Cheap calls do not rescue a system that needs constant repair.

Put a hard cap on spend, per run and per day, and decide what happens when it is hit. The right answer is that the work stops and someone is told.

9. Rehearse stopping and recovery

Test: stop a run halfway on purpose, then have someone other than the builder work out what finished, what is uncertain and what is safe to retry.

Check what happens to queued actions, open requests and held credentials. If cancelling cannot undo an action the other system already accepted, say so in the runbook. Keep only the operational data you need to recover: raw prompts and documents can contain sensitive material, so decide retention and redaction on purpose.

10. Launch a measured pilot, not a promise

Test: is there a written limit on volume, allowed actions, budget, reviewer and rollback trigger?

Record the model and configuration so later changes can be compared against the same baseline. Hand over the task definition, permission map, evaluation set, known failures, run instructions and recovery procedure. If whoever built it cannot say what is still unverified, that silence is itself a finding.

The go/no-go scorecard

Score each item 0 (not done), 1 (partly) or 2 (done and tested):

| # | Check | Score | |---|---|---| | 1 | "Done" is defined, with failure cases | | | 2 | Access map, with read/write/send separated | | | 3 | Approval enforced at every entry point | | | 4 | Evaluation set with a held-out portion | | | 5 | Evidence checked against the claim | | | 6 | Retries capped and duplicate-safe | | | 7 | Monitoring shows stale and unknown honestly | | | 8 | Cost per accepted outcome measured, spend capped | | | 9 | Stop and recovery rehearsed | | | 10 | Pilot limits and rollback written down | |

• 16–20, with no zero on 2, 3, 6 or 8: ready to run unattended within the pilot limits.
• 10–15: run it with a person approving every irreversible action while you close the gaps.
• Under 10, or any zero on 2, 3, 6 or 8: not ready to touch real systems. Those four are where the expensive failures live: too much access, bypassable approvals, duplicate actions and runaway spend.

Where to go from here

You do not need a platform to start. You need a workflow small enough to understand and evidence strong enough to decide whether it should grow.

If you already run an agent and want this checklist applied to it, an AI systems review is the scoped version. If you have not built anything yet and want to know which workflow is worth automating first, start with the $299 AI Workflow Audit. And if you are choosing who should build it, read how to hire an AI automation developer.