Play · Developers and platform teams
Kill a runaway agent
Stop the loop,then stopthe agent.
An orchestrator that spawns workers can fan out faster than anyone can watch it, and killing one process does not stop the agent. Spawn and step limits catch the loop first, and Runtime's kill switch stops the agent from running, immediately.
30 minutes. No commitment.
SOC 2 Type II attested · ISO/IEC 27001:2022 certified · HIPAA with a BAA · aligned to the EU AI Act and NIST AI RMF
Who
A platform team running an orchestrator agent that spawns research workers, each with its own tool credentials.
What happened
A worker got stuck in a plan-and-retry loop and spawned more workers to share the work. By the time the on-call engineer found the right process to kill, the fleet had made thousands of calls.
What's at stake
Agents that fan out faster than anyone can watch, no single place to stop them, and no record of what actually ran.
- 01Observe
See the loop as it happens.
Every step of the orchestrator and every child it spawns lands as a run under the same session, with tokens, latency and cost per call. The executions list shows a run that has been going for forty minutes at step 300; open it and the trace shows the same tool called with the same arguments over and over. wax runs tail puts the same thing in the terminal.
parent and children in one session · wax runs tail · steps, cost, and duration per run
observe · executions
- 02Run
Limits first. One switch when they are not enough.
Under Runtime the workflow and its steps are decorated, so each child is a known run under the parent. A spawn limit puts a ceiling on concurrent spawns, so a worker cannot fan out in the first place, and a step limit suggested from run history ends a loop before anyone is paged. When a person has to step in, the kill switch stops the agent from running, immediately. The kill-switch policy can also trip on its own when an agent's error rate crosses a threshold.
kill switch · spawn limit · step limit from recommendations · error-rate circuit breaker
runtime · deployed agents
- 03Prove
The record says what stopped, and when.
The run carries the kill decision, who pressed it or which policy tripped it, and the step it stopped at. The post-incident review is a page in the product.
durable decision record · policy-linked · exportable
observe · blocked run detail
- spawn worker · research-worker-07research-orchestrator · run 9b2e · spawn limit 6 reachedblock
- web.fetch · same URL, 40th callresearch-worker-04 · step 212 · step limit 200 · from recommendationblock
- kill research-orchestrator · run 9b2ej.park · kill switch · agent stoppedblock
- run.start · after killresearch-orchestrator · kill switch active · run not startedblock
Illustrative entries in the shape the product writes them.
Products in this play
Because a process is one copy of the agent. A schedule or a signal starts it again, and the workers it spawned are separate runs. The kill switch stops the agent itself from running, and spawn and step limits keep a loop from fanning out in the first place.
Run this play this week.
Free for your first agents and devices, live in about thirty seconds. Or walk through it with someone who has run it before.
30 minutes. No commitment.
SOC 2 Type II attested · ISO/IEC 27001:2022 certified · HIPAA with a BAA · aligned to the EU AI Act and NIST AI RMF