PrymeIntelligence

Agentic operations·Article

Handing work back from an agent must always be possible

Handing work back from an AI agent must always be possible. Teams need the skills, access and capacity to take work back the day an agent is suspended.

Any agent can be suspended at short notice: a failed certification run, an incident, a provider outage. Its work then goes back to people. If they have lost the skills, the access or the time, suspension stops being a safe option, and an agent you cannot stop is an agent you do not control.

Why does the ability to hand back erode?

Quietly and for good reasons. Once an agent handles a process reliably, the team that used to do it moves on to other work. New joiners never learn the routine cases. Procedures stop being updated for people because people no longer use them. Access to the systems involved is trimmed in a tidy-up. Within a year or so, the team that could do the work has become a team that remembers doing it.

None of this is visible until the day the agent stops. Then a queue forms, nobody is sure how to clear it, and the pressure to restore the agent before it is fixed becomes intense. That pressure is the real danger: it pushes the business to resume the agent's authority without the evidence that would justify it.

When does work need to be handed back?

More often than most plans assume. The triggers fall into a few groups.

Trigger How fast Typical scope
Failed certification run Same day The affected agent, at the depth the evidence no longer supports
Wrong-action incident Immediately One capability, sometimes the whole agent
Provider or platform outage Immediately Every agent on that platform
Source failure Within hours Capabilities relying on the source
Regulatory or legal instruction As directed Possibly a whole class of agents
Bad change to the agent On detection The capabilities the change touched

Some of these hand back part of the work, some all of it. A capability dropping from execute to draft means people must now send what the agent prepares, which is a smaller step than taking over the whole task. Your plan needs to cover both.

What does a team need to take work back?

Four things, each of which decays if nobody maintains it.

Skills. People who can do the work to the required standard, without the agent's drafts. That means some staff keep doing the work regularly, or practise it on a schedule.

Access. Accounts and permissions in the systems the work touches. If people's access was removed when the agent took over, restoring it in an emergency can take days.

Procedures. Written steps a person can follow. These often live on in the agent's instructions but drift out of human-usable form.

Capacity. Hours available at short notice. A team running at full stretch on other work cannot absorb an agent's volume overnight.

Our playbook on taking work back from an AI agent sets out how to prepare each.

How do you handle work that is in flight?

This is the part most plans miss. At the moment of suspension, the agent will have cases at every stage: read but not drafted, drafted but not sent, held for approval, partly executed. Each needs a clear owner and a clear next step.

The record makes this possible. If every action the agent proposed is recorded with its verdict and status, you can list every open case and its stage in minutes. Held items stay with their named approvers. Drafts not yet sent go to people to review or redo. Partly executed actions are the hardest: someone has to check whether each step completed and finish or reverse it by hand.

Write this sequence down before you need it, and test it. A suspension is not the time to work out what "half done" means for a payment.

Handing back is not the same as rolling back. Rolling back changes the agent: you revert its brief, sources or configuration to an earlier version that worked. Handing back changes who does the work: people take over while the agent is fixed. You often need both at once. A bad change is rolled back, and while the rolled-back version is re-tested, the work is handed back. Our guides on how to roll back an AI agent and rolling back an agent after a bad change cover the first half.

Why do regulators care about this?

Operational resilience rules in several markets expect firms to keep important services running through disruption, including the failure of a third-party provider. EU financial entities in scope of DORA must manage ICT risk and ICT third-party risk, including exit and continuity planning. Basel Committee principles on operational resilience set similar expectations for banks more widely. An agent you cannot hand back from is a single point of failure in a service that may matter to customers.

This applies with particular force in banking operations, where back-office work often supports payments, settlement and account servicing. Our piece on whether an AI agent can work in a bank's back office looks at the conditions. This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

How do you keep the ability alive?

By practising it. Run a handback drill for each material agent at least once or twice a year: suspend a capability for a day, have the team take over, and measure how long it took to clear the queue and what went wrong. Keep a small number of people doing the work by hand regularly, rotated so the skill spreads. Keep procedures written for people as well as for the agent. Review access so people who may need to take over still have it.

What is the trade-off?

Keeping the ability to hand back costs capacity that the agent was meant to release. Some people have to keep doing work an agent could do, drills interrupt normal operation, and procedures need double maintenance.

That cost is insurance. Without it, the only response to a failing agent is to keep it running, which removes your most important control. For each agent in production, ask who would do its work tomorrow if it stopped, whether they have access, and how long the backlog would take to clear. If the answer is "nobody", "not any more" or "we don't know", fix that before you widen the agent further. The deployment approach that keeps this in view is set out in our guide to deploying an AI agent: train, shadow, certify, widen.

Where Pryme fits

In Pryme, a certification run that clears no depth drops the agent to depth 1 the same day, and a capability owner can lower depth at any time. Because every verdict is filed with its status, the open cases at the moment of suspension can be listed from the record and assigned to people.

Questions people ask

How much human capacity should be kept in reserve?

Enough to cover the agent's most important work at a reduced service level for the time it would realistically take to fix or replace it. That differs by process; the drill is how you find out whether the reserve is enough.

Can another agent take over instead of people?

Sometimes, if a second agent is already certified for the same capability on the same cases. But if the cause is shared, such as a provider outage or a bad source, the second agent may fail too. People remain the fallback that does not share the agent's failure modes.

Should customers be told when work is handed back?

Only if it affects them, for example through longer waiting times. The handback itself is an internal matter, but service changes that result from it should be communicated as any other disruption would be.

Decide what your agents may do. Prove it. Enforce it.

Pryme Intelligence certifies each agent on your own cases, checks every action against five bounds at the moment it happens, and files every verdict.