Every few months a new demo suggests that an agent can simply be told to process the invoices, and the orchestrator, the queues and the carefully tested workflows can be retired. The demo is usually real. The conclusion is usually wrong. What agents change is not whether you need deterministic automation. It is where the boundary of deterministic automation sits.
Two different kinds of work.
A bot is a program. Given the same input it produces the same output, it either succeeds or raises an exception, and its behaviour can be tested exhaustively before release. That is exactly what you want for posting a journal, updating a record, or moving a file between systems that must agree.
An agent is a reasoning loop around a language model. Given an objective and a set of tools, it decides what to do next, observes the result and decides again. It handles ambiguity, unstructured input and situations nobody wrote a rule for. It is also probabilistic. Run it twice and you may get two different paths to the answer, or two different answers.
The mistake is to use either for the other's job. A bot asked to interpret a free-text customer email will need a rule for every phrasing and will still miss most of them. An agent asked to post 4,000 identical journal entries will be slow, expensive, and occasionally creative in ways the auditor will not enjoy.
A working division of labour.
| Give it to a bot | Give it to an agent |
|---|---|
| Structured input with a known schema | Unstructured or semi-structured input |
| Steps that must be identical every time | Steps that require interpretation or judgement |
| Writes to systems of record | Reads, summarises, drafts and recommends |
| High volume, low variance | Low to medium volume, high variance |
| Pass or fail is well defined | Quality is a matter of degree and needs review |
In a typical back-office flow the agent sits at the edges. It reads the inbound email and decides what kind of request it is. It drafts the response to the supplier whose invoice was rejected, in language that explains why. It triages the exception queue and proposes a resolution for each item. The bot sits in the middle, doing the deterministic work the agent decided should happen, and reporting back a result the agent can rely on.
How they should talk to each other.
The integration pattern matters more than the products. Three patterns cover most cases.
- Agent as dispatcher. The agent interprets input and places a structured work item on a queue. A bot picks it up. The agent never touches the system of record directly, so every write is deterministic and testable.
- Bot as tool. The bot is exposed to the agent as a callable tool with a strict input schema. The agent decides when to call it. Tool calling gives you a clean audit record of what the agent asked for and what the bot returned.
- Agent as exception handler. The bot runs the happy path. When it raises a business exception it hands the case, with full context, to an agent that attempts a resolution and either completes it through a tool or escalates to a person with a recommendation attached.
Guardrails that make the combination safe.
- Strict tool schemas. The agent cannot invent a parameter the bot does not accept.
- Allow-lists for actions by context. An agent handling supplier queries cannot call the payment tool.
- Confidence or self-check gates before any tool call with financial effect.
- Human approval for anything above an agreed value or risk threshold, with the agent's reasoning shown alongside.
- An evaluation harness: a fixed set of real cases the agent is run against before every prompt or model change.
- Prompt and model version control, so a change in behaviour can be traced to a change in configuration.
What changes for the automation team.
The RPA developer's job does not disappear. It shifts towards building clean, well-documented, idempotent bots that can be safely called by something that does not fully understand them. Idempotency matters more than ever: if an agent retries a call, the second run must not post the journal twice.
The new work is on the agent side: writing evaluation sets, tuning prompts against them, deciding thresholds with the business, and reviewing the cases where the agent and the person disagreed. That is closer to quality engineering than to coding, and it suits analysts who know the process well.
The organisations getting value from agents are not the ones that replaced their bots. They are the ones that gave their bots a smarter front door.
If you have an RPA estate and are being asked what to do about agents, start by listing the places where exceptions, free text or judgement currently stop the bots. Those are the seams where an agent earns its place.