Flagger.gg

Feature flags for AI coding agents

When agents write and ship most of the code, every change they make should land behind a flag, so a human or the agent can turn it off without a redeploy. Flagger.gg lets agents create, flip, roll out and kill flags through MCP, the CLI and the SDKs, using scoped agent tokens. Every change records which agent made it, in which run and why.

Updated

Why agents need flags

Coding agents such as Claude Code, Codex and Cursor now open, merge and deploy a large share of changes. Review can't catch everything at that pace, so the safety net has to move from "before merge" to "after deploy": ship the change switched off, turn it on for a few people, and turn it off at once if it misbehaves.

That only works if the agent itself can do the flag work: create the flag for the change it's making, wrap the new code in a check, move the flag through admins and targets, and kill it when a check fails. Flags designed for people clicking in a dashboard don't give agents that, or give them full admin power with no record of which agent did what.

The agent loop

  1. Create a flag for the change. The agent calls flag_create over MCP, or flagger create, with a summary of what changes for customers and a note on why. In auto-live mode a new flag starts on unless it carries a not-ready reason, so an agent shipping dark passes one; with approvals on, new flags start off.
  2. Ship behind it. The new code path sits behind flag("key", ctx) in Node or client.Enabled("key", sub) in Go, and merges to main.
  3. Widen it step by step. Admins, then named users or workspaces, then a percentage, then everyone, checking its work at each step with flag_eval.
  4. Kill or revert if checks fail. flag_kill turns it off for everyone; flag_revert rolls back to the previous state.

The run is taken from FLAGGER_RUN (or --run), so every step lands in the audit log under the same run:

flagger create search_v2 --summary "New search ranking" --not-ready "ranking not tuned yet" --note "ticket 412" --json
flagger set search_v2 admins --note "try on the team first" --json
flagger set search_v2 percent --percent 10 --note "admins look good" --json
flagger kill search_v2 --note "error rate up after 10%" --json

Guardrails for agents

  • Scoped agent tokens. Each agent gets its own flg_agent_… token for one project, a list of environments and the actions you pick: read, create, target, rollout, kill, request. Tokens expire after 90 days, are stored as hashes and can be revoked any time.
  • A note on every write. Agent writes without a note are refused. The run (from --run, FLAGGER_RUN or the MCP client) is recorded too.
  • Auto-live or approvals, per project. In auto-live mode (the default) agents' changes apply at once. With approvals on, agents in production can roll out up to a cap (10% by default); turning a flag on for everyone becomes a request a person approves in the Release console. There is no approve tool for agents.
  • Protected flags. Mark payments or sign-in flags protected and agents can only kill them.
  • Rate limits. 30 writes a minute per agent token; with approvals on, also 5 changes to one flag an hour. Kill is exempt.
  • Unknown means off. A typo in a flag key can't turn anything on.

Which agent did what, and why

Every change, by a person, an agent token, an admin token, a deploy's code registration or an import, writes an audit row with who, which run, the state and rules before and after, the client (console, CLI, MCP, API) and the note. The org audit log filters by agent, flag, run and person, and every filter is in the URL, so "everything the backend agent changed in run 1832" is one link.

How agents connect

  • MCP: hosted at mcp.flagger.gg (Streamable HTTP, the agent token as a bearer) or flagger mcp on stdio, with the same 11 tools. See the MCP server guide.
  • CLI: every command takes --json and prints one JSON object; errors are {"error":{"code","message"}}. Exit codes: 0 done, 2 waiting for approval, 1 error.
  • API: api.flagger.gg/v1 with the token as a bearer.

Step-by-step setup for Claude Code, Codex and Cursor is in this guide.

FAQ

How do AI coding agents use feature flags?

They create a flag for each change, ship the new code behind it switched off, widen it step by step while checking their work, and kill or revert it if something fails. With Flagger.gg they do this through MCP tools or the CLI with a scoped token.

Can an agent turn a feature on for everyone by itself?

In auto-live mode, yes, within its token's actions. With approvals on, an agent in production can go up to the rollout cap (10% by default), and anything wider becomes a request a person approves.

Can an agent approve its own change?

No. There is no approve tool and agent tokens can't approve. Approving is done by a person in the Release console or with a person's own flagger login.

How do I know which agent changed a flag?

Each agent has its own named token, and every change records the token, the run, the before and after, and the agent's note. Filter the audit log by agent, run or flag.

Which agents work with Flagger.gg?

Any MCP client, such as Claude Code, Codex and Cursor, and any agent that can run a shell command and read JSON.

Ship your next change behind a flag.

Sign up, add an SDK key to your app and give your agent a token.

Sign up