Human approval for AI agent flag changes
Let agents make small, reversible production changes on their own and send anything wide to a person. In Flagger.gg, turn approvals on for a project: agents in production can still create flags, target users, kill and roll out up to a cap (10% by default), but going wider or turning a flag on for everyone becomes a request a person approves in the Release console or with flagger approve. Agents have no way to approve, and kill never waits.
Updated
Why approve some agent changes, not all
An approval step on every change turns a person into a bottleneck for agents that ship many small changes a day. No approval at all means an agent can turn a half-finished feature on for every customer. The middle ground is to judge each change by how many users it reaches: showing a feature to admins, a few named users or a small percentage is cheap to undo, while turning it on for everyone is not.
Flagger.gg makes that call per project, with one switch in the project's settings.
Auto-live mode and approvals mode
- Auto-live (the default). Agents' changes apply at once, within their token's actions. New flags start on unless they carry a not-ready reason. Protected flags still refuse agents except kill.
- Approvals on. New flags start off. People and admin tokens can do anything. Agents in development can do anything but touch protected flags. Agents in production work up to a cap, set per environment (10% by default), and wider changes become requests.
Switching modes never changes the state of an existing flag.
What an agent can do in production with approvals on
| Change by an agent | Result |
|---|---|
| Create a flag, edit its description, summary or owner | Applied |
off, kill, admins, targets, target edits | Applied |
percent up to the cap | Applied |
percent above the cap, on, bulk on, a revert to something wider than the cap | Request for a person |
| Anything but kill on a protected flag | Request for a person |
| Archive, protect, change policy or tokens, approve | Refused (403 forbidden) |
Reach decides. off, admins and targets count as 0%, percent as its share and on as 100%. A change needs approval only when it is wider than the cap and wider than the flag is now, so making a flag safer always applies: an agent can take a flag from 50% to 20% with a cap of 10%.
With approvals on, an agent token can also change one flag at most 5 times an hour, on top of its 30 writes a minute. Kill is exempt from both.
What the agent sees when a change needs approval
- API:
202withstatus: "pending_approval", therequest, and aurlto the request's page in the console. - MCP: the same answer as a normal tool result, not an error, so the agent can report the link and move on.
requests_listandrequest_getshow where it stands. - CLI: exit code 2.
flagger request <id> --wait --timeout 30mwaits until a person decides.
The token needs the request action to file requests; without it the change fails with 403 needs_approval. A new request for the same flag and environment replaces the older pending one, and a request no one decides expires after 72 hours.
A line for your agent's instructions: "If a flag change returns pending_approval, stop and report the request URL; never retry it."
How a person approves
- Open the Release console. Pending requests are listed under "Waiting for you", and each has its own page with the change, who asked, the run and the note.
- Approve or decline, one at a time or in bulk. From a terminal, a person signed in with
flagger logincan runflagger approve <id>orflagger decline <id>. - Approval applies the change in one transaction and records it in the flag's history and the audit log with the request id.
If the flag changed after the request was made, approving fails as stale, so no one approves a change against a state they didn't see. Pass --force to approve it anyway.
How other flag services handle approval
LaunchDarkly has review-style approvals for flag changes, modelled on pull request reviews. Reviewers are alerted by email, in the app, and in Slack or Microsoft Teams. Requiring approvals is on select plans, and Enterprise customers can require them per environment (LaunchDarkly's approvals docs, checked 2026-11-02). Its workflow is more general than Flagger.gg's: people review people's changes too, with notifications in the tools a team already uses. Flagger.gg's approvals are built around agents: a rollout cap per environment, a change judged by how far it reaches, and no approve path for any agent.
FAQ
How do I require human approval before an AI agent changes production?
Turn approvals on in the project's settings. Agents in production can then roll out up to the cap (10% by default) on their own, and turning a flag on for everyone, or going past the cap, becomes a request a person approves.
Can an AI agent approve its own feature flag change?
No. Only a person can approve, in the console or with a flagger login user token. There is no approve tool in MCP, and agent and admin tokens can't approve.
Does an agent need approval to kill a flag?
No. Kill always applies at once, on protected flags too, and isn't rate-limited, so an agent can stop a bad release without waiting for anyone.
Can I change the rollout cap?
Yes. The cap is set per environment in the project's settings. Production starts at 10% and development at 100%.
What happens to a request no one answers?
It expires after 72 hours and the flag stays as it was. A newer request for the same flag replaces it sooner.
Ship your next change behind a flag.
Sign up, add an SDK key to your app and give your agent a token.