Products
Solutions
Resources
Customer feedback is the biggest driver of how we build Statsig. Lately, most of that feedback points to the same thing: teams want to use agents to work with Statsig.
Every month, more customers want to plug Statsig into Claude, Cursor, Copilot, or agents they’ve built themselves. They arrive with specific, thought-through asks: keys scoped the way their roles are scoped, review workflows their agents can participate in, API responses sized to fit a context window.
That feedback is why we’ve spent the last quarter improving our MCP, and why it felt worth writing down what we’ve learned.
In this post, I’ll walk through how I’ve seen the headless trend show up in customer requests, and how it now works for you to take a Statsig feature gate through its full lifecycle without opening a browser tab.
What customers actually asked for
I work closely on Statsig’s Console, which spans the UI, our public API, and the MCP server. My ticket queue has been signaling a clear shift: requests that used to be about the UI are now about tools and schemas. People increasingly want to work through MCP.
Looking back through the customer requests, two waves are easy to pick out.
The first wave was about reading. Over a few months, a string of enterprise customers (banks, marketplaces, consumer apps) asked some version of the same question: how do I give my AI tools safe access to Statsig?
Engineers wanted their coding assistants to answer questions like “Which experiments shipped last week?” and “Is this gate on for this user?” without leaving the editor
On-call responders wanted agents to reconstruct a config’s change history during an incident
Analysts who had never touched our API wanted the same thing through whatever chat interface they already lived in
The second wave was about writing. Once teams had agents reading their Statsig data, they started asking for agents that could act, and the requests were more conservative than I expected.
One customer is building automation where an agent sets up experiments end-to-end, from hypothesis to targeting to metrics
Another asked us to guarantee that their API automation obeys the same change-review requirements a human would face in the Console UI
None of them wanted a way around review. They wanted it extended to machines.
Feature gate lifecycle through MCP
Here’s what the shift actually looks like in practice. This scenario is a composite of workflows we see from customers today, using tools that are in production.
An engineer has a new checkout flow ready to go behind a flag. On Tuesday morning, instead of opening the Console UI, she asks the agent in her editor to set it up: a new feature gate, off by default, targeting internal employees first. The agent calls Create_Gate and reports back. The whole exchange takes less time than the Console UI’s login redirect, and the change is already in the audit log, attributed to her key.
The flow holds up in dogfooding, so on Wednesday, she asks for a 10% rollout. This is where it gets interesting, because her team requires review on production gate changes, and that policy applies to her agent, too. Rather than mutating the gate directly, the agent calls Create_Gate_Review with the proposed change and looks up who can approve it with Get_Gate_Eligible_Reviewers. Her teammate picks up the review, reads the diff, and approves it from his own tools, through the same MCP surface. The change commits, and the rollout starts.
I want to linger on that, because it’s the part we spent the most engineering effort on. The agent went through governance instead of routing around it. MCP enforces the same role checks as the Console UI. A read-only key can inspect a review but can’t approve one. If your org requires review for a change, an agent proposing that change lands in the same queue a human would.
Thursday is monitoring: our engineer asks how the gate is doing, the agent pulls Get_Gate_Results, and the numbers hold: exposures growing, error rates flat, checkout conversion slightly up. The ramp to 50% and then 100% goes through the same propose-review-commit loop, each step costing her a sentence.
By the following week, the feature is fully launched, and the flag is dead weight. She tells the agent to clean it up. It confirms the gate’s launch state and kicks off Start_Gate_Code_Cleanup to strip the stale flag checks out of the codebase.
One feature: gated, reviewed, ramped, measured, launched, and cleaned up. Console UI visits: zero. Audit gaps: also zero.
And like I said, this is all using tool calls that are in production. You can try this out yourself!
The Console UI is no longer the default
For a growing set of teams, the UI is becoming one client among several. It is the place you go for deep exploration, not the place every change has to start. Setting up a new feature gate is increasingly something users hand to an agent.
And the teams pushing us hardest are the ones building AI products themselves, using agents to run experiments on their agents. Their expectations pull the whole Statsig product forward: cleaner schemas, leaner responses, richer state, and guardrails that treat machine-initiated changes as first-class citizens.
Feature gates were always about closing the gap between deciding to ship and shipping. Wiring Statsig into your agents shrinks that gap even further. If you want to see for yourself, connect the Statsig MCP server to whatever assistant you already use and ask what shipped last week.