AIBefore you count the savings, plan how to stop the agent
An AI agent that keeps repeating a mistake won't set off an outage alarm, and stopping it leaves half-finished work in several systems. We propose designing and rehearsing the stop before go-live, and letting the fallback it needs decide how much of the team you can really free up.
When an AI agent goes into production, the plan describes how it runs and where a person approves. The design gets its hardest test at another moment. Something is going wrong, the agent is still working, and someone has to decide to stop it.
Our view: before an agent takes over a live process, the business should design and rehearse how to stop it. That covers who can pause it without waiting for IT, which parts can be stopped while the rest keeps running, what state each request is left in, and who handles the queue by hand while the cause is fixed. The people who can still do the work by hand are the same people the business case hopes to free up. So the stop plan also decides how much of their time you can actually release.
This applies to agents that write to your systems or send messages on your behalf. An agent that only prepares drafts for a person to finish needs a much lighter stop plan.
An agent that's wrong doesn't look broken
Continuity plans are built for systems that fail: when a server goes down, an alarm starts the procedure. An agent can fail in a quieter way. It keeps running, the technical monitoring stays green, and it repeats the same mistake on every new request.
So the first signal is likely to come from the business. A customer calls about a strange confirmation, or a warehouse team sees orders that make no sense. The person who notices often isn't the person who can switch the agent off. Deciding to stop is also a business judgement: is this a one-off, or is every request since ten o'clock affected?
A morning at a distributor
Consider a hypothetical industrial distributor. An agent handles customers' requests to change open orders. It reads the email, updates the order in the ERP, sends the customer a confirmation and tells the warehouse what to pick. The customer service team that used to do this by hand now spends its time on complaints and key accounts.
One morning, after a change to the warehouse codes in the ERP, the agent starts mishandling one kind of request: changes that move an order to a different warehouse. It sends them to the wrong one, and its confirmations still look perfect. A warehouse supervisor spots the problem mid-morning and walks over to customer service.
Can the customer service lead pause the agent, or does it take a ticket to IT and a call to the vendor? If the agent stops right now, which requests are finished and which are half done? Some orders are updated but the customer hasn't been told. Some customers have a confirmation but the warehouse has the wrong instruction. And who processes this afternoon's requests, when the people who know how are busy with other work and some of them no longer have the system access they used to?
These answers have to be settled and tested before go-live. On the day, there's no time to invent them.
The stop plan sets what you can release
A business case for an agent counts the hours the customer service team will no longer spend on the task. The stop plan shows that some of those hours can't disappear.
A real fix may take days. If a pause means the customer service team has to take back the whole queue for that long, the business can't move the entire team to other work. It can keep some people on the process part-time, with their access and regular practice, build partial stops so that most problems don't need a full pause, or start with a smaller share of requests and widen it as evidence builds up. Any of these works. Releasing all the capacity while the fallback exists only on paper doesn't.
The same question returns as the agent's autonomy grows. Each time it takes on a new type of request or a new action, the stop plan has to cover it too.
What a stop plan contains
For the distributor, we'd want five things in place before go-live.
Authority to pause, in the business. The person on duty in a named role, here the customer service lead, can pause the agent directly. In practice that means a switch in a tool the lead already uses, built in before go-live. In a small team, that can be one person with a named deputy. An unnecessary pause costs some manual work. A late one can cost far more in corrections and in customers' trust. The decision to stop sits with the business, and IT and the vendor then fix the cause.
More than one way to stop. In the distributor's case, requests that move an order to another warehouse could go to a person while the agent keeps handling the rest. That alone would have contained the morning's problem. A heavier option is to let the agent keep preparing updates and confirmations while a person approves each one before anything is saved or sent. A full pause is the last resort. These modes are part of the build, so they belong in the scope agreed with whoever builds the agent.
A known state for every request. For each request, the system records which steps are done. When the agent is paused, it starts no new steps, and the customer service team gets the list of half-finished requests with what's missing for each one. It also gets the requests the agent completed since the problem began, so they can be checked. When the agent restarts, it has to recognise steps a person has already finished, so the warehouse doesn't receive the same instruction twice.
A fallback with people and access. Someone has to work the queue while the agent is paused: named people, a short procedure and system access that hasn't been removed. Size it for the time a real fix might take. On a normal day nobody needs it, so this capacity has to be kept alive on purpose, for example by having the team handle a small share of requests by hand on a regular basis.
Criteria to restart. Before the agent resumes, the cause is fixed, the affected requests are reconciled and a set of test requests with known correct outcomes is run through the agent. A named person decides when the agent restarts.
Then rehearse it. In the test environment, pause the agent in the middle of a batch and watch what happens. How long does it take until every request is in a known state? Can the customer service team pick up the queue with the access they actually have? A rehearsal is the cheapest place to find a step that isn't safe to repeat or a permission nobody remembered.
The strongest objection
One objection is that all this already exists. The distributor already has incident management and a continuity plan, and switching an agent off is technically simple.
We'd keep the existing incident process as the home for the stop plan, and add what is specific to agents. Someone in the business needs the authority to use the switch on the strength of business signals, before any technical alarm. Switching off also leaves work half done in several systems, and a technical restore won't tell you which customer received which promise.
A second objection is cost. The stop plan does add work: partial stops and step tracking have to be built, and some capacity stays where it is. That cost is easier to accept in the business case than to discover during an incident. Partial stops also pay back later, because the business can give the agent more work when stopping one type of request doesn't mean stopping everything.
Questions for the go-live review
If the agent were paused now, could we list every half-finished request, and every request completed since the problem began?
Who would work the queue by hand tomorrow, for several days if needed, and do they still have the access?
Which partial stops exist, and has each one been tested?
If the honest answer to the second question is "nobody", the business case is counting hours it can't release yet.