When to Fire an Agent (and Hand the Work Back to a Human)

We talk endlessly about deploying agents. Where to add one, what to automate next, how to get more leverage. Almost nobody talks about the other half of the job: knowing when to pull an agent off the work and hand it back to a human.

That's a mistake. Deciding when an agent should stop doing something is exactly as much a management skill as deciding when it should start. With people, you'd never call it failure to move someone off a role that isn't working. It's just managing. Same here.

Firing an agent isn't admitting the AI failed

The instinct is to read a pulled agent as proof the whole thing was a bad idea. It usually isn't. More often the agent was put on the wrong work, or the work changed, or it should never have been automated in the first place. None of that means AI "doesn't work." It means you made a staffing decision that needs revisiting, which is a normal, healthy thing to do.

The teams that get this wrong treat every agent as permanent once it's live. They let it limp along doing mediocre work because pulling it would feel like going backwards. That's not discipline. That's sunk cost.

The signals it's time

Four patterns tell you an agent is in the wrong seat.

Checking it costs more than doing it. The whole point was leverage. Picture an agent that generates your weekly client status reports. If every report comes back needing fifteen minutes of fact-checking and cleanup, and a person could have written the thing in twenty, you haven't saved anything. You've added a review step to a task that was faster by hand. If your team spends more time reviewing and correcting the agent than they'd spend just doing the work, the leverage is negative.

The work needs judgment that doesn't delegate. Some tasks look automatable but are really judgment, relationship, or high-stakes calls wearing a routine costume. If a job keeps requiring a human to step in on the part that actually matters, it was never 70% work. It was 30% work you mislabeled.

It keeps failing the same way and context isn't fixing it. A good agent gets better when you improve its context and instructions. If you've genuinely invested in the context and it still makes the same class of mistake, that's a signal the tool or the framing is wrong for this job, not that you need to try the prompt one more time.

The stakes changed. An agent that's perfectly fine drafting internal notes is not fine drafting the message that goes to your biggest customer. When the cost of being wrong goes up, work that was safely in the 70 moves into the 30. The agent didn't get worse. The job got more serious.

How to pull an agent well

Firing an agent is rarely all-or-nothing. The smart move is usually to demote, not delete.

Take that report-writing agent. It may be bad at producing the finished, client-ready report, but genuinely good at pulling the numbers, drafting the first cut, and flagging what changed week over week. So you hand the final write-up back to a person and keep the agent doing the gathering and drafting underneath it. You're not removing the agent from the workflow. You're moving it to the part it's actually good at, and putting a human back on the part that needs one.

Do it cleanly. Make sure the human picking the work back up has what they need, the same way you'd manage any handoff. The failure mode is a silent gap where everyone assumes the agent has it and nobody actually does.

This is the 30% doing its job

Knowing when to pull an agent is the 70/30 Method working as designed. The 30% you keep with senior judgment exists precisely to notice when something shouldn't be in the 70, and to act on it. An agent you onboarded like a new hire still needs a manager willing to say "this isn't the right role for you" when the evidence says so.

The goal was never to maximize how much the agents do. It was to put the right work in the right hands, human or agent, and to keep moving it when you're wrong. Aggressive automation and the willingness to pull an agent aren't opposites. They're the same discipline.

If you're building a system where agents own real work and you need to know which work that should actually be, that's the Agentic OS work I do with clients. Let's talk.