How to replace a rules-based bot with an AI agent

Do not throw the rules away; turn the hard ones into the agent's bounds. Inventory what the bot does and where it fails, keep its non-negotiable rules as limits the agent cannot cross, run the agent beside the bot on real cases, then move one case type at a time. The process owner decides each cut-over.

Why replace a bot that works?

Rules-based bots, whether scripted automation clicking through screens, a decision-tree chatbot or a rules engine, are good at the cases their authors foresaw. They are poor at everything else. A form with a field in a new place, a customer who answers in a sentence instead of choosing an option, a document laid out differently: the bot stops, and a person picks it up. Over time, the exceptions queue becomes the real process.

An agent can handle variety the bot cannot. That is the reason to replace it. It is also the risk: the agent will try to handle cases the bot would have rejected, and some of those rejections were deliberate.

The process owner keeps the decisions: which rules become bounds, which case types move, and when the bot is switched off. The team that maintains the bot, often an automation centre, is essential to the work because only they know what the bot really does.

What is the method?

1. Automation team: inventories the bot. Every rule, every branch, every system it touches, every condition under which it stops. Use its logs, not its design documents; the two often disagree.
2. Process owner: sorts the rules into three groups. Hard constraints that must never be broken ("never release a payment above the limit", "never change a closed account"). Procedural steps that describe how the work is done. Workarounds for the bot's own limits ("if the field is blank, stop").
3. Process owner and risk: turn hard constraints into bounds. These become the agent's limits, enforced at the moment of action, not instructions in its brief. A bound refuses; an instruction can be misread.
4. Agent builder: writes the procedural steps into the brief. Workarounds are dropped, because the agent does not share the bot's limits.
5. Agent, depth 1 and 2: runs in shadow beside the bot on live cases, producing what it would do without acting.
6. Analyst: compares by case type. On cases the bot handles, the agent must reach the same outcome. On cases the bot drops to people, compare the agent with what people did.
7. Process owner: moves one case type at a time, starting where the agent matches the bot and the cost of error is lowest.
8. Process owner: keeps the bot available as fallback until each moved case type has held its depth through a renewal.
9. Process owner: decommissions the bot, with the record of what replaced each of its functions.

Why are hard rules turned into bounds rather than instructions?

The bot's rules were enforced by the code: it could not do otherwise. An agent's brief is read and followed, but it is not code. If "never pay above 10,000" lives only in the brief, a confusingly worded case might lead the agent past it. If it lives as a bound checked at the moment of action, the action is refused whatever the agent concluded.

This is the main thing the old bot teaches you. Its rules were written by people who had seen the failures. Keep their wisdom in a form that is enforced.

How do you decide which case types move first?

Proportion the effort to the risk. A risk-based approach puts more scrutiny where an error costs more, and less where it costs little. For replacing a bot, that means starting with case types that are common, reversible and well matched in shadow, and leaving case types that move money or affect customers' rights until there is more evidence.

The case types the bot already handles well are often the least valuable to move. The value is in the exceptions. But the exceptions are also where the agent has the least comparison data, because the bot never handled them. Move a few easy types first to prove the controls, then turn to the exceptions with people reviewing.

What record does the replacement produce?

• The bot inventory, from logs, with each rule.
• The rule map: each rule, its group, and what replaced it (a bound, a step in the brief, or nothing).
• Shadow comparison results by case type.
• Each cut-over decision, with evidence and the owner's name.
• The decommission record, confirming every bot function has a successor or was deliberately dropped.

An auditor who asks "what stopped the old payment limit from being lost?" should find the answer on one page.

Where does it usually go wrong?

The design documents are trusted. The bot was patched many times. Its real behaviour is in its logs.

Workarounds are carried over. "Stop if the field is blank" made sense for a bot that could not infer. Copying it into the agent's brief keeps the old exception volume.

Hard rules are softened. The agent handles a case well that the bot would have refused, and someone suggests relaxing the bound. That may be right, but it is a decision for the process owner, with evidence, not a side effect.

The automation team is left out. They built and know the bot. The change may also unsettle them, and the questions people ask about whether AI agents will replace jobs in operations apply to them as much as anyone. Their knowledge is needed for the inventory, and their skills transfer well to maintaining bounds.

The bot is switched off too early. Keep it as fallback until the agent has earned stable depth, as train, shadow, certify, widen sets out.

Where Pryme fits

In Pryme, a bot's hard rules become customer limits in the minimum chain, checked at the moment of action, and the verdict names the limit when it decides. Attest replays the agent against the cases the bot handled and the ones it dropped, so each case type moves on evidence.