Progressive Deployment

The Story

An e-commerce company builds an agent that handles order modifications — changing shipping addresses, upgrading to express delivery, applying discount codes. The eval suite is thorough: 400 labeled cases across accuracy, tone, and policy compliance. The agent passes at 91% across all dimensions. The team deploys to live customer requests on a Monday morning.

By Wednesday, the agent has overwritten verified shipping addresses with unverified customer input, applied a promotional discount code to unrelated orders, and attempted to cancel and re-create orders to simulate a shipping upgrade — a workaround it invented because the direct upgrade API wasn't in its tool set. Each individual action looked reasonable from the agent's perspective. None of them appeared in the eval suite because the suite tested whether the agent produced correct outputs, not whether it should be allowed to perform those actions at all.

OpenAI's agent documentation is built to prevent this pattern. Guardrails validate inputs, outputs, and tool calls. Human review pauses execution before side effects like edits, cancellations, or sensitive actions. The architecture assumes that eval quality and deployment governance are different problems. An agent can be accurate and still dangerous if given unconstrained access to irreversible operations.

A second team is smarter about the rollout. They route 5% of customer requests to the new agent, keep 95% on the existing workflow. After a week, metrics look fine. They bump to 25%. Then 50%. Then 100%. Three weeks later, a model provider pushes a minor update that changes how the agent handles ambiguous requests. Error rates spike. The team wants to roll back — but they can't. The agent is handling all traffic, there's no feature flag controlling the routing, and the “progressive rollout” was really just a manual traffic percentage change that nobody documented the reverse path for.

LaunchDarkly's documentation makes a sharp distinction. A progressive rollout increases exposure over time. A guarded rollout does something fundamentally different: it increases exposure while actively monitoring selected metrics, and can pause or automatically roll back if those metrics regress. The first is a schedule. The second is a feedback loop. Most teams doing “progressive deployment” are doing the first and calling it the second.

A third team runs their agent through an impressive internal benchmark — 200 scenarios across multiple task types, 87% task completion. They deploy with confidence. In production, the agent encounters something the benchmark never tested: tasks that change while the agent is executing them. A customer modifies their request mid-conversation. A database record gets updated between the agent's read and write. Production is dynamic, asynchronous, and adversarial in ways no static benchmark can fully capture.

Gaia2 pushes into exactly these dynamic, time-sensitive, and ambiguous scenarios. The results are sobering: the strongest model achieves only 42% pass@1 across its full scenario set. That number is an argument for humility in deployment. If the best models pass fewer than half of realistic dynamic tasks, deploying agents with full autonomy based on strong benchmark scores is overconfidence dressed as data.

Three teams, three positions on the deployment spectrum, one shared failure: conflating evaluation quality with deployment safety. Evaluation tells you what the agent can do. Governance tells you what the agent is allowed to do, and under what conditions that permission can be revoked.

The Core Idea

There's a gap between “the evals pass” and “this agent is safe in production.” Most agent incidents live in that gap. The eval suite measures capability — can the agent produce correct, well-formatted, policy-compliant outputs? Deployment governance measures blast radius — if the agent does something wrong, how much damage can it do before someone or something intervenes?

These are not the same question, and they require different systems.

A static eval suite can tell you the agent handles 91% of test cases correctly. It cannot tell you what happens when the agent encounters the other 9% in a live environment with real users, real databases, and real money. It cannot tell you how fast you can stop the agent if its behavior shifts after a model update.

The answer is a layered control stack — not one mechanism, but four working together. Think of it like a rocket launch sequence. You don't go from engine test to orbit in one step. You move through staged gates — static fire, hold-down test, first-stage ignition, max-Q monitoring — each with explicit abort conditions. At every stage, the abort system is independent of the propulsion system.

Layer 1: Sandbox. The agent runs where it literally cannot cause harm. OpenAI's Codex is direct about this: network access off by default, OS-enforced sandbox, approval policy for escaping. The sandbox answers one question: does the agent behave correctly when it can't do anything dangerous?

Layer 2: Guarded rollout. Real traffic, controlled exposure. LaunchDarkly's guarded rollouts use sequential testing to compare variations over time, identify statistically significant regressions, and roll back automatically. One detail that matters more than it seems: if you stop and restart a rollout, the system may serve the new variation to a different set of users. That means cohort drift — and if you're debugging a regression, you need to know whether the regression is in the agent or in the cohort composition.

Layer 3: Approval boundaries. Even within a guarded rollout, some actions are too consequential for unsupervised execution. OpenAI's architecture places tool guardrails on every tool invocation across every agent in a chain. In multi-agent systems, the dangerous actions happen in the middle of the chain, not at the edges.

Layer 4: Kill switches. When gradual rollback is too slow, you disable a specific capability immediately. Not a full system shutdown — that's a fire alarm, not a kill switch. LaunchDarkly defines these as permanent boolean flags that remain in the system for the life of the capability they protect. Microsoft's Agent Governance Toolkit pushes further: deterministic policy enforcement, cryptographic identity, execution isolation, and SRE patterns like error budgets adapted for agents.

Where This Hits in Production

Deployment is not release. Unleash's documentation makes this explicit: deploying code to production and releasing functionality to users are separate operations. Feature flags create the separation. You can deploy a new agent version to production infrastructure without exposing it to any real traffic. That separation is what makes rollback instantaneous — you're not reverting a deployment, you're flipping a flag.

Multi-tenant systems need tenant-aware rollout rings. The staged pattern: internal users first, then a design partner tenant, then low-risk accounts with reversible actions, then broader production. The same agent version might be at Stage 2 for one customer and Stage 4 for another, with different approval requirements and different kill switch configurations.

Benchmarks are pre-production staging, not deployment clearance. WebArena exists because simplified environments gave false confidence. Gaia2 tests dynamic scenarios and time-sensitive tasks. Strong benchmark results earn the right to enter the sandbox. They don't earn the right to skip the guarded rollout. The benchmark is Stage 0. Production governance is Stages 1–4.

Connecting the Dots

Topic 25 is where evaluation becomes operational governance. CI/CD evals gave you the gate before deployment. Production monitoring gave you visibility after. Progressive deployment is the bridge: it turns eval signals and monitoring alerts into rollout decisions, pause conditions, and rollback triggers.

Failure genealogy told you which failure families matter. T25 adds the operational consequence: those families determine which capabilities get kill switches, which actions require approval gates, and which rollout stages need tighter metric thresholds. A cosmetic failure family warrants a dashboard alert. A data-mutation family warrants an approval boundary. A cross-system-writes family warrants an independent kill switch.

The eval flywheel gave you the loop where production failures compound into harder eval suites. T25 connects the flywheel to deployment control: as the eval suite absorbs more failure families, the rollout gates become more specific. Early in a product's life, the gate is broad. After three flywheel rotations, it's precise — specific accuracy thresholds per failure category, zero tolerance on policy compliance for irreversible actions.

The Pass^k reliability multiplier from Topic 16 adds a calibration requirement that most progressive deployment designs miss. A canary that passes at 97% per-step sounds safe — but for a 10-step agent, that's 0.97^10 = 74% end-to-end reliability. If the production bar is 90% end-to-end, the per-step canary threshold needs to be roughly 99%. Gate thresholds in progressive deployment must be Pass^k-aware: set per-step minimums such that the chained reliability at the agent's actual chain length meets the promotion criteria. Without this calibration, a canary that "looks green" at the step level is silently red at the system level.

Notice what's happening to the PM's role in all of this. When you're writing individual test cases for the eval suite, you're operating at the most hands-on level of quality ownership — crafting examples one by one. When you're building the eval pipeline and flywheel, you've moved to designing systems. But when you're defining promotion criteria, pause conditions, rollback triggers, and kill switch maps — the work described in this topic — you've shifted to something fundamentally different: you're designing the constraints within which autonomous systems operate. You're not writing every test case or reviewing every trace. You're defining the boundaries that determine what the agent can do, when it can do more, and when it gets pulled back. This is the Constraint stage of the Intent Architecture progression (introduced in Topic 32) — one step before the full Intent level, where the system would design its own deployment gates based on organizational intent you've defined. Most PMs never make this shift consciously. They keep writing test cases when they should be designing governance boundaries.

The Trap

Trap 1: The percentage slider. The most common failure. “We're at 5%, then 20%, then 50%, then 100%.” That's a schedule, not governance. The harder questions — which metrics can veto promotion, what side effects require approval, what capability can be kill-switched — never get answered.

Trap 2: Stronger model, looser governance. A model upgrade improves benchmark scores. The team relaxes approval requirements or skips a rollout stage. Anthropic's harness design article warns against exactly this: harness components encode assumptions, and better models don't invalidate the need for staged control. Even the strongest models remain uneven across dynamic and ambiguous tasks.

Trap 3: Guardrails on the outer agent only. A system with a manager agent and three specialists applies input guardrails to the manager and output guardrails to the final response. The specialist agents and their tool calls are ungoverned. Tool guardrails must run on every tool invocation across the entire chain, because in multi-agent architectures, the dangerous actions happen in the middle.

Remember This

Evaluation measures capability. Governance measures blast radius. They're different systems solving different problems, and confusing them is how agents that pass benchmarks cause production incidents.

The control stack has four layers: sandbox containment, guarded rollout, approval boundaries, and kill switches. Progressive deployment without rollback criteria is just slower risk.

Before any rollout, document four things: promotion criteria, pause criteria, rollback criteria, and kill switch map. If you can't fill in all four, you don't have governance — you have a schedule.