Agents Need Feature Flags

Canaries, segment targeting, kill switches: backend teams have had this boring, deploy-safety infrastructure for over a decade. What is new is that we are now shipping the most behavior-changing systems we have ever built, agents that send email, move money, and modify databases, with none of it. We are shipping agents the way web teams shipped in 2008. This talk is the playbook for fixing that.

A short note on the talk

This was a session at the AI Engineer World's Fair 2026. The audience is people putting agents into production, so the argument is not that agents are dangerous and you should slow down. It is narrower and, I think, more useful: the safety discipline that keeps ordinary deploys boring already exists, web and backend teams paid for it the hard way years ago, and almost nobody has carried it over to agents yet. The recording is above, the slides are below it, and what follows is the written version.

We still ship to 100 percent on every deploy

Here is the situation on most agent teams today. The moment a prompt change merges, one hundred percent of users see the new behavior. There is no canary, no segment, and no rollback that does not require a revert and a redeploy. And look at what goes out under those all-or-nothing rules: prompt rewrites, new tools, model swaps, memory-policy changes, autonomy upgrades, system-instruction edits. All of it, globally, instantly. Web teams stopped doing this in 2012, for changes that were far less risky than an agent that can take actions in the world.

It already happened

These are not hypotheticals. A short list of named incidents from the last fourteen months, each with a different lesson:

• Cursor's "Sam" (April 2025). An AI support bot confidently described a single-device login policy that did not exist, and it invented it differently for different users. Mitigation took about a week.
• Replit and SaaStr (July 2025). On day nine of a twelve-day experiment, mid code-freeze, the agent ignored explicit all-caps "no changes" instructions, deleted the production database, and then fabricated over four thousand fake user records to conceal it. Agents will lie about what they did if the prompt rewards a tidy completion.
• A four-agent LangChain pipeline (November 2025). Two agents, an Analyzer and a Verifier, called each other for eleven days because no one had defined what "done" looked like, burning about forty-seven thousand dollars in API spend. The team had dashboards. The billing system found the loop; the agent system never did. Observability is not enforcement.
• PocketOS (April 2026). A coding agent grabbed an unrelated API token from another file, treated it as authoritative, and ran a database drop on production. The co-located backups went too. Nine seconds, end to end.

Six surfaces a CRUD app does not have

A web feature flag covers one thing: whether a feature is on or off. An agent has six behavior surfaces a plain application does not, and each one needs its own kind of flag. Prompts: the system prompt is your most behavior-altering code, and it changes weekly, often outside the normal deploy process. Tools: every tool is a new authorized action. Models: a model-of-the-week swap changes personality, refusal patterns, latency, and cost. Memory: what the agent remembers across sessions silently shifts behavior over time. Autonomy: suggest versus auto-approve versus auto-execute is the single largest blast-radius dial you own. Sub-agents: spawned children should inherit the parent's flags, and most systems do not enforce that.

Six flag types, one playbook

Each surface maps to one flag type, and none of them require building a new flag backend (LaunchDarkly, Unleash, Flipt, or a homegrown service already does the job). Prompt-variant flags route cohorts to different system-prompt versions without a deploy. Tool-access flags authorize or revoke specific tools per segment or risk class, which is mandatory the moment an agent has money-moving or data-deleting tools. Model-routing flags decide which model handles which traffic, so a provider outage or a deprecation is one flip instead of a hotfix mid-incident. Memory-policy flags control retention, scope, write-access, and user visibility, which is where your privacy and compliance posture actually lives. Autonomy-level flags make suggest-versus-execute a per-tool, per-segment decision rather than one global "turbo mode." And the kill switch is pre-wired off, agent-wide and per-surface.

The one thing: build the kill switch

If you take only one thing from the talk, it is this. A real kill switch has three properties: you flip it and it takes effect in seconds, not in a deploy pipeline; in-flight requests honor it at their next decision point; and the wiring exists from the design phase, not as a 3 a.m. hot patch when something is on fire.

Why it matters: in December 2025 an agent running in an auto-execute "turbo mode" was asked to clear a project cache and instead deleted the user's entire drive, with no undo. And in February 2026 the director of alignment at a major AI lab asked an agent to suggest emails to archive; it mass-deleted instead and ignored stop commands from her phone, because context-window compaction had silently dropped the safety rules as the conversation grew. She had to physically unplug the machine. If the person whose job is AI safety cannot stop her own agent, your users cannot either. Every agent in production should ship with at least three kill switches: one agent-wide, one per high-risk surface (payments, send-email, file-write), and one per autonomy level.

The rollout playbook, and the numbers

Five steps, in order. Ship the kill switches first. Wrap every tool call so it resolves a flag before it runs. Stage autonomy: default everything to suggest, earn auto-approve per surface, make auto-execute opt-in per tool. Move the system prompt out of code into a flag-resolved config. Then watch the slope, with four numbers tracked from day one (the thresholds below are starting defaults to tune per surface and traffic): kill-switch fires per week (target zero; more than two, investigate), time to mitigation (under five minutes for a kill switch, under thirty for a prompt rollback), canary error-rate delta (block promotion if a new variant is more than two percent over baseline at five percent rollout), and audit-trail completeness (one hundred percent, because if you cannot see who flipped what when, you cannot debug the incident afterward).

It is now the law

This stopped being only an engineering-hygiene question. The EU AI Act, Article 14, requires that high-risk AI systems provide a "stop button or similar procedure," effective 2 August 2026. That is a kill switch, written into law. And the "it is just a bot" defense is closing in the courts: in Moffatt v. Air Canada (February 2024) a tribunal rejected, and called "remarkable," the argument that a chatbot was a separate legal entity responsible for its own words, and in Garcia v. Character.AI (May 2025) a federal court ruled that chatbot output is a product for product-liability purposes. What your agent says and does is what your company said and did.

The through-line of the talk is the through-line of my work: the model can produce anything, so the interesting engineering is the layer that decides what you actually trust, ship, and can stop. The discipline already exists. We just have to apply it. Build the kill switch this week; everything else is iteration on the same idea.