Feature flags are becoming the control plane for AI infrastructure

We are not just feature-flagging code anymore. We are feature-flagging infrastructure decisions.

That sounds like a small semantic upgrade until you watch an agent turn a reasonable request into a Terraform plan, a cloud API call, a pull request, and an incident ticket before anyone has finished their coffee.

The obvious response is to put a human approval in every workflow. It is also the response that guarantees people will route around the workflow the first time it becomes inconvenient. The more useful question is narrower: what is an agent allowed to do, right now, in this environment, for this change?

That is a control-plane question. Feature flags are surprisingly good at answering it.

CI gates were built for a slower world

The traditional infrastructure pipeline has a familiar shape: make a change, open a pull request, run a plan, collect approvals, apply. It is a good baseline. Terraform’s plan, for example, deliberately separates a proposed set of actions from applying it, so teams can inspect the effect before making the change. That distinction is still valuable.

But a pull request is a snapshot of intent, not a live decision system.

An agent can discover a noisy database, suggest a larger instance, update an IaC module, and prepare a rollout in minutes. Between the PR being approved and the apply running, the budget, incident state, deployment window, or model confidence may have changed. The decision needs to be evaluated at the moment of execution, with current context—not only at the moment somebody clicked approve.

That does not make code review obsolete. It makes code review insufficient as the sole safety mechanism for autonomous systems.

The flag is the policy boundary

Used this way, a flag is not new-checkout=true. It is a small, explicit policy decision that sits between an agent’s intention and an irreversible action.

For example:

agent.infrastructure.apply = false
agent.infrastructure.apply.nonprod = true
agent.infrastructure.multi_region = false
agent.infrastructure.database_resize.max_percent = 20

The agent can still investigate, generate plans, calculate costs, and open a review. The final executor checks the relevant policy before it can mutate anything. A production database resize is not authorized because the agent wrote convincing Terraform. It is authorized only when the policy service says this actor, this environment, and this proposed action are in bounds.

That is why I prefer calling these decision flags rather than sprinkling ordinary booleans through automation. The evaluation context matters: environment, account, change type, estimated cost, resource criticality, incident status, and maybe the identity of the agent or workflow. OpenFeature’s model is useful here because it standardizes flag evaluation behind a provider abstraction and lets callers pass context rather than hard-coding a particular vendor into every executor. Its evaluation API is deliberately built around that separation.

Three patterns worth stealing

1. Let agents propose before they execute

Start with a flag that controls capability, not just deployment exposure.

An agent may be allowed to create a Terraform plan in every environment, but only apply it automatically in a disposable sandbox. In staging it can apply only a narrow allowlist: a new queue consumer, perhaps, but not a database replacement. In production it creates a signed plan and waits for an explicit policy flip or human promotion.

This is much better than a global “AI on/off” switch. It lets a team learn where the agent is useful without granting it the keys to every account on day one.

The important implementation detail is that the executor owns the check. Do not trust the agent to remember that it is forbidden. The workflow, deployment controller, or cloud-facing service must evaluate the policy immediately before the sensitive action.

2. Canary the decision, not only the application

We know how to canary application code. The same idea works for infrastructure decisions.

Suppose an agent believes a cluster needs a new autoscaling policy. Let it apply the change first to one low-risk cluster, then to a small percentage of eligible production clusters, while you watch error rates, latency, and spend. If the metrics go ugly, turn the flag off and stop the next expansion.

This does not magically undo a bad infrastructure change. Rollback is harder when state, data, and cloud resources are involved. But it creates a boundary around the blast radius and gives you a fast way to stop making the situation worse.

AWS makes the distinction clear in its configuration products: Parameter Store is centralized configuration, but a parameter update has no validation, gradual rollout, or automatic revert. AWS AppConfig adds deployment strategies, validation, alarm monitoring, and rollback for configurations that need them. The documentation is worth reading as a warning against treating every key-value store as a safe flag platform.

3. Put cost behind a policy switch

The first truly autonomous infrastructure surprise is often not an outage. It is a bill.

An agent that can improve availability by adding replicas, enabling a larger SKU, or proposing multi-region failover will find plenty of technically valid ideas. The issue is that technically valid does not mean financially authorized.

Make cost-bearing actions explicit policies: allow multi-region only for a named service; cap automatic scaling changes at a percentage; require a live incident for temporary capacity expansion; deny expensive changes outside a deployment window. Then log the evaluation alongside the estimated impact and the eventual cloud action.

This turns a vague instruction—”be careful with cloud costs”—into something a system can actually enforce.

A flag is not a compliance costume

There is a bad version of this idea: a dashboard full of poorly named switches, mutable by half the company, with no expiry, no owner, and no way to tell why a change happened. That is not a control plane. It is a distributed permission leak with nicer UI.

If a flag authorizes infrastructure mutations, treat it as production policy:

1. Give it an owner and an expiry. Temporary autonomy should not quietly become permanent.
2. Evaluate it server-side at the last responsible moment. A client-side or early-pipeline check is advisory.
3. Use a fail-safe default. If the policy service is unavailable, an agent should usually propose rather than apply.
4. Record the decision. Keep the flag value, evaluation context, actor, plan digest, and resulting cloud action together.
5. Keep foundational controls separate. IAM, protected environments, budget alarms, policy-as-code, and change management remain necessary. A flag should narrow a capability, not replace identity or authorization.

That last point matters a lot in regulated environments. An audit trail saying “the feature flag was on” is not enough. You want to reconstruct: which policy version allowed which agent to apply which exact plan, under what conditions, and who changed that policy. The flag is a useful choke point precisely because it gives you one place to collect that evidence.

Build the boring version first

I would not begin with a grand autonomous-platform programme. Pick one reversible, expensive, or frequently debated action and put it behind a policy flag.

Maybe it is allowing an agent to restart non-production workers. Maybe it is permitting it to change a Kubernetes replica count within a tight band. Maybe it is an absolute production deny on destructive Terraform actions until a change window is active.

Make the state observable. Exercise the off switch. Deliberately deny a proposed action and make sure the system explains why. Then expand the scope only after the operational story is boring.

That is the point. AI infrastructure does not need a magical governance layer. It needs small, reliable decisions enforced where work actually happens. Feature flags already know how to change behaviour at runtime. Giving them the job of controlling agentic infrastructure is a natural evolution—as long as we are honest that a toggle is policy, not permission to stop thinking.

References

• OpenFeature Evaluation API
• Terraform plan command
• AWS Systems Manager Parameter Store and AWS AppConfig comparison

---

To test my projects, I use Railway. If you want $20 USD to get started, use this link.