← Back to concept explainers

Concept Fable

Feature flag

Conclusion first:Feature flags control whether a capability is enabled without redeploying code. They can be rolled out gradually by user, tenant, region, task type, model, tool, policy, or risk level.

Feature Flag, Feature Toggle · Product engineering / release management

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

The new mechanism hides in the wall first; no need to tear down the city gate to switch it on

Stone Gate City was preparing to install a new mechanism on the city gate that could automatically lower flood boards during heavy rain. The craftsman was very proud and suggested tearing down the old gate and replacing the whole city's gates overnight.

The city defense officer disagreed. The city gate had caravans, military carts, and night travelers coming and going every day; if the new mechanism jammed, the whole city would be stuck outside the gate. He had the craftsman first hide the mechanism inside the gate wall, while normally still using the old winch.

On the first trial run, the mechanism worked smoothly at the east gate. The craftsman was eager to activate it across the whole city at once, but the gate officer allowed only one small gate for testing. The next day, the south wind blew sand into the gears, and the small gate stopped halfway up.

The craftsman said fixing the gears was enough. The city guard asked: if the old gate has already been removed, what about last night's grain carts? Knowing only how to install new mechanisms but not how to shut them down at any time still leaves the risk on the people.

So a bronze key was added beside each gate. The new mechanism was first used for a few gates and a few time periods; if jams occurred, the city guard could immediately switch back to the old winch; after several rounds of wind and rain, the scope was expanded.

The townspeople barely noticed the renovation process. The new mechanisms went from one gate to three gates, then to the whole city. Wherever a problem arose, it stopped right there—no need to tear down the entire city gate and start over.

The craftsman later admitted that what was truly clever was not the mechanism itself, but the key that let new things be enabled by scope, turned off at any time, and scaled up gradually. That way, changing the city would not bind everyone to a single bet.

Later, when the city built canals and replaced street lamps, the same approach was followed. New things were first kept within a controllable scope—a few people tried them, problems were rolled back, and only after stability was confirmed were they scaled up. What the common people saw was steady change; what the craftsmen got was real feedback. Renovation did not have to become an all-city gamble every time. The city guard later kept a record for every mechanism: when it was opened, who used it, when it was closed, and why it was expanded. Craftsmen could therefore test with confidence, and the common people were not forced to bear all the risk. The switch was small, yet it changed how the entire city renewed itself. Later, craftsmen were also more willing to deliver half-mature new mechanisms, because they knew half-mature would not directly fall on the whole city. This phrase was later written into the handbook for newcomers, reminding everyone to look at the on-site cost first before talking about saving effort. And because of this reminder, when similar problems arose later, people would not rush to apply old methods.

Reveal

This story is about: feature flags

Feature flags control whether a capability is enabled without redeploying code. They can be rolled out gradually by user, tenant, region, task type, model, tool, policy, or risk level.

In Agent products, it supports canary releases, gradual rollout, emergency shutdown, experiments, and customer-targeted enablement. But expired switches also need governance and cleanup, otherwise the system becomes increasingly difficult to judge real behavior.

Metaphor mapping

  • New gate mechanisms: new features, models, tools, or Agent behavior
  • You must tear down the door to close it: rollback difficulties caused by binding release and enablement
  • The small brass gate: Feature Flag / Feature Toggle
  • Switches by caravan and risk level: targeting and segmentation
  • Flip the copper switch: kill switch and rapid mitigation
  • Clearing old copper gates: feature flag lifecycle governance
  • Final insight: feature flags break deployment, enablement, experimentation, and emergency rollback into controllable actions

Andy Ren Xu's judgment

The practical value of this concept is that it helps you break "AI features that look smart" into deliverable, verifiable, and governable units of work.

Canary deploymentA/B testingrolloutkill switchsegmentationexperimentation
京ICP备2026014272号