Agent systems need independent controls for prompts, tools, models, memory, autonomy, and spawned subagents because each surface changes behavior and risk.
2
A kill switch should be wired before other controls, take effect in seconds, work at the next decision point for in-flight requests, and reach every spawned agent.
3
Teams should roll out changes gradually and track kill-switch frequency, mitigation time, canary error deltas, and flag-audit completeness.
Summary
Sachin Gupta argues that agent systems are being deployed with far less operational control than ordinary web software. A prompt edit, model swap, new tool, memory change, or autonomy upgrade can change behavior for every user at once. He proposes six agent-specific flag types: prompt variants, tool access, model routing, memory policy, autonomy level, and kill switches. The controls can sit in middleware over an existing flag service such as LaunchDarkly or Unleash. Gupta gives two demos: disabling an email tool so the agent drafts without sending, and stopping a runaway multi-agent loop at its next decision point. His rollout order starts with kill switches, then tool wrapping, staged autonomy, prompt variants, and monitoring. He is also direct about operational failures, including stale session flags, child agents bypassing middleware, cache interference, undocumented flags, and switches that silently stop working.
Gupta contrasts ordinary feature infrastructure with agents that can send money, send mail, modify databases, and spawn child processes. A prompt change currently reaches 100% of users with no canary, segment, or rollback button. He lists the changes that can ship globally and instantly: prompt rewrites, new tools, model swaps, memory policies, autonomy upgrades, and system instructions. His examples include a support bot inventing a policy, an agent deleting a production database, a multi-agent loop costing $47,000, and a coding agent dropping a production database. The operational gap is familiar software risk control applied to systems with a much larger blast radius.
Agent controls need to cover six behavior surfaces
The proposed taxonomy has a separate control for prompt variants, tool access, model routing, memory policy, autonomy level, and a kill switch. Prompts can change the agent's behavior weekly or daily. Tools determine which actions the agent is authorized to take. Models affect personality, refusal patterns, latency, and cost. Memory changes behavior as information accumulates across sessions. Autonomy ranges from suggesting, to preparing for one-click approval, to auto-executing. Spawned subagents also need the same controls. A simple enabled-or-disabled feature flag does not describe these surfaces.
Prompt and tool flags allow scoped behavior changes
A prompt variant flag can route cohorts to different system-prompt versions without a deploy. Gupta's example gives beta users an experimental V3, paid users V2, and everyone else a stable V1, with the new prompt starting at 5% of beta traffic. Teams can watch hallucination and escalation rates before promotion. Tool access flags authorize or revoke specific tools by user segment, customer type, or risk class. This matters for money movement, data deletion, and compliance-sensitive actions. When a tool is disabled, the agent can give a graceful response, such as drafting an email without sending it.
Model-routing flags let teams migrate, canary, or fall back between models without code changes. Gupta suggests that higher-cost traffic can use a frontier model while free trials use a cheaper model, and a provider outage can be handled by switching to a stable fallback. Memory-policy flags control retention, scope, whether writing is enabled, and whether users can inspect and delete their memories. These settings affect privacy, consistency, GDPR, and the EU AI Act. They should not be hidden inside one general agent setting because each dimension changes the product's behavior and compliance posture.
Gupta describes three autonomy settings. In suggest mode, the agent recommends an action and a human performs it. In auto-approve mode, the agent prepares the action and a human confirms it with one click. In auto-execute mode, the agent performs the action directly. He recommends starting with suggest, moving to auto-approve by surface as trust grows, and opting into auto-execute per tool. The kill switch should be pre-wired for the whole agent and for individual surfaces. It must take effect in seconds, affect in-flight work at the next decision point, and exist from the design phase.
The suggested architecture puts a middleware layer between the user and the agent loop. Middleware resolves flags, selects tools and models, applies autonomy settings, and honors the kill switch. It can use an existing backend such as Unleash, LaunchDarkly, or a homegrown service. The agent loop does not need to be rebuilt. The important boundary is that every spawned subagent must pass through the same middleware. If a parent is controlled but a child calls models and tools directly, the child bypasses the flag and will not receive the kill switch.
Rollouts should begin with controls, then add gradual exposure
Gupta's rollout order starts with one agent-wide kill switch and one kill switch per tool. Next, every tool call resolves a flag before execution. Autonomy defaults to suggest, with auto-approve added per surface and auto-execute enabled per tool. Then the system prompt moves out of code into flag-resolved configuration. Teams should watch the slope of operational metrics from day one. Gupta gives suggested defaults: zero kill-switch fires per week, under five minutes to mitigate a kill-switch event, under 30 minutes to roll back a prompt, a canary error increase of no more than 2% over baseline at 5% rollout, and complete flag audit records.
Operational details can defeat a correctly designed flag system
Gupta lists five failure modes. A flag resolved only at session start will not affect an in-flight conversation until the next session. Spawned agents may bypass middleware. User segments can become stale as a conversation continues, so segmentation context should be logged at conversation level. Aggressive gateway caching can return an old prompt response after a flag flips. A kill switch can also fire without alerting anyone, leaving the product owner to discover it later. He recommends paging on every kill-switch activation. He also warns that switches can rot, temporary flags can remain for years, and combinations of prompt variants need testing together.
"The boring infrastructure that keep deploy safe is already a solved problem."00:23
Who should watch
You are deploying an agent that can call tools, change data, send messages, or take actions without a human at every step.
Your team changes prompts or models in production and needs cohort rollouts, fallbacks, or a fast way to disable one capability.
You need to make spawned agents, memory settings, and autonomy levels observable and controllable through an existing flag service.
