Switching off an AI agent that isn't working, cleanly

You set up an agent, you switch it on, and three weeks later it's obvious: it isn't doing what you hoped. It answers oddly, your team corrects it more than it saves them, or customers dodge it entirely and ask for a human in their first message. The natural reaction is to unplug it and move on. The catch is that a live agent isn't a switch. There are half-finished conversations, reminders queued for next Tuesday, and a team that hasn't looked at that inbox in a month because "the bot has it". Pull the plug badly and you leave more holes than you had while it was running. Here's the orderly way to roll it back.

First: is it broken, or did you never finish building it?

Before you touch anything, spend twenty minutes reading the last fifty conversations and sorting them into three piles. What you should do next depends almost entirely on where the bulk of them land.

It's missing information. The agent understands the question but doesn't know the answer: prices are out of date, it doesn't know you close for two weeks in August, it can't tell two similar services apart. That's not an agent failure, that's an incomplete handbook. An afternoon fixes it, and it doesn't justify shutting anything down.

It's in the wrong place. The agent answers reasonably well, but your customers don't use it. They ring anyway, or they open the chat and type "can I speak to someone" before anything else. This is a channel or expectations problem, and it is a real reason to rethink the whole setup.

Nobody trusts it. The agent does the work, but someone on the team reviews one hundred percent of the output and rewrites half of it. That doesn't save hours, it relocates them. The cause is usually tone, badly drawn escalation rules, or the fact that nobody ever agreed who decides what. Look hard at this one before you act, because it's where most people switch off an agent that was actually fine.

If two in three conversations land in the first pile, don't decommission anything. Finish the handbook and look again in a fortnight.

There are three ways back, not one

Most people treat shutdown as binary. In practice you have three options, and the middle one — the one almost nobody picks — is usually the right call.

Pause it (24 to 72 hours). The agent stops replying, but everything else stays in place: access, the number, the history, the rules. It stops the bleeding while you decide, and it answers a genuinely useful question: what happens when it isn't there? If two days pass and nobody on the team misses it and message volume doesn't move, you have your answer. If Monday morning is chaos, you also have your answer.

Narrow it. Strip out everything it does badly and keep what it does well. There is almost always something that worked: opening hours and directions, order status, capturing a new enquiry and passing it on. An agent that does three things properly beats one that does twenty at seventy percent. This is the rollback we recommend most and the one people choose least, because it feels like admitting a partial failure. It isn't.

Full decommission. The agent comes off the board. That's the right move when the underlying process was never clear, when the channel was wrong, or when the business itself has moved on. It's also the one that needs a checklist, because it has more moving parts than it looks.

The decommissioning checklist

Half an hour, in this order. The first item is the one everyone forgets and the source of ninety percent of the mess.

1. Freeze what's already queued. Appointment reminders, follow-up sequences, overdue-invoice nudges. An agent you switch off on Wednesday might have sixty messages scheduled over the next ten days. Close only the front door and those still go out, customers reply, and nobody answers.
2. Close open conversations by hand. Pull the list of threads where the agent spoke last and nothing was resolved. It's usually somewhere between five and twenty. Each one deserves a short message from a person.
3. Redirect the channel. If the agent lived on a WhatsApp Business number or a shared mailbox, decide today who receives that from tomorrow, and write it down. An orphaned channel is worse than no channel.
4. Remove the visible front door. The website widget, the link in your email signature, the QR code on the counter, the button on your Google profile. Leave them up and people keep knocking on a door nobody opens.
5. Revoke access — and note what it had. Calendar, mailbox, CRM, payment provider. Revoking is the easy part; the note about what was connected and why is what you'll be glad of in six months.
6. Export the history before you cancel anything. Three months of real conversations are the best raw material you'll ever have for writing an FAQ playbook, whatever you build next. Cancel the account first and it leaves with you.
7. Tell the team in one sentence, not a paragraph. "From Thursday, WhatsApp messages to the shop number go to Marta, same as before May." No ambiguity, with a date on it.

When not to switch it off

• In week one or two. A newly built agent always looks worse than it is: it hasn't seen enough cases, you can't yet read its failures, and the team distrusts it by default. Give it three or four weeks and decide on evidence.
• In peak season. Shutting down at the peak hands your team exactly the volume they can't absorb, in the worst week of the year. If the agent is bad but not dangerous, narrow it now and decommission in January.
• When the person asking is the one who never wanted it. It happens more than you'd think. Not a reason to dismiss them — very much a reason to read the conversations instead of trusting the general mood.
• When only one task is broken. If one of five jobs is causing trouble, remove that job. Killing the whole thing over a specific fault throws away four that were working.

Write the two-paragraph post-mortem

Once it's off, write two paragraphs and put them somewhere you'll find them again: what you expected it to do, what it actually did, and the precise point where it went sideways. This sounds like bureaucracy. It isn't. Most of the time the failure wasn't in the agent at all but in the process underneath it — and you will meet that process again, with a new hire, a different tool, or another agent a year from now.

Switching off something that doesn't work, cleanly and without leaving customers hanging, is a good decision rather than a defeat. The one option with no upside is leaving it half-on: answering sometimes, nobody watching, reminders still firing on their own. If what you actually want is to rethink which tasks should have been automated in the first place, start there rather than with the tool — our operations agent is built for exactly that kind of internal work, and the conversation beforehand matters as much as the build.