How to take work back from an AI agent

Lower the agent's depth for the affected capability first, then send new work to people's queues, list every item in flight and give each a named owner, and brief the staff who are taking over. The agent can keep drafting to help, or stop altogether. Watch the backlog daily. Each step leaves a record of who held the work.

When would you take work back?

Sometimes because something went wrong: a failed run, a bad change, an incident, a complaint that reveals a pattern. Sometimes for ordinary reasons: a certificate lapsed and renewal is not ready, the process is changing, a regulator has asked questions, or a provider is unavailable. And sometimes permanently, because the agent is being retired.

The reason affects how long the work stays with people, not how you take it back. The steps are the same. The argument that this must always be possible, and what that requires in advance, is made in handing work back from an agent must always be possible.

The agent owner decides to take work back. Agent operations makes the changes. The team leader whose people take over runs the work. Approvers of the agent's held items are told at once.

What are the steps, and who acts at each?

1. Agent owner: decides and records the reason, the capabilities affected and whether the agent should keep drafting. Evidence: the decision with its time.
2. Agent operations: lowers depth for the affected capabilities, to 2 if the agent will keep drafting, to 1 if it will only read, or removes the capability. Evidence: the depth change and the time it took effect.
3. Agent operations: reroutes new work to the team's queue instead of the agent's. Evidence: the routing change.
4. Agent, depth 1: lists every item in flight: held items awaiting approval, cases it started but did not finish, scheduled actions not yet run, messages drafted but not sent.
5. Team leader: assigns each item to a named person, and cancels any scheduled action that should not run. Evidence: the list with new owners.
6. Agent owner: tells the people affected: the team, approvers, and any team downstream that relies on the agent's output. Evidence: the message and recipients.
7. Team leader: briefs staff who will do the work, using the current procedure. Staff who have not done it for months may need a refresher. Evidence: the briefing record.
8. Agent, depth 2 if kept on: drafts for people to review and send. Staff decide whether drafts help or slow them down.
9. Team leader: monitors the backlog daily and raises concerns early. Evidence: daily backlog figures.
10. Agent owner: decides on return, through recertification, or confirms the work stays with people. Evidence: the decision.

How is this different from rolling back?

Rolling back restores an earlier version of the agent: its brief, sources or bounds. Taking work back moves the work to people, whatever the version. They often happen together, a bad change triggers both, but they are separate decisions. You might take work back while you investigate, then roll back, then recertify, then hand work to the agent again. The rollback sequence is set out in how to roll back an AI agent after a bad change, and the short answer in how do you roll back an AI agent?.

Why does the in-flight list matter so much?

Because items in flight are the ones that get lost. A held refund that no approver now sees. A case the agent opened and was halfway through. A scheduled reminder that will still fire. A draft sitting in a shared mailbox. If no one owns them, customers wait or, worse, an action runs that no one meant to allow.

The agent's verdict records make the list possible: every action it was allowed, held or refused, and every action it planned, is recorded. Without those records, the team would be reconstructing the list from memory and system searches.

What if the team has forgotten how to do the work?

This is the real risk, and it grows the longer the agent has done the work well. Procedures change, staff move on, and the people left have spent months reviewing drafts rather than producing them. Plan for it before you need it: keep a rota of people who do the work by hand regularly, keep the procedure current, and practise taking work back. Training for this is part of training staff to work alongside an AI agent.

What should you measure?

• Time from decision to depth change, which should be minutes.
• In-flight items unassigned after the first hour. The target is none.
• Backlog and turnaround while people hold the work, against the fallback service level.
• Errors by staff in the first days, which show whether the briefing was enough.
• Time until the work returns, or until the decision to keep it with people.

Where does it usually go wrong?

Depth is lowered but routing is not changed. New work still goes to the agent, which now only drafts, and drafts pile up unseen.

Scheduled actions still run. Reminders, follow-ups and batch jobs the agent set up continue. List and cancel them.

Approvers are not told. Items they approve after the decision may be acted on through a path no one meant to keep open.

The team is not asked. Work arrives in their queue with no warning. Tell them first.

Return happens too fast. The fix looks simple and the agent goes back to full depth the next day. Recertify, then return through the steps in train, shadow, certify, widen.