Agents Need Feature Flags - Sachin Gupta

Hello everyone, I'm Sachin Gupta, and I'm a backend engineer, and today we're going to talk about agent-need feature flags. If you have been a backend engineer for any length of time, you already know these tools, things like canaries, segment targeting, kill switches.

Your craft has had them for over a decade, and none of them is new. The boring infrastructure that keeps deploys safe is already a solved problem. What is new is that we are shipping the most behavior-changing systems we have ever built: agents that send money, agent that send mail, agent that modify databases, agent that spawn child processes, and we are shipping them with none of that infrastructure.

We are shipping them the way web team used to ship in 2008. Over the next few minutes, here is the plan: I will walk you through with the 6 flag types that agents specifically need. I will show you 2 live demo storyboards.

The first is flipping a tool mid-conversation. The second is stopping a runaway agent mid-sentence. Then I will cover a rollout playbook with the numbers your team should track from day one. Let's go.

Here is the situation today. The moment your prompt change merges, 100% of your users see the new behavior. There is no canary, no segment, and no rollback button. Look at what goes out under those small all-or-nothing rules. We get prompt rewrite, new tool addition, model swapping, memory policy changes, autonomy upgrades, system instruction edits, and we get all of it globally and instantly.

Web teams stopped doing this back in 2012, and they stopped doing it for changes that were less risky than this. The story that you actually hear from teams, almost word for word, is that it's just a small pront tweak, maybe broke a couple of a chunk of users, and then finally people are finding it out on Discord links or TikToks or maybe another social media platform.

So that is the failure mode this entire talk is built around, and let me show you that it is not hypothetical.

These are the 4 named incident in the last 14 months. The first one we have is Cursor Sam. That happened in April of 2025, where the support bot confidently told users about a policy that never existed. The second one we have is Replet.

This was day 9 of a 12-day vibe coding experiment. The agent did not follow the instructions and ended up deleting the production database, and then fabricated over 4,000 fake users to conceal what it had done. The third one is LangChain.

It had a 4-agent pipeline: researcher, analyzer, verifier, and synthesizer, where 2 of them ran in continuous loop and costed $47,000. The fourth one is PocketOS, where a developer was using Cursor and Claude. The AI coding agent grabbed an unrelated API token from another file, treated it as authoritative, and ran a railway GraphQL drop on the production database.

On the bottom left you will see the sources that I used to cite it.

Web engineers learned this lesson a decade ago: canary releases. You ship to a few percentage of users, you watch the metrics. If it works, you expand. If it doesn't, then you roll back. Segment targeting: different behavior for different type of users.

Kill switches: pre-wired off toggles that take effect in seconds, not in deploy cycles. Rollout monitoring: every change has its own error rate dashboard. None of this is new. The tooling already exists, like LaunchDarkly, UnleashLift, or maybe your homegrown flag service.

This is already a solved problem. The discipline is already there. We just have to apply it. But now the problem is that web feature flags covers one thing: whether a feature is on or off. But agent has 6 behavior surfaces that a cred app does not have, and each one needs its own kind of flag.

And in the next slide we are going to see that. These are the 6 behavior surfaces that a cred app does not have. First one is prompts. The system prompt is your most behavior-altering code. It changes weekly, sometimes daily, often outside your normal deploy processes.

Tools: every tool the agent can call is a new authorized action. Tools comes and go faster than features ever did. Models: model of the week swap change personality, refusal patterns, latency, and cost, sometimes in subtle way you won't even notice for days.

Memory: what the agent remember across session silently changes behavior over time. The same prompt reduces different output for the same user as memory accumulates. Autonomy: suggest versus auto-approve versus auto-execute. The single largest blast radius style you own. Sub-agents: these are the spawn children inherited from the parent flags, or they should.

Most systems don't enforce it. A boolean feature enabled flag doesn't cover any of these. You need a taxonomy.

So here it is. 6 type, 1 for each surface. Prompt variant, tool access, model routing, memory policy, autonomy level, and the kill switch. Each one maps to a behavior surface. None of them require building a new flag backend.

Let me walk through them fast.

Prompt variant flags route different users to a different system prompt version on the fly without a deploy. Look at the example. The beta cohort get experimental v3, which is concise and action-first. Paid tier gets v2, which is warm and expensive.

Everyone else gets v1, which is stable and well-tested. Cursor Sam is what happens without this. There was no controlled variant, just one model doing its best. It got things wrong differently for each user. With the prompt variant flag, you roll the new prompt to 5% of beta traffic.

You watch the hallucination rate, you watch the escalation rate, and then you promote when it holds.

Tool access flags authorize or revoke specified tools per user segment, per user type, per risk class. The tool exists in your codebase. Whether the agent can call it, it is the flag. This is mandatory when your agent has money-moving tools, data-deleting tools, or compliance-sensitive tools.

You scope per customer tier, or you pay the AML or SOCs bill. Along the way, it prevents the usual broken tool ship: the prompt plus send email, mass mail incident, and the beta tool that leaks to prod users through coding drift, uh, through config drift.

Model routing flag decide which model handles which traffic. They let you migrate fallback or canary without code changes. The high-cost segment gets the frontier model. The free trial gets the cheapest model. And on an incident, one flip puts you to a stable fallback.

The lesson is extremely simple. On the day a provider deprecates a model, or pulls one for safety, or has a multi-hour outage, a model routing flag is the difference between flipping a switch and shipping a hotfix in the middle of an incident.

If your production system has a hard dependency on one model from one provider, and it does not have any routing flag, no fallback, you are one provider outage away from a complete agent outage, or maybe one deprecation notice and everything is gone.

Route your traffic, have a fallback, make it a flag.

Memory policy flag controls what the agent remember across sessions. These are 4 dimensions, and each of them are independent. The first one is retention. It could be session-only, it could be 30 days, or forever. Scope: it could be per user, per tenant, or maybe global.

Write enabled: whether the agent can persist memory for this segment at all or not. User visible: whether the user can inspect and delete their own. They all look small, but they are not. The privacy posture of your product lives here.

The consistency of your agent behavior lives here. Your compliance story with GDPR and EU AI Act lives here. Autonomy level flags. This is the single biggest blast radius DALL·E own. There are 3 settings: suggest, where the agent recommend, and a human acts.

Auto-approve, where the agent prepares and a human one-click confirms. And auto-execute, where the agent just does it. The kill switch: pre-wired off. Agent-wide and per surface. It does not require any deployment, does not require any start, does not require any code changes.

Three properties that make a kill switch a real kill switch. First, you flip it and the change takes effect in seconds, not in a deployment pipeline. Second, in-flight requests respect the flag at the next decision point. Third, the wiring exists from the agent design phase, not at 3:00 a.m.

hot patch when something is on fire. Without one, here is what you're going to get. First, LangChain. Second, PocketOS. Third, Replet. And fourth is OpenClaw. Now think if you had a kill switch. If you could just have terminated the operation in between, it would have changed the game altogether.

Okay, now is the time for the demo. The setup is basically: assume you are in the April 2025, where the Cursor Sam support bot is confidently citing a policy that is not present. So the way we think we can fix it is with the tool access flag.

On the left you see we are having a conversation, on theright the fix. So the moment we switch off this flag, it will say it's disabled it at this time by this person, this is the scope, this is what it applies, and these are the active sessions.

The moment the flag is flipped, you will see that instead of citing a wrong policy, it is saying, "I can draft this for you, but I'm not able to send emailsright now. Want me to copy the draft into your clipboard instead."

Now this is a graceful error. Instead of giving me the wrong details, it is telling me that it cannot perform the operation. Now the money shot. The setup here is: it's November 2025, a 4-agent LangChain pipeline looped for 11 days and burned $47,000.

The agent system never noticed. The billing dashboard tripped the threshold. The chart on the left is tool calls per minute. This is an illustrative simulation. Baseline is 428. The agent enters a runway loop. The line climbs rapidly. At T plus 15 seconds, the RaidGuard fires a Slack alert.

At T plus 2022, I flip the agent to kill it. At T plus 2026, every in-flight agent process sees the flag at its next decision point. Each one emit a graceful shutdown. At T plus 30, the cost graph flattens.

30 seconds from problem to mitigation without any deployment, without any restart, without any code changes. No incident channel paging. And this is what you get with the kill switch. Now the question is where the flag layer is actually living.

If you see, this architecture is extremely simple. There are 3 boxes: user on the left, a middleware layer in the middle which resolves the flag, gets the tools, routes the models, applies autonomy, and honors the kill switch. And the agent loop on theright with model, tool, memory, and sub-agents.

The agent loop is unchanged from whatever you have today. Below the middleware is your flag backend, which is UnleashLift, LaunchDarkly, or maybe homegrown. You are not building a new one. The critical architecture rule is on the callout at the bottom of the slide.

Sub-agents must go through the same middleware. The biggest failure mode I see is a parent agent with flags properly applied that spawns a child agent. The child calls the model and the tools directly but bypass the middleware entirely.

The kill switch you just flipped never reaches it. So wire the middleware into every agent that is being spawned, not just at the entry point. So this is the rollout playbook. Five steps in exact order. Step 1: kill switch first.

Wire a single agent-wide kill switch and one per-tool kill switch. Ship those before anything else. The step 2 is wrap the tools. Every tool call resolves a flag before execution. Step 3: stage autonomy. Default everything to suggest. Auto-approve per surface as you build trust.

Auto-execute is opt-in per tool. Step 4 is variant prompts. Move the system prompt out of the code and into a flag-resolved config. Step 5: watch the slope. What does watch actually mean? Four numbers you should track from day one.

These are on theright side of the slide. The thresholds I'm about to give you are suggested defaults. Tune them as per your requirement, your surface, your severity, your traffic class. First one: kill switch fires per week. The target is 0.

If you have more than 2 a week, then investigate. Rollback time to mitigation: target is under 5 minutes for a kill switch and under 30 minutes for a prompt rollback. If you're slower, your mitigation doesn't fit inside a real incident window.

Canary error rate delta: if a new prompt variant error rate climbs more than 2% over baseline at 5% rollout, block the promotion. Flag audit trail completeness: 100% required. If you cannot audit who flipped, what is flipped, when it was flipped, then you cannot debug an incident in retrospective.

Five failure modes that I've watched play out at multiple teams. Flag resolved at session start, not per turn. Your kill switch actually fired, but in-flight conversation don't see it until the next session. Sub-agents bypass the middleware. This one we have already covered.

We need to make sure that we wire the middleware into every spawn. Context drift flags. The user segment at turn 1 is tailed by turn 20. Log the segmentation context at the conversation level. Caching: defeating the flip. Aggressive caching at your LLM gateway returns the old prompt response even after the flag is flipped.

No alert on kill switch fires. The switch goes off silently. The product owner finds out next week. Every kill switch fire is a page on its own. In this slide, what you're seeing is the two parts to the business case.

On the top half, the five questions every enterprise buyer will ask you in the next 12 months. Can you show me the kill switch? What's your rollout policy for prompt changes? How do you isolate beta features from production users?

When a model behaves badly for one cohort, how fast can you mitigate? Who can flip these flags, and is it audited? If you cannot demo all five, you are going to lose the deal. Flags are the demo. And on the bottom half, this is no longer just a sales question.

It's a regulation. EU AI Act, MoFAT versus Air Canada, Garcia versus Character.AI.

These are the four habits that actually defeat the whole point. Kill switches rot. They get wired on day one and then never trailed. Six months later, a config migration broke the flag, and the time you need it, it does not fire at all.

Flag scrolling. You have 600 flags, no documentation. Every flag is a hidden coupling between the unrelated systems. Every flag needs an owner and a removal date. The temporary flag. It is shipped for a rollout, it was never removed.

Five years later, it's somehow load-bearing. Kill it immediately after the rollout is done. Flag-driven prompt. It works that nobody tests a suite. Six prompt variants live in a production. Each individually works. Together they are a maze. Test the Cartesian product.

Now, these are the three things that you should remember. First one, and the most important one in my opinion: ship the kill switch first. If you do nothing else, give your agent one agent-wide kill switch and one per-tool kill switch.

They take effect in seconds. No deployment is needed. That single capability changes your operational posture more than any engineering team investment in this particular quarter. Second one is: treat the six surfaces independently and measure the slope. Prompts, tools, models, memory, autonomy, sub-agents.

Each one needs its own flag type. On top of the taxonomy, track the four numbers: kill switch fires per week, time to mitigation, canary deltas, and audit completeness. Remember, 2026 was all about adoption. 2027 is all about control.

Then number three: match the discipline to the blast radius. Your boring web app sits behind canaries and segments. Your agent can send email, move money, modify database, and spawn children. It deserves at least the same discipline, or probably more.

Thank you very much. Build the kill switch this week. Everything else is the iteration on the same idea. Every incident on this deck is sourced. The curated case studies are linked on the screen at github.com/vectra/awesomeagentfailures. Thank you very much.

I'm Sachin Gupta. Thank you for watching.