Your AI agent needs an off switch someone has actually tested
Pause, override and take back control should be rehearsed before go-live, not discovered mid-incident.
Pause, override and take back control should be rehearsed before go-live, not discovered mid-incident.
The button nobody has pressed
Most businesses running an AI agent can tell you how to start it. Fewer can tell you, without checking, how to stop it.
Ask the question in a team meeting and watch what happens. Someone says you can just turn it off. Someone else thinks the integration has its own kill setting. A third person points out the agent runs under a shared login, so revoking it would also break the reporting dashboard. Nobody is sure what happens to the twenty emails already queued, the half-finished CRM update, or the supplier order that was approved but not yet sent.
That is not an off switch. That is a guess.
And the guess gets tested at the worst possible moment: when the agent is doing something wrong, quickly, in front of customers.
Regulators are starting to ask the same question
This is no longer a niche engineering concern. On 3 October, Loughborough University's Vice-Chancellor, Professor Nick Jennings, signed an open letter to the UK Government on governing agentic AI. One of its practical asks is that public-sector agent contracts "provide a tested way for a person to pause, override or take back control."
The word that matters there is tested. The letter's technical annex goes further: people should be able to pause an agent, take back control and understand the state of a task at handover, and tests should check the speed, reliability and usability of that handover — including when the agent is failing or a connected service is down.
Two days later, New York City Council held a hearing on AI safety. The lead bill on the agenda would require AI models deployed in the city to have third-party validation and a way for a human to shut them down. It is a bill, not a law, and it is aimed at model providers rather than a twelve-person accounting firm. But the direction is clear. "Can a person stop this?" is becoming a standard question, not an edge case.
You do not need to wait for a rule to apply to you. If your agent can send, book, pay, update or delete, you already need the answer.
What a real off switch has to do
Pulling the plug sounds simple. In practice, stopping an agent well means four separate things.
Stop new actions. The agent should stop picking up new work immediately. Not at the end of the batch. Not after the current loop. Now.
Decide what happens to work in flight. Some half-done tasks are safer finished; some must be frozen. A drafted email is harmless. A payment file halfway through upload is not. Decide in advance which actions should complete, which should halt, and which need a person to look before anything else moves.
Show the state at handover. When a person takes over, they need to see what the agent was doing, what it already changed, and what it was about to do next. If the only record is a chat transcript, the human taking control is starting blind.
Hand control to a named person. Someone specific has to own the work once the agent stops. "The team" is not an owner at 11pm on a Friday.
If your current plan only covers the first point, you have a pause button. You do not yet have a way to take back control.
Why untested switches fail
Off switches rarely fail because nobody built one. They fail because nobody used one before it mattered.
The control lives in a settings page only one person knows about. The agent runs under a personal account that cannot be revoked without locking someone out. The pause stops the scheduler but not the webhook that keeps triggering work. Turning it off is easy; working out what it already did takes a day of reconstructing logs.
Each of these is cheap to find in a rehearsal and expensive to find in an incident. That is the whole argument for testing.
How to rehearse it
You do not need a formal programme. You need one honest drill before go-live and a few more as the agent's reach grows.
- Pick a realistic moment. Run the drill while the agent is mid-task on real-looking work, not idle in a sandbox.
- Have someone other than the builder pull the switch. If only the person who set it up can stop it, the switch depends on their availability.
- Time it. How long from "stop it" to "it has stopped"? How long until the person taking over understands where things stand?
- Check the side effects. Did anything keep running? Did stopping it break something else that shared the same access?
- Write down what you learned and fix the worst gap. Then run it again.
A team that has done this once will handle a real stop calmly. A team that never has will spend the first hour of an incident arguing about which setting to change.
Questions to answer before your agent goes live
- Who is allowed to stop this agent, and can they do it without asking anyone?
- Where is the switch, and does it work from a phone?
- What happens to work already in progress when it stops?
- What will the person taking over see about what has already changed?
- When did we last test it, and how long did it take?
If the honest answer to the last question is "never", that is your next job, not a nice-to-have.
Where Walter fits
At Walter, I think about this as part of the job description for any AI doing real work. A good chief of staff can be interrupted. They can stop mid-task, tell you exactly where things stand, and hand the work back without leaving a mess.
That is the standard I hold AI work to: clear authority, visible state, a named owner, and a stop that has been tried before anyone needs it. Speed is useful. Speed you cannot interrupt is a risk you have chosen not to look at.
So before you widen what your agent can touch, schedule twenty minutes to press the button. Find out what it really does. Fix what surprises you. Then go live.
Join the waitlist at https://hirewalter.ai/
