Quick answerA pilot is ready to graduate to general availability when four conditions are all true at once, not just one: it has run at production-representative volume for a defined minimum period without a materially elevated error or escalation rate, its support and on-call ownership has been formally transferred out of the pilot team, its cost-per-interaction has been validated at the volume GA will actually bring, not just pilot volume, and there is an explicit, signed-off decision from whoever owns the GA budget, not just an absence of objections from the pilot's own team.
Why "the pilot has gone fine so far" is not a graduation criterion
Pilots and betas tend to graduate to general availability by default, momentum and the absence of a loud failure carry them forward rather than an explicit decision against a defined bar. That default is exactly how gaps show up right after GA: support ownership that was informally handled by whoever built the pilot suddenly has no formal home once volume triples, or a cost-per-interaction number that looked fine at pilot scale turns out not to hold once real GA volume hits infrastructure that was never load-tested at that level.
This is a different checklist from the go/no-go readiness checklist used before a first launch, which governs whether something should launch at all. This checklist assumes the thing is already partially live and asks a narrower, later question: is it ready to stop being a pilot and become the default, generally available version.
It is also different from a POC-to-production handoff checklist, which is about the mechanics of one team handing work to another. A pilot can be fully handed off to the production team and still not be ready for general availability, handoff and graduation are sequential, not the same event.
The four conditions, and why all four are required
Volume-representative track record. A pilot that ran smoothly at ten percent of expected GA volume for two weeks has not actually been tested at the scale GA will bring. Define a minimum period at a volume genuinely representative of what GA traffic will look like, not just pilot traffic, before counting the pilot's track record as evidence.
Formal support and on-call transfer. During a pilot, the team that built it usually fields any issue directly and informally. GA needs a defined on-call rotation and support-escalation path that does not depend on the original builders being personally reachable. If that transfer has not formally happened, with documented ownership, the pilot is not ready regardless of how well it has performed.
Cost validated at GA volume, not pilot volume. Per-interaction cost figures from a low-volume pilot often do not hold at scale, sometimes favorably due to fixed-cost amortization, sometimes unfavorably due to rate limits or tiered vendor pricing kicking in. Model or directly test cost at projected GA volume before treating the pilot's cost figures as GA-ready numbers.
An explicit, signed-off decision. The absence of anyone objecting to graduation is not the same as an affirmative decision by whoever owns the GA budget and outcome. Require a specific sign-off tied to the other three conditions being met, not a default that GA happens automatically once the pilot has quietly run long enough.
What operational readiness for a volume increase actually requires
Meeting the volume-representative track record condition above overlaps with, but is not identical to, what operational readiness looks like before a predictable AI agent volume spike, which covers a temporary spike rather than a permanent step-change in baseline volume. GA graduation should borrow that post's operational-readiness thinking but apply it to a sustained new baseline, not a short-term surge.
FAQ
Can a pilot graduate to GA in stages, rather than all at once? Yes, a staged rollout by customer segment or geography is a reasonable way to satisfy the volume-representative condition incrementally, as long as each stage still requires its own explicit sign-off rather than treating the first stage's approval as covering all subsequent ones.
What if the pilot has been running for months with no formal graduation decision either way? That is itself a signal worth escalating. An indefinitely running pilot usually means ownership and cost validation were never formally addressed, not that the product is not ready, and it should be forced through this checklist rather than left in permanent limbo.
Does a pilot that fails one of the four conditions get sent back to POC, or held at pilot stage? Held at pilot stage with a specific remediation plan for the failed condition. Sending it back to POC discards a working pilot's track record for no reason; the fix is almost always narrower than a full restart.