CONCEPT Cited by 3 sources

Feature flag¶

A feature flag is a runtime switch that gates a code path by context, rollout percentage, or targeting rule — enabling release to be decoupled from deploy and cohort-scoped rollouts. The code is in production but inert until the flag turns on for some population; ramping is a config change, not a redeploy.

The basic decoupling¶

Without flags, deploy-day = release-day — every user gets the new code path the moment the binary/Worker goes live. With flags:

Deploy: new code ships behind if (flag(...)) { new } else { old }. Flag is off. Nothing changes for users.
Release: flip the flag on — for one user, one cohort, a percentage, a region — watch metrics.
Revert: flip the flag off. Seconds, not a rollback deploy.

This is why flags are the substrate for agent-controlled deployment: the blast radius is bounded by the flag state, which is itself a fast, auditable control-plane edit.

Evaluation model¶

A flag typically has:

Variations — the possible returned values (boolean, string, number, or full JSON object — see Flagship's four variation types).
Rules — conditions evaluated in priority order, first-match wins, each mapping a matching context to a variation (plus an optional percentage rollout).
Default — returned on evaluation error or when no rule matches.

Rules compose via AND/OR — Flagship allows up to 5 levels of nesting, implicit AND at the top of a rule, nested AND/OR groups below.

What's hardcoded flags¶

The anti-pattern is "just commit a boolean and redeploy" — works at one or two flags, collapses at ten:

"One hardcoded flag becomes ten. Ten becomes fifty, owned by different teams, with no central view of what's on or off. There's no audit trail — when something breaks, you're searching git blame to figure out who toggled what." (Source: Cloudflare Flagship, 2026-04-17)

A proper flag service adds: central catalog, dashboard UI, audit trail, rule evaluation engine, rollout ramping with stable bucketing, and vendor-neutral call-site API via OpenFeature.

Evaluation-location trade-offs¶

Where the flag(context) call runs matters:

Remote evaluation (HTTP to flag service) — every user request waits on an outbound call. Centralized, easy to update, but "sits on the critical path of every single user request. It could add considerable latency." (Source: sources/2026-04-17-cloudflare-introducing-flagship-feature-flags-built-for-the-age-of-ai.)
Local-evaluation SDK — rules downloaded into memory, evaluated in-process, refreshed in the background. Assumes a long-lived process; breaks on serverless isolate substrates where "a Worker isolate can be created, serve a request, and be evicted between one request and the next."
Edge-local evaluation against a replicated config store — evaluation in the same runtime isolate that serves the request, reading config from an edge-replicated KV cache; no outbound hop, no long-lived SDK. See in-isolate-rule-evaluation + do-plus-kv-edge-config-distribution.

Not just for humans¶

The 2026-04-17 Cloudflare Flagship launch is explicit that the motivating user is an AI agent, not a release manager:

"An agent writes a new code path behind a flag and deploys it — the flag is off, so nothing changes for users. The agent then enables the flag for itself or a small test cohort, exercises the feature in production, and observes the results. If metrics look good, it ramps the rollout. If something breaks, it disables the flag."

See agent-controlled-deployment.

Stale-flag cleanup as KTLO automation target¶

The mirror image of the agent-as-flag-author framing is agent as flag-cleaner: once a flag is fully rolled out, the inert side of the conditional becomes dead code that "impacts performance, reliability, and developer productivity." Atlassian's 2026-06-01 Jira-team post is the canonical wiki articulation of stale-flag cleanup as one of the canonical KTLO chores mapped onto an agentic workflow:

"On a large, multi-product codebase, cleanup is harder than 'just removing the code.' A flag might be fully rolled out for some customers but still active for others due to compliance requirements, release tracks, or experiment holdouts. Piecing together a flag's true state across systems was manual and error-prone. The work was tedious, time-consuming, and repetitive — perfect for agents." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

The automation pipeline:

Daily heuristic cron scans the codebase for flag references, cross-references compliance / experiment / release-track state, and emits one Jira work item per stale flag with structured fields (flag name, type, repo, paths, line numbers, desired final state). (agentic-pr-triage)
Engineer transitions the work item's status, which triggers the agent with a custom system prompt. (jira-status-transition-triggers-agent-workflow)
Agent runs a three-tier skill fallback chain — repo-specific cleanup skill → flag the repo for skill creation + provide owner instructions → generic cleanup skill — and opens a draft PR. (agent-skill-with-fallback-chain)
Engineer reviews + merges through the standard merge-queue path (Bitbucket Merge Queues).

Reported throughput on the Jira repo alone: 500+ merged PRs in 70 days — ≈ 7 PRs/day on a single KTLO category.

A later Atlassian post (2026-09-24) documents the standalone feature-flag-cleanup instance of this same Dispatcher → Coding Agent → Closer loop, and hardens two properties worth calling out:

Verify the flag's state before editing. "A cleanup ticket is useful context, not proof that the codebase is unchanged." Repos drift between ticket creation and agent run — sometimes the flag is already gone, sometimes its final value flipped — so the agent searches for the flag name and value first and stops if it can't confirm the state (patterns/verify-before-changing-code).
Per-call-site transformation, not a blanket edit. The cleanup skill keeps the branch matching the final value and deletes the other path, the flag helper, and unused imports at each call site ("the pattern is often not uniform"), escalating to a human when the final value is false or the surviving branch is unclear.

Seen in¶

— Canonical framing of feature flags as per-tenant-cell blast-radius cap in a DBaaS fleet. Max Englander (PlanetScale, 2025-07-03) names feature flags as the substrate for per-database progressive delivery: "Database cluster config and binary changes are shipped database by database using feature flags". Load-bearing consequence: "A bug in Vitess or the PlanetScale Kubernetes operator rarely impacts more than 1-2 customers, thanks to our extensive use of feature flags to roll out changes." Canonical granularity: flags evaluate in a per-database context so the unit of rollout is one customer cluster at a time, bounding the blast radius of a bad ship to the customer(s) whose flag flipped just before telemetry surfaced the regression. Also composes with weekly failover drill — the flag-gated ship arrives via the failover itself.
sources/2026-04-17-cloudflare-introducing-flagship-feature-flags-built-for-the-age-of-ai — canonical wiki introduction; Flagship is the OpenFeature- native Cloudflare-built primitive, framed explicitly as the bounded-blast-radius substrate for agent-driven shipping.
— feature flag as kill-switch substrate at the async-job altitude. PlanetScale uses Flipper — a general-purpose Ruby feature-flag library — as the deploy-less config channel for disabling async-job classes via naming-convention flags (disable_<classname>). Canonical datum: general feature-flag systems can serve as the config channel for specialised kill-switches, no bespoke control plane required. See feature-flagged-job-enqueue-rejection.
sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in — canonical wiki instance of stale-flag cleanup as agentic-KTLO automation target. Atlassian's Jira team runs a daily heuristic cron that emits one Jira work item per stale flag with full pre-resolved cross-system state (flag name + type + repo + paths + line numbers + desired final state), then routes through Jira-status-transition-triggered agent runs that dispatch via a three-tier repo-specific → flag-for-creation → generic skill fallback chain. Reported throughput: 500+ merged PRs in 70 days on the Jira repo alone. The post canonicalises the cross-system-state-piecing problem (compliance / experiments / release-track holdouts make "is this flag actually stale" a hard query) and demonstrates that a heuristic cron encoding the team's pattern recognition is a viable detection layer for agentic remediation.
sources/2026-09-24-atlassian-how-we-automated-feature-flag-cleanup-with-agentic-pipelines — the standalone feature-flag-cleanup agentic pipeline. A scheduled Rovo Studio rule (dispatcher) queries Jira for eligible stale-flag tickets and fans out one coding-agent Bitbucket Pipelines run per ticket; the agent loads a feature-flag-cleanup skill, verifies the flag's current state, keeps the surviving branch, deletes the dead path + gate definition + unused imports at each call site, updates affected tests, runs checks, and — only if checks pass — opens a PR and comments/labels the ticket. In production since April 2026, run monthly. Canonical instance of the patterns/dispatcher-coding-agent-closer loop applied to flags and of patterns/verify-before-changing-code (verification as step one).
percentage-rollout
vendor-neutral-evaluation-api
agent-controlled-deployment
concepts/audit-trail
deploy-less-operational-lever
client-middleware-interception
ktlo-engineering-chores — work-category framing for stale-flag cleanup as agentic-automation target.
work-item-as-agent-prompt — the substrate the cleanup workflow runs through.
agent-as-first-pass-investigator — the operational model.
patterns/staged-rollout
patterns/progressive-configuration-rollout
patterns/dispatcher-coding-agent-closer — the agentic-cleanup loop.
patterns/verify-before-changing-code — verify flag state before editing.
in-isolate-rule-evaluation
do-plus-kv-edge-config-distribution
feature-flagged-job-enqueue-rejection
patterns/fast-rollback
agentic-pr-triage — Atlassian's detection layer.
jira-status-transition-triggers-agent-workflow — Atlassian's trigger.
agent-skill-with-fallback-chain — Atlassian's per-codebase skill dispatch.
systems/cloudflare-flagship
systems/openfeature
systems/flipper-gem
systems/jira — Atlassian's substrate for the agentic cleanup workflow.
systems/rovo-studio — the scheduled dispatcher in the flag-cleanup pipeline.
systems/rovo-dev — likely consuming agent.

Merged aliases¶

feature-flag-rollback-for-validator