Agents Need Feature Flags

Hello, everyone. I'm Sachin Gupta, and I'm a backend engineer. And today we are 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 keep 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 six flag types that agents specifically need.

I will show you two 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 just a small prompt leak, 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 four named incident in the last fourteen 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 Replit. This was day nine of a twelve-day wipe coding experiment. The agent did not follow the instructions and ended up deleting the production database and then fabricated over four thousand fake users to conceal what it had done.

The third one is LangChain. It had a four-agent pipeline, researcher, analyzer, verifier, and synthesizer, where two of them ran in continuous loop and costed forty-seven thousand dollars. The fourth one is Pocket OS, 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 prop 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, Unleash, Lift, or maybe your homegrown flag service. This is already a solved problem. The discipline is already there.

We just have to a-apply it. But now the problem is that web feature flags covers one thing, whether a feature is on or off. But agent has six behavior surfaces that a CRUD 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 six behavior surfaces that a CRUD 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, diffusion 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 tile you own.

Sub-agents. These are the spawn children inherited from the parent flags, or they should. Most system don't enforce it.

A boolean feature enable flag doesn't cover any of these. You need a taxonomy.

So here it is. Six type, one 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 back-end. 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 five percent 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 specific tools per user segment, per user type, per risk class. The tool exists in your code base. 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 SOX bill. Along the way, it prevents the usual broken tool shape, 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, fall back or canary without code changes. The high-cost segment gets the frontier model. The free trial gets the cheap first 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 four dimensions, and each of them are independent. The first one is retention. It could be session only, it could be thirty 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 dial you own. There are three 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 request respect the flag at the next decision point.

Third, the wiring exists from the agent design phase, not at 3 AM hot patch when something is on fire. Without one,

here is what you are going to get. First, LangChain. Second, Pocket OS. Third, Replit, and fourth is OpenClaude. 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 the right, 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 emails right 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 four-agent LangChain pipeline loop for eleven days and burned forty-seven thousand dollars. 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 four to eight. The agent enters a runway loop. The line climbs rapidly.

At T plus fifteen seconds, the rate guard fires a Slack alert. At T plus twenty twenty-two, I flip the agent to kill it. At T plus twenty twenty-six, 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. Thirty 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 three boxes. User on the left, a middleware layer in the middle, which resolve the flag, gets the tools, route the models, applies autonomy, and honor the kill switch, and the agent loop on the right 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 Unleash, Flip, LaunchDarkly, or maybe homegrown. You are not building a new one.

The critical architecture rule is on the call-out 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 call 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 one, kill switch first. Wire a single agent-wide kill switch and one per tool kill switch. Ship those before anything else.

The step two is wrap the tools. Every tool call resolve a flag before execution. Step three, stage autonomy. Default everything to Suggest, auto-approve per surface as you build trust.

Auto-execute is opt-in per tool. Step four is variant prompts. Move the system prompt out of the code and into a flag resolved config. Step five, watch the slope. What does watch actually mean?

Four numbers you should track from day one. These are on the right 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 zero. If you have more than two a week, then investigate. Rollback time to mitigation. Target is under five minutes for a kill switch and under thirty minutes for a prompt rollback.

If you are 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 two percent over baseline at five percent rollout, block the promotion.

Flag audit trail completeness, hundred percent 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 middle lay, uh, middleware into every spawn. Context drift flags. The user segment at turn one is tailed by turn twenty.

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 are 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 twelve 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 portion, it's a regulation.

EU AI Act, Moffatt 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 drilled. Six months later, a config migration broke the flag and the time you need it, it does not fire at all.

Flag sprawling. You have six hundred 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 variant 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, twenty twenty-six was all about adoption. Twenty twenty-seven is all about control. The number three, match the discipline to the blasted years. 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/awesome-agent-failures. Thank you very much.

I am Sachin Gupta. Thank you for watching.