How to put your AI agent to work on feature flags with the Flagsmith CLI

Kim Gustyr

Before AI, one of the biggest friction points you would encounter when adopting feature flags was getting the SDK wired into your codebase: working out where it fits in your application's life cycle, what glue code your stack needs, how it behaves on startup.

That friction has largely gone. Tell a coding agent to integrate a feature flag SDK into your codebase today, and it works as expected ninety-nine times out of a hundred.

Now you can focus on the more interesting problem of actually managing the flags once you have set them up, which is why we built the Flagsmith CLI.

Let your agent build the flags, not just the code

As an agent can confidently manipulate your codebase to integrate a feature flagging SDK, it can just as confidently manage the other parts of the job:

Creating flags and naming them accurately
Writing accurate descriptions
Tagging them appropriately
Setting the correct type

Flagsmith supports standard and multivariate flags, and you can let the agent decide upfront whether a given feature needs a gradual rollout and create a multivariate flag accordingly.

On a completely new codebase, you can tell the agent it is a greenfield project with no feature flagging at all. Ask it to look at the code, factor out the features that can be toggled on and off and rolled out gradually, sprinkle the codebase with the integrated SDK, and create the corresponding flags, all in one pass. All that happens reliably with the CLI.

It's also worth developing the habit of asking your agent to add new features behind a flag as standard, creating the flag before it touches a single line of code. I'd argue that's good practice generally: get your flag names sorted before you start writing.

The same workflow also works for existing code. One of our co-founders, Kyle, shared a story recently about a user who had a project full of settings governed by environment variables. He converted the whole lot to feature flags with a single prompt, hooked the project up to Flagsmith without giving it much thought, and didn't lose any time doing it.

It works on codebases you don't own, too

Feature flags have become more accessible in open source.

If you're developing against an open-source project that relies on Flagsmith, you don't need to read up on how it uses flags before you can turn features on and off.

Clone the repository, tell your agent the codebase uses Flagsmith, and ask it to spin up a local Flagsmith instance and create a project containing every feature from that codebase. In my experience, the agent one-shots this: quickly, efficiently, and reliably, every time.

No command? The agent calls the API instead

Agents are trained on a huge volume of bash, so they're naturally inclined to compose tools by writing one-off scripts, and the CLI fits that instinct well.

We deliberately built a way for CLI users to consume our API using the credentials the CLI already stores. So if we haven't shipped an ergonomic command for a particular piece of functionality yet, it still works: our API documentation is public, and as it lives on GitHub, it's probably in the training data too.

An agent won't give up when a specific CLI command is missing; it will just call the API through the same CLI tool.

Machine authentication and the evaluate command

You can use the Flagsmith CLI in CI without having to store credentials as well, which basically gives you unlimited scripting opportunities.

The CLI's evaluate command turns a pipeline, or any piece of automation, into a Flagsmith client.

Add it to a pipeline step, and you've got a feature flag consumer without having to overthink the integration: rolling out new infrastructure gradually, or on a schedule, just involves writing a bash conditional around the flag's value.

None of that requires you to store long-lived credentials in your pipeline, either. We support machine authentication via OIDC, so a CI job can authenticate without a stored secret.

GitHub is currently the only OIDC provider we support by name, but we built the integration to be generic enough that most other OIDC providers should connect without much friction.

The barrier to adopting feature flags is genuinely that low.

Keeping an agent on a leash

Before you hand an agent access to your codebase and your feature flag platform, think about the blast radius.

Use role-based access control, available on our paid plans, to attach roles to the machine credentials an automation relies on, whether that's a static REST API key or OIDC, and you can govern exactly what the CLI can and cannot touch.

By default, using the CLI means using your own credentials, which are short-lived rather than persistent. The CLI stores them in the OS keychain on Linux and macOS, so they don't appear in commands or transcripts where an LLM could expose them. To access them, a bad actor would need to compromise the keychain itself.

Built to be understood by agents, not just humans

A tool that an AI doesn't understand well is a risk in itself: unintuitive commands and unclear failure states are exactly what send an agent into a loop or a dead end.

We designed the CLI with that problem in mind. Every error is stated clearly and comes with a recovery path or a concrete next step. Every command's help page carries well-tailored, handwritten examples, based on real use cases, that a human and an agent can read.

While we were iterating on early versions, we gave the CLI to agents with no additional context and watched how they used it. We corrected the command APIs based on what we saw, and the result turned out to be more intuitive for humans too—a pleasant side effect of building for agents first.

The goal throughout was to reduce the risk of an agent bloating its own context, getting stuck in a loop, or landing in a dead end it can't reason its way out of.

Those failure modes waste tokens and your time in roughly equal measure, so it was worth designing against them deliberately rather than patching them after.

Why we've bet on the CLI

We're a small, bootstrapped team, so we constantly have to think about where our engineering time actually pays off.

The CLI got the lion's share of it because it covers far more ground than an agent-only integration would. It's a general interface to Flagsmith for engineers who'd rather work in a terminal than a browser; it slots straight into CI/CD, and it makes things easy for AI agents.

Building one tool that serves all three uses felt like a better bet than building something more purpose-specific.

That versatility is also why the API escape hatch is so important. An agent, or a person, is never limited to the commands we've thought to write. Anything the CLI's credentials can authenticate against, you can use.

What's coming next

We're working on a skills catalog for the CLI, and I can tease a few of those planned:

The experimentation skill will help an agent analyse your project, work out which exposure and conversion events your business logic should be sending, and set up the metric and experiment needed to track the actual impact of your code.
The releaser skill will help teams adopt best practices for gradual, data-driven rollouts.
The enterprise feature skills will make things like RBAC more visible and usable by an agent, explaining what Flagsmith's permissions model offers so it can propose which roles your team is missing.

That's a taste of what we're aiming to ship before the end of the year. The CLI is open source, and if you find a rough edge or think of a use case we haven't, let us know on GitHub.