Moving a multi-agent AI system from staging to production is not the same as moving a standard API service to production. The operational requirements are different in ways that standard production readiness checklists don't capture — they focus on stateless services, not on systems that call external model providers with variable latency, unpredictable costs, and non-deterministic output.
This checklist is based on what we've seen teams miss — not in development, where everything is tested — but in the weeks after production launch, when the edge cases surface.
1. Observability — can you answer the question?
The production readiness test for observability is: when something goes wrong, can you answer "what happened?" from telemetry alone, without SSH access to production servers?
Required:
- Every agent invocation produces a structured log entry with: workflow name, invocation ID, model used, token count (prompt + completion), latency, status (success / error / fallback activated)
- Traces span the full workflow execution — from the initial trigger through every agent hop, including routing decisions and fallback activations
- Metrics are scraped by your existing observability stack (Prometheus, Datadog, etc.) — not just available in a custom dashboard you built yourself
- You can reconstruct the full trace for any specific invocation ID from the last 90 days
Failure mode if missing: Provider incident at 2am. On-call spends 90 minutes cross-referencing provider logs, application logs, and deployment history to understand which agents were affected and why. Resolution takes 3+ hours instead of 20 minutes.
2. Fallback coverage — every invocation has a survival path
For every agent invocation in your production workflow, there must be a defined path that succeeds even when the primary model provider is unavailable.
Required:
- At least one fallback tier defined for every workflow — ideally crossing to a different provider to handle provider-level outages, not just model-level outages
- Fallback chain is tested with real invocations against the secondary model in staging — not just assumed to work
- Latency SLO for fallback tier is documented and acceptable — if your fallback is a local model at 8s p99 and your SLO is 3s, your fallback doesn't meet your SLO
- Fallback activations emit telemetry so you know when they're firing and at what rate
Check to run: In your staging environment, block your primary model provider and run your full integration test suite. Does your workflow complete? Does the fallback activation appear in your telemetry? Does the output quality from the fallback tier meet your quality bar?
3. Budget enforcement — hard limits, not alerts
Cost alerts tell you after you've overspent. Hard enforcement prevents the overspend.
Required:
- Per-invocation token ceiling is configured for each workflow, not a single global limit
- Per-session rolling budget is configured for multi-turn workflows
- Budget enforcement triggers before the invocation reaches the model — not a post-hoc charge reversal
- Budget breach events emit structured telemetry with invocation ID, workflow, estimated token count, and ceiling
- On-call runbook includes the procedure for adjusting budget ceilings without a deployment
Risk without this: A workflow bug generates unusually long context prompts. The bug runs for 6 hours on a weekend. Monday morning: a provider invoice with an unexpected 4-figure overage and no structured data about which invocations caused it.
4. HITL gate coverage — compliance requirements are met
If your system operates in a regulated domain or has contractual requirements for human review, HITL gates must be treated as first-class infrastructure, not as ad hoc Slack notifications.
Required if you have compliance requirements:
- Gate trigger conditions are defined in config and version-controlled — not in application code
- Every gate event has a complete audit trail: trigger condition, reviewer ID, decision, timestamp, subsequent action
- Timeout behavior is explicitly configured: auto-reject, auto-approve, or escalate — not undefined (undefined = inconsistent behavior under load)
- The review queue has a defined owner and SLA — "someone in Slack reviews it when they see it" is not a documented process
- Audit log export is tested: you can produce a CSV of all HITL events for a given date range
5. Config management — policy is separate from code
Routing policy, fallback chains, budget ceilings, and HITL triggers should be config, not code. This determines whether you can respond to production incidents without deployments.
Required:
- Orchestration policy is declared in version-controlled config files — not hardcoded in agent functions
- Config changes have a documented apply procedure that doesn't require an application deployment
- Config history is auditable: you can answer "what was the routing policy at 14:37 on this date?" without reading git blame on application code
- Config changes are tested in staging before applying to production — there's a staging instance of the control plane that mirrors the production config
6. Graceful degradation — what happens when the control plane is unavailable
Any middleware layer adds a failure mode: what if the middleware itself is unavailable? For an AI orchestration control plane, you need a defined passthrough behavior.
Required:
- Passthrough mode is documented and tested: if the control plane is unreachable, agents fall back to direct provider calls
- Passthrough mode is acceptable from a compliance perspective — if HITL gates are a hard compliance requirement, passthrough may not be acceptable, and you need a "fail closed" behavior instead
- The tradeoff is documented: in passthrough mode, routing policy, budget enforcement, and HITL gates are inactive. Teams understand what they're losing and for how long they can tolerate it.
7. Rate limit handling — provider quotas are a production concern
Model provider API rate limits are not a development concern. In production, any workflow with sufficient scale will hit them. They must be handled explicitly.
Required:
- Rate limit errors (429) are treated as fallback triggers, not application errors — the fallback chain handles them, not your application's error handler
- Provider rate limits are documented: what's your requests-per-minute quota on each provider? What's the per-model quota? Are you close to them at current production volume?
- Rate limit events appear in your telemetry so you have visibility into quota headroom
8. On-call runbook — can a new engineer handle an incident?
The final check: write down the steps your on-call engineer would follow for the three most likely AI-system incidents, and give the runbook to an engineer who has never operated the system. Can they execute it?
Incidents to document:
- Primary model provider outage — how to verify, how to check fallback activation rate, how to change routing policy if fallback quality is insufficient
- Unexpected cost spike — how to identify which workflow is causing it, how to tighten budget ceiling without a deployment
- HITL queue backup — how to see how many invocations are waiting, how to escalate reviewer assignment, how to extend timeout window
If the runbook requires deployment steps, it's not operationally ready. If a new engineer can't follow it, it's not complete.
The standard is higher than for stateless services
The reason this checklist differs from a standard production readiness checklist is that multi-agent AI systems have properties that standard services don't: non-deterministic output (harder to test comprehensively), external cost dependencies (a bug can have immediate financial impact), variable latency (normal ranges are wide), and compliance obligations that require durable, auditable records of decisions.
Meeting this checklist takes real engineering investment. Teams that skip it consistently find the production launch is the easy part — it's the operational management of the system over the following six months where the gaps surface, usually at the worst possible time.