Agents, RPA or workflows: which automation for which job

A company has three automation initiatives running at once. An RPA team is automating screen work in the old ERP. IT is building approval workflows in a workflow tool. An innovation team is piloting AI agents. All three have claimed the inbound invoice process.

The RPA bot breaks whenever the ERP screen changes. The workflow needs every case designed in advance, so the odd invoice falls out of it. The agent handles the odd invoices well, and nobody can explain afterwards why it did what it did. Each team blames the other two for the gaps.

The cause is that three different tools for three different shapes of work were chosen by who owned the budget, not by the job. They are not competitors. Each is good at something the others are bad at.

Three tools, three jobs

Workflows (process engines, BPM) make an explicit process run: states, transitions, rules, owners and approvals, all designed in advance. They are predictable and auditable, and rigid by design. They suit work where the process is known and stable.

RPA (robotic process automation) is software that operates other software’s user interface the way a person would, with clicks and keystrokes. It is a bridge to systems that have no programming interface. It is brittle when screens change, and it automates the workaround rather than the process.

Agents are language models that read, plan and call tools. They cope with unstructured input and with cases nobody foresaw. They are not deterministic, so they need written limits, a log of what they did and approvals on anything that matters.

Common mismatches

RPA as an integration strategy. A bot copying fields from one system to another is an integration with no contract. When either screen changes, it fails, often silently, and the problem is discovered downstream.

Workflows for unstructured work. Trying to model every kind of customer email as a branch in a diagram produces a diagram nobody can maintain, and still misses the next new kind of email.

Agents for deterministic steps. Using a language model to calculate tax or to apply a fixed approval threshold is slower and more expensive than code, and it can be wrong in ways code cannot.

Agents without limits. Write access with no ceiling on value, no list of what may be touched and no approval step. It works until the first confident mistake.

Three tools, three states. Each keeps its own record of where a case is, so “where is this invoice” has three answers and a meeting to reconcile them.

Choose by the job

For each step in a process, ask five questions in order.

1. Is the input structured? If not, an agent reads it and turns it into structure.
2. Is the rule known and stable? If so, it belongs in a workflow or plain code, and runs the same way every time.
3. Is there an interface or a shared data model? If so, use it. RPA only as a temporary bridge to a system without one, with a date by which it will be retired.
4. Does the step need judgement on a case nobody foresaw? Then an agent prepares a proposal with its reasoning and a person decides.
5. What does a mistake cost, and can it be undone? That sets the approval, whichever tool does the work.

The usual answer is a combination. The workflow is the spine: states, owners and approvals. Agents handle the unstructured steps inside it, such as reading, drafting and classifying. Deterministic code does the calculations. RPA bridges a legacy system only until that system is replaced or exposes an interface.

That is the structure Hurukan’s Agentic Logic layer is designed around: domain agents working inside process templates, with written autonomy limits, approvals by a person on critical steps, and every action logged. Proposals that need a decision go to one inbox, described under Decisions and Tasks. Both are in build. Whichever tools are chosen, most failures happen between the steps rather than inside them, which is the argument of hyperautomation fails at the handover.

A test you can run today

Make a list of every automation running in your company: bots, workflows, scheduled scripts, macros, agents. For each, write four things:

1. What it does, in one sentence.
2. Which of the three kinds it is.
3. Which kind it should be, according to the five questions above.
4. Who is told when it fails, and how.

Any automation where the answers to the second and third points differ is a candidate for rebuilding. Any automation where the answer to the fourth is “nobody” or “we would notice eventually” is the one to fix first, whatever kind it is. The Hurukan homepage explains how agents fit into the rest of the system.