AI agents vs. RPA vs. chatbots: which automation fits which process?

Three tools for three different jobs

A typical scenario: purchase orders arrive as PDF attachments in a dozen supplier layouts, some with handwritten notes. A clerk opens each one, checks it against the price list, enters it into the ERP and emails a confirmation. Which automation fits? That depends on which part of the job you are looking at, because each of the three technologies covers a different part.

Robotic process automation (RPA) uses software robots that replay a fixed sequence of clicks, keystrokes or API calls. It is excellent at the entering-into-the-ERP part, as long as the data is already clean and the screens do not change.

Chatbots are conversational interfaces. Older ones follow decision trees; newer ones use a language model to understand free text. They are good at the front end, answering the supplier who asks where the order is, but a chatbot alone cannot process anything.

AI agents are goal-driven systems that use a language model to read, decide and act across several steps and tools. They are the first technology that can handle the messy middle: reading twelve layouts, noticing that a price deviates from the contract and deciding what to do about it. For the full definition, start with our article on what agentic AI is.

The common mistake is to treat these as generations, as if agents replaced RPA the way RPA replaced macros. They are tools for different kinds of input, and most real processes need two of them.

The comparison at a glance

Two rows deserve attention. The lack of determinism is not a weakness to be engineered away; it is the reason agents can handle exceptions at all. And the maintenance row explains why many RPA estates quietly grow a team that keeps the bots alive: the robots are only as stable as the screens they click on.

Where RPA still wins

RPA is the right answer more often than agent enthusiasts admit. It wins when the interface is stable and there is no API, when the process must be strictly deterministic because an auditor will ask, when the cost per run has to be close to zero, and, above all, when it already works. Mass data entry into a legacy system, reconciliations with fixed export formats, nightly transfers between two applications: none of these need a language model, and adding one would only add cost and uncertainty.

Our advice in these cases is deliberately unexciting: keep the bot, document it, and put an agent in front of it only when the input stops being clean.

Where agents replace or wrap RPA

Agents earn their place where RPA needs a person to prepare the input. Documents in varying layouts, emails with the order details in the body, tickets with the actual problem in paragraph three: the classic RPA project fails here because the bot needs structured fields and someone has to create them. An agent reads the unstructured input, extracts and validates the fields, and only then hands over.

The second area is judgement. When the rule reads “match the invoice to the purchase order unless the deviation is explainable”, RPA does the first half and stops at the word unless. An agent can look at the delivery note, the contract and the correspondence, propose an explanation and route the case accordingly. The third area is the exception queue itself, which in many RPA estates is worked by hand. An agent that resolves most exceptions and prepares the rest for a person often delivers more than automating another happy path.

Whether an agent replaces or wraps the bot depends on the system behind it. If the target application has an API, the agent calls it directly and the bot retires. If the only way in is the user interface, the bot stays as the hands and the agent becomes the head. That is the wrap pattern, and it is the most common outcome in Mittelstand IT landscapes with older ERP systems.

Chatbots are an interface, not a solution

The disappointment with the chatbots of the last decade had a simple cause: a conversation is not a capability. A bot that perfectly understands “I want to change my delivery address” but cannot open the order and change it produces friction, not service. The customer ends up in the same email queue as before, now annoyed.

The current generation changes the equation only if you treat the chat window as the front door to something that can act. Behind a good customer-service chat sits an agent with tools: look up the order, check the policy, change the address, confirm. Behind a good internal helpdesk chat sits a knowledge assistant that searches the actual documents and, where allowed, executes the request. Design the capability first and the conversation second.

Hybrid patterns that work in practice

The productive answer is rarely a single technology. Three combinations come up again and again in our agentic workflow projects.

• The agent decides, RPA or an API executes. The language model handles reading, extraction and judgement. Execution runs through deterministic connectors: APIs where they exist, RPA bots where only a user interface exists, a workflow engine in between. The boundary between the two is explicit and logged.
• Chat in front, agent behind. The conversation is the entry point for customers or employees; the agent behind it has tools and permissions, and the level of autonomy is set per action.
• RPA runs the happy path, the agent takes the exceptions. The existing bot keeps doing what it does. Whatever it cannot process is passed to an agent, which resolves the case or prepares it for a person. This is the least disruptive way to modernise an RPA estate.

A decision framework in five questions

For any process on your list, answer these five questions in order. The pattern of answers usually points to one architecture.

1. What does the input look like? Structured, predictable and always in the same place: RPA or a plain integration. Unstructured, variable or arriving in several formats: an agent is needed at least for the intake.
2. How much judgement sits in the middle? None, the rules are complete: RPA. Some, and an experienced clerk applies rules of thumb: an agent with guardrails. Purely human discretion, for example negotiations: assist only, no automation of the decision.
3. What happens when it is wrong? Reversible and cheap: the agent may act within limits. Expensive or irreversible: an approval step before execution, or keep the machine at the recommendation level.
4. How stable are the systems? APIs available: the agent calls them directly, ideally through a standard such as MCP. Only a user interface: RPA as the hands. Screens that change every quarter: expect bot maintenance and budget for it.
5. Who or what triggers the process? A person asking in natural language: a chat front end. An event in a system or a scheduled batch: an agent or bot running in the background, with people notified only for exceptions.

If the answers point to an agent, the next question is which process to start with. Our guide to choosing your first AI agent use case has a scoring model for that.

Three examples

Order intake from emails and PDFs. Input unstructured, judgement moderate, errors reversible before posting, ERP with a partial API. Architecture: an agent for reading, validation and clarification questions; the API for posting; RPA only for the one legacy screen without an API. See AI agents in operations.

IT helpdesk: password resets and access requests. Input conversational but narrow, judgement minimal, rules complete. Architecture: a chat front end, deterministic automation behind it, an agent only for the ambiguous tickets where the actual problem is buried in the description. See IT and engineering.

Monthly bank reconciliation with fixed export formats. Input structured, judgement none, systems stable. Architecture: RPA or a scheduled integration. No agent, no chatbot. If someone proposes one, ask what the language model would be deciding.