Agentic AI vs RPA in Treasury: Agents Don't Remove the Process Work
Every vendor I talk to this year has an agent. The pitch usually goes like this: your RPA bots are brittle, they break every time a bank changes a screen, so replace them with an agent that understands the goal and finds its own way.
Half of that is true. RPA is brittle. An agent is more flexible. But the conclusion people draw, that you can now skip the boring work of mapping the process, is exactly backwards. An agent doesn’t remove the process work. It punishes you for skipping it.
If you want the basics first (what an agent is, its components, how it compares with RPA task by task), start with Agentic AI in Corporate Treasury. This article is about the decision that comes after: which one to use, and what to write down before you trust either of them with real treasury work.
The one sentence difference
RPA follows steps. You record or script a sequence: open the portal, download the file, copy column C into the template, save, send. It does exactly that, every time.
An agent follows a goal. You give it an objective (“daily cash report in the Teams channel by 9:00”), a set of tools it may use, and rules. It plans the steps itself, acts, checks the result and adjusts.
So far, so familiar. The part that matters for treasury is what happens when something goes wrong.
RPA fails loudly. An agent can fail quietly.
When a bank moves a button or renames a column, RPA stops. You get an error, the report doesn’t arrive, someone notices by 9:15. Annoying, but visible.
An agent is built to work around obstacles. That is its whole value. But “work around” can mean the right thing (find the file in the backup folder) or the wrong thing (use yesterday’s balance because today’s is missing, and say nothing). The report still arrives at 9:00. It looks normal. It is wrong.
| RPA | Agent | |
|---|---|---|
| Something changes | Stops | Tries another way |
| How you find out | Error, missing output | Only if it was told to tell you |
| Typical damage | Delay | A plausible, wrong number |
| What protects you | Monitoring the run | Rules, checks and a log, designed upfront |
That last row is the whole argument of this article. With RPA, the safety net is that failure is obvious. With an agent, you have to build the safety net yourself, before go live.
One missing statement, three outcomes
Take a daily cash report built from end of day statements from five banks. One morning, Bank C’s camt.053 isn’t in the folder. (This is an illustrative example, not a specific case.)
The RPA bot reaches the step “open Bank C file”, finds nothing and stops. No report goes out. The treasurer gets an error message and chases the bank.
An agent with a vague objective (“send the cash report at 9:00”) notices the missing file, decides the objective still has to be met, and reuses yesterday’s Bank C balance, or leaves it out. The report goes out on time. Nobody knows that 20% of the cash in it is a day old.
An agent with a mapped process has three extra lines in its instructions: a statement older than today is never used as today’s; if a bank is missing, check the backup folder once; if it’s still missing, send the report marked INCOMPLETE, name the bank, and alert the treasurer. The report goes out on time, it is honest about what it contains, and a human decides what to do about Bank C.
Same technology in the last two cases. The difference is entirely in the process work someone did, or didn’t do, before switching it on.
Write down four things before any agent touches a treasury process
1. The objective, in one sentence. If you can’t say it in one sentence, the agent can’t plan towards it. “Help with cash management” is not an objective. “Publish the consolidated cash position by entity and currency in the Teams channel by 9:00 on business days” is.
2. What it may do, and what it may not. List the actions it is allowed to take: read files from this folder, call this balance API, write to this SharePoint list, post in this channel. Then list what is off limits. In treasury, that second list matters more than the first.
3. Where a human approves. Decide in advance which outputs go straight out and which wait for a person. A daily report with all banks present can go out alone. A report with a missing bank, a balance that moved more than an agreed threshold, or anything touching a payment waits for sign off.
4. What gets logged. Every run should leave a record: which files it used, which steps it took, what it skipped and why, who approved what. Your auditors will ask. More importantly, it’s the only way you’ll catch the quiet failures.
If this looks like the work you would do before automating anything, that’s because it is. The Automation Workflow Builder walks you through exactly these pieces (trigger, actions, approval, exceptions) and gives you a diagram of the flow. Do it before you open any agent platform.
What an agent should never do alone in treasury
Some actions are fine to delegate. Some should stay behind a human approval no matter how good the agent is, because the cost of one quiet mistake is too high:
- Releasing or approving payments
- Changing beneficiary bank details or any vendor master data
- Changing users, roles or the approval matrix in a bank portal or TMS
- Overwriting or deleting a statement, a booked transaction or a reconciliation
- Executing an FX deal or a funding transfer
An agent can prepare all of these: draft the payment run, flag the suspicious beneficiary change, propose the hedge. The decision stays with a person. If a vendor’s answer to “can it do this without approval?” is “yes, if you configure it”, the right configuration is no.
Rule, RPA, agent, or a person?
Most tasks don’t need an agent at all. Before choosing, ask what kind of task it really is.
| The task | What it needs | Treasury example |
|---|---|---|
| Same input, same output, every time | A rule | Sweep balances above a buffer to the header account |
| Same steps across systems, stable screens or files | RPA or a workflow tool | Download statements, build the position, email it |
| Steps that vary, messy input, a clear objective | An agent, with rules and a log | Assemble the daily report when banks deliver late or in different formats |
| Judgment with real consequences | A person, with help | Decide whether to release a large urgent payment |
In practice the best setups mix them. A rule does the arithmetic, a workflow moves the files, the agent handles the exceptions and explains what it did, and a person signs off where it matters. Using an agent for a task that a rule could do is like hiring a consultant to add up a column.
Not sure which row your task sits in? The Rules, Automation or AI? tool takes one concrete task through six questions and tells you why it lands where it does.
Checklist before you switch it on
- Is the objective one sentence, with a deadline and a destination?
- Is there a written list of allowed actions, and a list of forbidden ones?
- Does every missing or stale input produce an alert, never a silent workaround?
- Is there a human approval point for anything touching payments, master data or access?
- Does each run leave a log someone actually reads?
- Have you tested it on the bad days: the missing file, the duplicate statement, the bank holiday?
- Who owns it when it’s wrong?
The bottom line
Agents are a real step forward. They handle the variation that breaks RPA every month, and they can explain what they did, which RPA never could. But the flexibility that makes them useful is the same thing that lets them fail without telling you.
RPA forgave a missing process map by stopping. An agent won’t stop. So map the process first: objective, actions, approvals, log. Then let the agent run it.
Go deeper:
- AI Agents for Treasury: How They Actually Work, a real agent architecture with a full traced example
- AI Agents in Treasury: From Chatbots to Autonomous Workflows, including guardrails and approval workflows
- Rules, Automation or AI?, the learning path for deciding what a task actually needs