Published in partnership by Agents Stack and RuntimeAI. Adapted from an article first published by RuntimeAI on September 25, 2026.
A kill switch that can only stop one agent at a time is the wrong shape for an incident that involves more than one agent.
Most real incidents do. A shared upstream dependency starts misbehaving. A policy has to change across a whole product line. A security review calls for a precautionary stop. None of those arrive as a single agent ID.
At RuntimeAI we run three separate public-facing AI chat agents across our own sites: one on our main site, one on our CRM product's site, and one on a sister product's site. Each has its own identity, its own tenant boundary and its own audit trail. That is the right way to run them day to day.
It also raised an obvious operational question. If something goes wrong across all three at once, do we want to issue three separate kill commands, one at a time, and hope we did not miss a fourth?
That question is why we built catalog-scoped kill switches. Any group of agents you have already defined can now be stopped together, with the same single signed action you would use to stop one.
The kill switch already worked. The grouping did not exist yet.
RuntimeAI's kill switch has always supported three scopes: a single agent, an entire tenant, or global. All three are live and proven. What was missing was the scope in between: a named, curated set of agents that is not everything on the tenant and not just one agent.
The building block was already there. The Governed Entity Catalog lets a tenant define its own groupings, called blueprints, and link real agents into them. Until now the catalog was descriptive. Grouping agents helped you see them together, but it did not change how they were governed.
One connection, not a new enforcement engine
A catalog-scope kill switch does not add new plumbing. It fans one KILL or LIFT call out to every agent in the group, using the per-agent enforcement path that already exists. The signal is the same, and so is the audit trail. The only missing piece was the grouping.
Proven on three live website agents
We did not test this against a synthetic fixture. We registered our own three running public-website bots under one governed group and ran the demo in both directions.
- Precision. Kill one bot by name. The other two, on the same tenant, keep answering real chat messages without interruption. Grouping agents for convenience never has to mean losing the ability to act on just one.
- Group stop. One call that targets the group instead of an individual agent. All three bots stop responding at once. One call to resume, and all three are answering again within seconds.
1 API call to stop an entire named group of agents.
3 real agents in the live proof, each still independently addressable.
0 new enforcement engines, because it is the same kill switch fanned out.
Every member of a group kill still gets its own result. If one agent in a group of ten fails to stop, that failure is reported by name instead of being hidden behind a blanket success. A group action is still an auditable set of individual actions.
Why this matters beyond three bots
None of this is specific to website chat widgets. Any real deployment of AI agents ends up with natural groupings:
- a product line's agents
- a region's agents
- every agent built on a given model version
- every agent touching a given data class
Once you can name a group, you can govern it as one blast-radius unit, with the same policy, kill switch and audit trail. You no longer hand-maintain a list of agent IDs every time something has to change for all of them.
That is the shift: from a kill switch per agent to a kill switch per group you define, while keeping the precision to act on one agent when that is all the situation calls for.
The Agents Stack view: containment is a governance question
For a CISO or a risk committee, the useful question is not whether a kill switch exists. It is whether you can stop the right set of agents, prove what was stopped, and bring them back in a controlled way.
Three things are worth settling before an incident forces them:
- Define the groups before you need them. Product line, region, model version and data class are the natural cuts. Decide them alongside your agent inventory, not during the incident call.
- Decide who can pull which switch. A group stop takes more agents offline than a single-agent stop. It needs a named owner, an approval path and a matching path to resume.
- Treat the per-agent results as evidence. A stop that reports each agent by name gives your incident record and your regulator something concrete. A blanket success message does not.
Agents Stack works with RuntimeAI to bring runtime controls like this into enterprise AI governance programs.
