A rollout checklist for putting your first AI agent into production

The AI agent rollout checklist at a glance

An agent pilot can go wrong without the model misbehaving at all: nobody agreed what a good result was, a scheduled run quietly did not happen, or a run kept spending and nobody could stop it. Each step below gives the next one something to test against. Work through them with one agent and one task.

1. Define the task and what a good result looks like.
2. Name an owner and a reviewer.
3. Connect reporting and verify it end to end.
4. Report the schedule as well as the runs.
5. Test the failure paths on purpose.
6. Set limits that stop a run.
7. Guard consequential actions with a human approval.
8. Review the pilot on a fixed cadence.
9. Decide go or no-go with evidence.
10. Expand one step at a time.

To tick through these as you go, the interactive pilot checklist at /resources/supervision-checklist builds a copy you can download and keep with the pilot’s notes.

Define the task, a good result and who owns it

Pick one recurring task with a clear deliverable, such as a weekly research brief or a nightly data cleanup report. An open-ended assistant makes a poor first pilot, because there is nothing fixed to check its work against. Write down, in a few lines:

1. What the agent produces and where it lands: a file, a ticket, a message or a pull request.
2. When it should arrive, for example every weekday by 07:00 in a named time zone.
3. What makes it acceptable: required sections, sources that must be cited, fields that must not be empty.
4. What it must never do without a person, such as emailing someone outside the company or changing a production record.

Then name two people. The owner receives the alerts, fixes the configuration and decides whether the agent keeps going. The reviewer judges each output against the written definition. One person can hold both roles in a small team, but write both down.

Connect reporting and verify it end to end

Instrument the agent so each execution reports a run with a start and an end, the main steps inside it, and its result. Keep its credential in the runtime environment rather than in code, and keep secrets and customer data out of free-text fields. Then verify from where the agent really runs:

1. Send a test report from the machine or container that will run the agent, not from your laptop.
2. Trigger one real run and confirm its start, each step and its end appear under the right agent name.
3. Make the agent raise an exception in a test environment and confirm the run ends as failed rather than staying open.
4. Block the network path to the monitoring service and confirm the agent still finishes its work. Reporting should never be the reason an agent fails.

Report the schedule as well as the runs

Run history only shows runs that happened. If the scheduler never fires, the history just looks quiet. To tell the two apart, the monitor needs to know when the next run is due, so report the calendar, the time zone and the next expected run time, and update that time whenever a run starts. Then decide how late counts as missed: a short grace period for a job that starts on time, a longer one for a job that waits on an upstream export.

Test each failure path on purpose

A pilot that has only seen successful runs has not tested its monitoring. In staging, or with harmless test data, cause each of these and note what alerted, who heard and how long it took:

1. Missed run: disable the trigger for one slot. The owner should hear the run is overdue without opening a dashboard.
2. Crash: kill the process mid-run with a signal it cannot catch, so it never reports an end. The open run should be flagged as stalled.
3. Bad output: have the agent write an empty file or a report missing a required section, and check that an output check or the reviewer catches it.
4. Runaway: give the agent a task that loops, or a budget small enough to hit, and confirm the run is stopped and recorded with the reason.
5. Repeated failure: make three runs fail in a row and check the pattern is raised as one problem, not three separate messages.

After each test, ask the owner to find the cause from the recorded evidence alone. If they have to log in and read raw logs, the reporting is missing a step.

Set limits and guard actions that are hard to undo

A limit belongs on the path the spending takes. Put a per-run cap on runtime, model calls, tokens or cost, and make reaching it stop the whole process, including anything it started. An alert on a threshold is a notification, not a limit.

Next, list every action that is hard to reverse, such as messaging customers, merging code, paying, or changing records in a system of record, and decide which need a person to approve the exact action first. The approval should cover this email to these recipients, not email in general, and a denial or a timeout should mean the action does not run.

Review the pilot on a fixed cadence

Put a short review in the calendar, weekly for most pilots, and hold it even when nothing went wrong. The reviewer opens the actual outputs, not a status summary, and records accept or reject for each with a reason. The owner goes through the week’s incidents: what fired, who acknowledged it, how long that took and whether the cause is fixed. Track a few numbers from the first week:

• Expected runs against runs that actually started.
• Outputs reviewed, and how many were accepted.
• Incidents opened, and the time from alert to acknowledgement.
• Reported cost per run, where you have it, next to whether the result was accepted.

Decide go or no-go with evidence, then expand

Fix the length of the pilot before it starts, long enough to include the task’s normal variation, such as a month-end or a Monday backlog. A reasonable bar for going ahead:

1. Every failure you caused in testing was detected and reached the owner.
2. Expected and received runs match, or every gap has an explanation.
3. The reviewer accepted outputs at a rate the team agreed in advance.
4. Limits and approvals behaved as designed, including at least one rejection.

No-go is a valid result, and so is a shorter second pilot. When you expand, change one thing at a time: more runs of the same task, then a second task, then a second agent. Give each change its own round of failure tests, because a new schedule or a new action brings new ways to fail.

Running the checklist with Toolcaise

Toolcaise covers the reporting, alerting and control parts of this list. Agents report through the Python or Node.js SDKs, the HTTP API or OpenTelemetry, or run under Toolcaise Connect, a command-line connector on your own machine. With the Python SDK, python -m toolcaise check confirms Toolcaise accepts the agent’s credential before you trigger a real run.

1. Reporting: runs, steps and outcomes appear under the agent. The SDKs queue reports in the background and carry on if Toolcaise is unreachable, so the network test above should pass.
2. Schedule: report the calendar, time zone and next expected run with the agent’s telemetry, and Toolcaise opens an incident when a run is 15 minutes overdue.
3. Failure tests: a run with no update for 30 minutes and three consecutive failed runs each open an incident, and a failed output check opens an alert. Alerts can go to email, Slack, Microsoft Teams, Discord, PagerDuty or a signed webhook, and each incident can be acknowledged and closed.
4. Limits: toolcaise-connect run measures every model call made through an OpenAI- or Anthropic-compatible API and stops the command and everything it started when a limit is reached. Limits set per agent in the dashboard merge with the machine’s own, and the stricter value wins. With --remote-control, the dashboard can also pause, resume or stop that run.
5. Approvals: guarded_action() in the SDKs asks a person to approve the exact action and runs it once, only if approved. For tools behind an MCP server, toolcaise-connect mcp --require-approval holds matching calls until someone decides, and refuses them if nobody does.
6. Review: the agent reports an outcome, optionally with the SHA-256 of the artifact, and a workspace owner or admin accepts or rejects it. An optional weekly report summarizes runs, incidents, approvals waiting and reported cost.

toolcaise-connect run --agent "Weekly brief" --max-model-calls 3 -- python agent.py

What Toolcaise does not cover

Toolcaise does not judge whether an output is correct. That is the reviewer’s job, and an accepted outcome records their decision rather than proving anything. Figures reported through the SDKs are the agent’s own claim, and SDK pause, cancel and approvals are cooperative: they work at the checkpoints your code calls, and code that skips them is not stopped. Connect’s token and cost limits apply only to calls made through the standard OpenAI or Anthropic base-URL settings, cost comes only from prices you supply, and Connect is a preview whose builds are not yet code-signed. Toolcaise also cannot confirm that an external system received an action, so check the destination for anything consequential.