Short answer: RPA replays a fixed sequence of actions on structured screens and fails when anything changes. AI agents interpret unstructured input, decide the next step against your SOPs, and keep working when the input, layout or situation changes. In logistics, where most input arrives as email, PDF and portal screens that nobody controls, that difference decides whether an automation survives its first quarter.
Side by side
| Dimension | RPA | AI agents |
|---|---|---|
| Input it handles | Structured fields, fixed screens, consistent file formats | Email bodies, scanned PDFs, images, portal screens, chat messages |
| How it decides | Predefined if/then rules written by a developer | Reasoning against your documented SOPs and shipment context |
| Response to change | Breaks; needs a developer to re-record the flow | Adapts; the goal stays the same when the layout or wording changes |
| Exception handling | Drops the case into a human queue | Classifies, assembles evidence, proposes or executes the fix |
| Build effort | Per-process scripting, per-screen mapping | Configure role, SOP and authority limits |
| Maintenance | High — the main reason RPA programmes stall | Low — prompts and SOPs adjusted by operations staff |
| Audit | Log of steps executed | Log of inputs read, rule applied, approval and record changed |
| Best fit | High-volume, unchanging, fully structured tasks | Variable, document-heavy, judgement-light operational work |
Why RPA stalls specifically in logistics
RPA works well in finance and HR, where the systems are internal and the screens are stable. Logistics has neither property:
- You do not own the interfaces. Carrier portals, terminal systems and customs platforms change without warning. Each change breaks a script you paid to build.
- Most input is unstructured. A rate arrives as a sentence in an email. A packing list arrives as a photographed PDF. RPA needs the data to already be in a field.
- Variance is the job. Rollovers, holds, damages, split shipments, amendments — the work that consumes the team is precisely the work outside the happy path an RPA bot was recorded on.
- Maintenance cost compounds. Every new lane, carrier or customer adds another variant. The bot count grows, and so does the team keeping them alive.
The common end state: a portfolio of bots covering the easy 20% of transactions, with a maintenance bill that quietly exceeds the savings.
Where RPA is still the right tool
This is not an argument to remove RPA. Keep it where it performs:
- Moving data between two internal systems with stable APIs or screens
- Batch file handling and scheduled report extraction
- High-volume, low-variance keying into a system that genuinely has no API
A pragmatic architecture uses both: agents interpret and decide, RPA or direct APIs execute the mechanical write into a legacy screen.
A worked example: the invoice that does not match
The task: a carrier invoice arrives by email and must be checked against the contracted rate and actual shipment events before payment.
With RPA: the bot opens a structured invoice file, reads fixed columns, compares to a rate table and flags a mismatch. If the invoice arrives as a scanned PDF, or the carrier adds a new surcharge line, or the charge is disputable only in light of a terminal delay event, the bot stops and a human takes over. In practice, that is most disputable invoices.
With an AI agent: the Freight Audit Officer reads the PDF regardless of layout, maps each line to the contracted rate, pulls the gate-in and gate-out events to test whether the detention days claimed are real, drafts the dispute with the evidence attached, and routes it for approval because the value is above threshold.
The difference is not speed. It is coverage — the share of real invoices the automation can finish without a person.
How to choose, in four questions
- Is the input structured and stable? If yes, RPA or a direct integration is cheaper.
- Does the task need judgement against a policy? If yes, it is an agent task.
- How often does the interface or input format change? Frequently means RPA maintenance will erode the benefit.
- What share of cases must be handled for the business case to work? If the happy path is only 30% of volume, automating it changes very little.
Migrating a stalled RPA workflow
The usual path our customers take:
- Inventory the bots: volume handled, exception rate, maintenance hours per month.
- Pick the bot with the worst exception-to-volume ratio — that is where judgement is missing.
- Run an agent over the same workflow in shadow mode, on real cases, for four to six weeks.
- Compare coverage: what percentage of cases each finishes without a human.
- Retire the bot, or keep it as the execution step behind the agent's decision.
That sequence produces a number the business can act on, rather than a debate about technologies.