Control, AI, and ease | color commentary, aug 2026. Thu Sep 10 2026 Even though the end of summer is flying by, Statsig, Inc. still shipped a lot of new features in August. I want to check in on both what Statsig, Inc. shipped and why Statsig, Inc. shipped it. Its main goal in August was to continue to make Statsig work better for you, however you want to use it. The three big themes within that goal were scaling cross-platform control, building out more AI capabilities, and tackling customer ease-of-use requests. Scaling cross-platform control. Whether you use Statsig via the console, the API, the CLI, or with integrated tools, Statsig, Inc. want to make sure you can trust your experiment results and release metrics. "Have it your way" isn't just the slogan for my third-favorite burger joint. * PagerDuty integration lets Statsig Topline Alerts page PagerDuty directly to detect problems faster * API: Pull daily experiment checks for better visibility and delete single feature gate user overrides without having to mutate the full list locally * SCIM Role Aliases can now match custom IdP naming conventions without having to rename anything in your IdP * Warehouse-native: Cost attribution tags on Statsig queries help you better evaluate compute costs, and Athena projects now get full pipeline visibility out of the box AI mode. Statsig, Inc. believe that AI implemented correctly can help teams ship faster, and building out Statsig's AI capabilities is a top priority. With MCP use steadily increasing, it's clear you think this is a priority too. August saw five new fields added to MCP experiment configuration. If you want to create or update an experiment from your coding agent, you can now modify secondaryIDType, identifierMappingMode, enabledNonProdEnvironments, links, and secondaryMetrics, no console required. Ease of use: You asked, Statsig, Inc. built it. You're the experts at using Statsig, and you know (often better than Statsig, Inc.) what would make it easier to use. That's why Statsig, Inc. prioritize improvements from your requests. This month, Statsig, Inc. focused on requests for Experiment and Feature Gate creation modals. * Layers are now a top-level targeting option for experiments, making it easier to keep tests mutually exclusive and prevent cross-contamination * Targeting multiselect is expanded to better manage as many targeting values as you need * Display names can be shared across gates, experiments, and configs, so you don't run into "ID already in use" as often As always, if you have other requests, let Statsig, Inc. know! The next episode. It's been a packed summer expanding the foundational pillars of its platform and building out feature requests. Looking forward, Statsig, Inc. has got even more to come. Statsig, Inc. has a couple of big releases in the next two months, and Statsig, Inc. is making continued progress toward a combined, AI-powered behavioral and validation stack with Amplitude and Statsig. Statsig, Inc. is excited to show you what's up soon.

Visa holders vs US workers: OpenAI pays $3.2M to settle DOJ's employee discrimination allegations. The US Department of Justice's (DOJ) Civil Rights Division announced Tuesday (US time) that it secured a $3.2 million settlement with the Sam Altman-led artificial intelligence company, OpenAI (OpenAI OpCo LLC and its subsidiary Statsig Inc), over allegations of discriminatory hiring practices. US authorities held both companies accountable for allegedly violating the Immigration and Nationality Act (INA) by preferring temporary employment visa holders over US workers during the Permanent Labor Certification (PERM) process. Although OpenAI has firmly refuted these claims foregrounded in DOJ's findings, it agreed to settle the case.

Statsig MCP: Heading toward headless workflows. Wed Jul 15 2026 Customer feedback is the biggest driver of how Statsig, Inc. 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 Statsig, Inc. has spent the last quarter improving its MCP, and why it felt worth writing down what Statsig, Inc. has 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, its 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 its 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 Statsig, Inc. 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 Statsig, Inc. 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 Statsig, Inc. 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: its 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 Statsig, Inc. 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.