Share
AI Agent Production Readiness Checklist
October 19, 2026Read time: 7 min

AI Agent Production Readiness Checklist

A production readiness checklist for AI agents with write access: actions, correct state, end-to-end tests, failures, misuse and a release gate.

In short: an AI agent with write access is ready for production when you know each system it writes to, have defined correct state for its critical writes, have tested those writes end to end with failures and deliberate misuse, a failed check blocks the release, and someone owns the decision. The checklist below is the one we use in Mutation Risk Audits; copy it and run it before your next release.

Most production readiness lists for agents are about the model: accuracy, latency, cost, guardrails. Those matter. But for agents with write access, the questions that decide whether a release hurts a customer are about actions. This checklist is grouped in six parts.

1. Do you know what the agent can change?

  • Every system the agent can write to is listed: ERP, CRM, billing, document store, email, ticketing, internal APIs.
  • Every action in each system is listed: create, update, delete, send, approve.
  • Each action is ranked by cost if it goes wrong: money moved, legal effect, customer-visible, internal only.
  • Tool permissions match the list. The agent cannot do things it was never meant to do.
  • Irreversible or high-value actions require human approval, and that requirement is enforced outside the prompt.

If you cannot write this list in an hour, the agent has more reach than the team knows about. That is the first finding of most audits.

2. Have you defined what correct looks like?

  • For each high-cost action, the expected end state in the target system is written down field by field.
  • Domain experts, not only the engineers who wrote the prompts, have reviewed those expectations.
  • Expectations cover units, currencies, dates and IDs, not just "a record exists".
  • You know which differences are acceptable (wording, formatting) and which are not (amounts, recipients, deadlines).

The common failure here is defining success as the agent's own message. See hallucinated success for why that does not work.

3. Have you tested the writes end to end?

  • Critical flows run against a test instance of the real target system, not only against mocks.
  • After each run, the target system is read back and compared with the expected state.
  • The test data includes awkward cases: similar names, unit conversions, closed records, multiple currencies.
  • Each flow has been run more than once to see whether results vary between runs.

The full method is in how to test AI agents that write to your CRM or ERP. For the most common failure, see AI agent wrote wrong data to your CRM or ERP.

4. Have you tested what happens when things go wrong?

  • Critical flows have been run with injected timeouts, 5xx errors and slow responses from each dependency.
  • Under retries, each flow ends in exactly one write or a clean failure. See duplicate writes.
  • When a write fails, the agent says so to the user and does not report success.
  • Partial work, such as a draft created but not filed, is either completed or rolled back.

5. Have you tested deliberate misuse?

  • Inputs the agent reads from outside (emails, documents, web pages, tool results) are listed per high-cost action.
  • Each of those paths has at least one prompt injection case with a defined safe outcome.
  • Direct misuse is tested: users asking the agent to skip approvals, split orders or act outside scope.
  • Safe outcomes are checked in the target system, not only in the agent's reply.

No suite catches every attack. The goal is that known patterns cannot regress silently. More in agent mistakes made on purpose.

6. Is there a release gate and an owner?

  • The checks above run before every release that changes prompts, tools, model or agent code.
  • They also run on a schedule to catch model provider updates and target system changes.
  • A failed check blocks the release. The rule for what blocks was agreed before the first failure.
  • A failure report includes the trace, expected and actual data, and steps to reproduce.
  • A named person owns the release decision.
  • The checks were written by someone other than the author of the change. See should the AI that wrote the code write its own tests?

What a release gate is, and why we call it that, is explained in what is a quality gate for AI agents? For model provider updates, see how to test a model change.

What about evals, monitoring and guardrails?

They belong on a full readiness review, and we assume you have them:

  • Evals for answer quality on representative tasks.
  • Observability for traces, cost and latency in production.
  • Guardrails for input and output filtering at runtime.
  • Rollback for a fast way back to the previous version.

They answer different questions from the checklist above. The comparison is in release gates vs observability and evals.

How do you score the checklist?

Do not turn it into a percentage. Look at it per action. For each high-cost action, every box in parts 2 to 6 should be checked. A low-cost action can ship with less. An agent with ten low-risk actions fully covered and one high-risk action untested is not ready, whatever the overall count says.

Which domains need the strictest version?

Domains where a wrong action creates financial, legal or contractual exposure. The domain-specific guides go deeper:

FAQ

What is AI agent production readiness?

The point at which an agent's actions in real systems have been checked well enough that a release is a controlled decision rather than a hope. For agents with write access, that means tested writes, tested failures, tested misuse and a gate that can block a release.

How long does the checklist take?

Part 1 usually takes an hour with the right people in the room. Parts 2 to 5 depend on the number of high-cost actions. Start with the top three and expand.

Do I need all of this for an internal agent?

Scale it to the risk. An internal agent that only reads data needs less. An internal agent that posts to your own ledger needs nearly all of it.

Can Agentiqa run the checklist with us?

Yes. That is what the Mutation Risk Audit is: 20 minutes to map your agent's write surfaces against this list, plus a release gate stopping a live failure. First release gates live within 7 minutes after that. See Enterprise.

Is there a free way to try the testing side?

The Community Edition is free for web apps and simple agentic workflows, with 20 runs a month that reset monthly. Pro is $39/month.

Next step

Fill in part 1 this week. If the list of actions is longer than you expected, that is normal, and a good reason to talk.

Book a 20-Minute Mutation Risk Audit