AI Agent Production Readiness: The Controls a Demo Does Not Test

An agent can complete a demo and still be nowhere near production-ready.

The happy path proves that a model can produce one useful result under friendly conditions. Production asks different questions. What happens when the same event arrives twice? When a tool times out after committing a side effect? When retrieved content tells the agent to ignore its rules? When a credential has too much access? When the cost ceiling is reached halfway through a workflow?

Readiness is the evidence that those boundaries behave as designed.

Begin with a bounded job contract

Write one sentence describing the trigger, input, decision, output, and owner. “Manage support” is not a job contract. “Classify new tickets in the assigned queue and draft a reply from the approved knowledge base for human review” is testable.

Then declare success: correct classification, cited source, no cross-customer data, no external send, and a review event recorded. If success cannot be measured, autonomy cannot be earned.

Enforce permissions outside the model

A model may propose an action. Deterministic code should decide whether that action is allowed.

The permission contract needs the allowed tool, resource and tenant scope, approval mode, maximum action value, runtime, retry ceiling, log requirement, owner, and revocation method. A prompt saying “do not send refunds above $50” is not access control if the tool credential can refund any amount.

Use narrow operations. draft_reply is safer than send_email. read_assigned_ticket is safer than query_database. create_refund_request is safer than refund_payment. Narrow tools make denial tests possible.

Build fixtures for failure, not only success

Every allowed action deserves a positive fixture and a set of negative fixtures:

• action outside the data scope;
• disallowed tool request;
• missing, expired, or mismatched approval;
• amount above the declared limit;
• duplicate event with the same idempotency key;
• provider timeout before and after a side effect;
• malformed or stale input;
• prompt injection inside retrieved content;
• request after credential or workflow revocation;
• log assertion proving no secret entered the audit trail.

Expected behavior must be explicit. Use allow/deny, exact side-effect count, error class, retry count, and audit event—not “the response should look sensible.”

Treat idempotency as a business control

Retries are normal. Networks fail, serverless workers restart, queues redeliver, and clients click twice. An operation that charges, sends, creates, or modifies must have an idempotency key at the side-effect boundary.

Test the same event twice. The expected result is one effect and two traceable processing records, not two effects and an apology.

Bound time, retries, and spend

Set a workflow deadline, per-tool timeout, maximum retry count, maximum token or model budget, and a fallback state. A failure after the budget is exhausted should stop safely and alert the owner; it should not switch to an unbounded loop or silently reduce quality for a high-stakes decision.

Cost estimates are not controls. Enforce the limits in code and test the limit path.

Make the system observable without leaking it

An audit event should identify the workflow, input record, source versions, proposed action, permission decision, approval, tool result, latency, cost, and final status. It should not contain raw credentials, full private documents, or unnecessary personal data.

Alerts need an owner and a tested route. “Slack integration configured” is weaker than a fixture incident that reached the on-call person with enough context to act.

Rehearse stop and recovery

A kill switch must stop an active or next scheduled action and prevent self-restart. A backup must be restored at least once. A compensating action—such as canceling a queued send—must be tested before it is needed.

When a workflow changes external state, document which failures can be rolled back, which require compensation, and which are irreversible. Irreversible actions need stronger approval and narrower authority.

Release by stages

The safest authority ladder is:

1. offline fixtures;
2. read-only production observation;
3. shadow recommendations beside the human process;
4. reversible internal writes with approval;
5. bounded autonomous external action;
6. broader authority only after stable evidence.

A model, prompt, tool, schema, permission, dependency, or policy change can invalidate prior evidence. Readiness is a versioned release state, not a permanent badge.

Use the free AI agent production-readiness assessment to grade your controls, then create a reviewable permission manifest. If a critical control remains unverified, that is the result—not an inconvenience to score around.