Feature Flags for Prompts

Feature flags are the mechanism that separates prompt deployment (the prompt exists in production infrastructure) from prompt activation (the prompt is serving real user traffic). With feature flags, a new prompt version can be deployed to production without serving any user traffic, then progressively activated — 1% of traffic, 10%, 50%, 100% — with the ability to roll back instantly by flipping the flag, not by executing a deployment rollback.

Feature flag strategies for prompt rollouts: percentage rollout (the flag routes X% of traffic to the new prompt), user segment targeting (the flag routes specific user cohorts — beta users, internal users, enterprise tier — to the new prompt), and kill switch (a flag that can instantly route all traffic back to the previous prompt, regardless of current rollout percentage). Every production prompt launch should use all three: start with percentage rollout, monitor the target segment before expanding, and maintain the kill switch as long as the new version has not reached 100% stable traffic.

The flag is infrastructure. The prompt is the payload. The flag exists independently of any specific prompt version — it is a routing mechanism that stays in place as prompt versions change. Do not confuse feature flags with prompt versioning. A feature flag routes traffic. A version number identifies what is being routed to.

PROMPT ROLLOUT PLAN
Prompt: sales-email-007 v2.3.0
Previous version: 2.2.1
Flag name: sales_email_v2_3_0

ROLLOUT SCHEDULE
Day 1: 1% traffic
  - Monitor: format compliance rate, word count compliance, error rate
  - Pass threshold: all metrics within 5% of v2.2.1 baseline
  - Gate: manual approval before Day 3

Day 3: 10% traffic
  - Monitor: same metrics + downstream conversion rate (24h lag)
  - Pass threshold: format compliance ≥ baseline; conversion rate no worse than -2%
  - Gate: automated gate (if metrics pass) or manual escalation

Day 7: 50% traffic
  - Full A/B comparison v2.2.1 vs v2.3.0
  - Statistical significance check: minimum 500 sessions per variant
  - Decision: continue, pause, or rollback based on data

Day 14: 100% traffic (if metrics pass at 50%)
  - v2.2.1 remains in infrastructure for 30-day rollback window
  - Flag retained but set to 100% — not removed until rollback window closes

KILL SWITCH
Flag can route all traffic to v2.2.1 instantly
Authorization: any team member with flag console access
Trigger criteria: format compliance drops >10%, error rate >5%, or manual escalation