Who flipped the flag
After a drop in sign-ups the product lead asks what changed. Memtro reads the audit log and finds the new onboarding gate was disabled at 15:20 on Thursday by Dan Fletcher, an hour before the drop began.
Ask Statsig who turned a feature gate off, and how an experiment is going.
Connect Statsig with a Console API key and Memtro reads feature gates with their rules and owners, experiments, and the project's audit log of who changed what. Staff email addresses and the user ids in targeting rules are never read. It reads on demand and there is no hourly sync. When you ask, and once an administrator has granted the action by name, it can create tags and gates, enable, disable or launch a gate, which every user feels at once, and create, start or decide experiments. Deciding an experiment or deleting a gate cannot be undone.
Ask in plain English from chat, your editor, a scheduled job or your own agent. The model picks the right Statsig tool, reads what it needs, and answers with the source cited.
These tools change something in Statsig. The model is told to use them only when you ask for exactly that, and an administrator grants each one by name to the teams that may use it; a personal connection acts only after its owner allows it.
Turn events on in the connection's Events tab on the Connections page, then add the address it shows as a webhook in Statsig, choosing the same kinds; the tab shows Statsig's own steps. Each event can start a job, with the event as its input. Statsig signs every delivery, and one whose signature does not check out is refused before it is read.
Events and webhooksOnce Statsig is connected, these are the kinds of things people ask. Plain questions, no syntax. If the answer lives partly in another system you have connected, Memtro looks there too.
Who turned the new checkout gate off, and when?
Which feature gates are stale?
How is the onboarding experiment going, and what are its metrics?
What changed in Statsig in the hour before the incident?
Disable the new checkout gate now
After a drop in sign-ups the product lead asks what changed. Memtro reads the audit log and finds the new onboarding gate was disabled at 15:20 on Thursday by Dan Fletcher, an hour before the drop began.
Checkout errors spike at Acme just after a release and Priya Sharma asks Memtro to turn the new payment flow off. Memtro disables the new checkout gate, so it fails for every user at once and they fall back to the old flow, then shows her who last changed it.
The teams that lean on Statsig most, a question each of them asks, and what they connect beside it.
A record in Statsig is rarely the whole story. Connect the systems that hold the rest and Memtro checks them together, then remembers what it learned so the next question starts further along.
Using something else for the same job, or both? Each connector has its own tools; connect as many as you like.
In console.statsig.com open Project Settings → API Keys and generate a Console API key, not a server or client SDK key
A read-only key is enough unless Memtro should change gates, experiments or tags
Copy the key, then in Memtro open Connections → Statsig, paste the Console API key and connect
Ask who changed the checkout gate this week
Chat in the dashboard, the OpenAI-compatible API, scheduled jobs, and any MCP client: Claude Code, OpenCode, Cursor, Claude Desktop. The Statsig tools are the same everywhere.
Only when you ask, and only what it has been granted: create a tag; rename or redescribe a tag; create a feature gate (passes nobody until it has rules); enable a feature gate (users see it at once); disable a feature gate (users lose it at once); launch a feature gate to everyone; archive a feature gate; delete a feature gate (permanent); force named user ids to pass or fail a gate; create an experiment in setup; start an experiment (assigns real users); finish an experiment by shipping one group; archive an experiment. Every other tool reads, searches or lists. The Connections page labels the tools that act, an administrator grants each one by name to the teams that may use it, and a personal connection acts only after its owner allows it.
A personal connection serves only your own requests. A shared connection serves the organisation: everyone, or only the teams an admin chooses. Admins can always add shared connections; other members need the permission.
Credentials are encrypted at rest. Tool results are cached briefly so agent loops do not repeat identical calls, and the facts the model extracts are saved to your organisation's memory with provenance (system, record and link) so they can be checked and superseded.
Console API key. In console.statsig.com open Project Settings → API Keys and generate a Console API key, not a server or client SDK key.
Yes. Turn events on in the connection's Events tab on the Connections page, then add the address it shows as a webhook in Statsig, choosing the same kinds; the tab shows Statsig's own steps. A job set to start "When an event arrives" then runs once for each matching event, with the event as its input. The run treats the event as outside data, never as instructions, and anything the run remembers is kept as unverified.
Seven-day free trial, then one monthly price per organisation. Connectors, jobs and memory are never metered.
Sign in, add a provider key, create an API key and point your tools at Memtro. It takes about five minutes.
7-day free trial · card on file, nothing charged until it ends · cancel any time