RPA, Integrations, IDP, or AI Agents: Picking the Right Method

The problem with calling it all "automation"

Someone in finance says "let's automate invoice processing." Someone in support says "let's automate ticket triage." Someone in HR says "let's automate onboarding." They're all using the same word for genuinely different builds.

RPA, system integrations, intelligent document processing, and AI agents solve different problems. Pick the wrong one and you get a brittle script that breaks every time a vendor changes their login page, or a rigid rule engine applied to a process that's actually full of judgment calls. Either way, you end up maintaining something that costs more than the manual work it replaced.

This is a Plan-stage decision. It happens before a line of workflow logic gets built, and it's the decision most teams skip — they default to whatever tool their current vendor sells, or whatever method the last consultant used, instead of matching the method to the process.

Operations leads scoping their first automation feel this. So do IT teams fielding requests from three departments who each want something different called "automation." So does anyone who's inherited an automation that technically works but needs constant babysitting — because it was built with the wrong tool for the job.

If you're the one deciding what gets built, this choice determines how much the thing costs you a year from now, not just what it costs to launch. For more on that ongoing cost, see the maintenance tax — it's the bill that shows up after the build, and the method you choose here is what sets its size.

Most teams pick a tool, not a method

Walk into most companies partway through automation adoption and you'll find one of two patterns.

Pattern one: RPA as a hammer. A team bought an RPA license two years ago, so every new automation gets built as a bot that clicks through screens — even for systems that have a perfectly good API sitting unused. The bot works until someone changes a button's position, then it breaks silently.

Pattern two: AI agent as a buzzword. A team hears "AI agent" at a conference and wants one for a process that's actually simple, deterministic, and high-volume — the kind of thing a straightforward integration with clear rules would handle more reliably and far more cheaply.

Both patterns come from the same root cause: nobody paused to diagnose the process before choosing the method. The fix starts with naming what each option is actually good at.

The four methods, and what each one is for

RPA (robotic process automation). A bot that interacts with a system's user interface the way a person would — clicking, typing, copying between screens. Useful when there's no API to connect to and the system isn't going anywhere soon. Its weakness is fragility: it breaks when the interface changes, and it scales poorly across variations.

System integration. A direct, API-level connection between two systems — no screen involved. This is the most durable option when it's available. It's faster, more reliable, and cheaper to maintain than RPA, but it only works if both systems expose an API (or you're willing to build one).

Intelligent document processing (IDP). Built for unstructured or semi-structured input — invoices, forms, PDFs, emails — where the data isn't sitting in a clean field somewhere. IDP extracts the fields regardless of layout, then hands clean data to whatever comes next. It's the right tool when the bottleneck is reading documents, not moving data between systems.

AI agents. Built for judgment, not just data movement — classifying, drafting, deciding what to do with something that doesn't fit a rule. Useful when a process has real variation and a human was making a call, not just typing numbers. The risk is applying an agent where a simple rule would do — more cost, more to monitor, for no better outcome.

Matching the method to the process

A few questions settle most of these decisions before you build anything:

That last question matters more than people expect. Every method named above still needs a clean handoff for the cases it can't resolve — an invoice that doesn't match its PO, a ticket that doesn't fit a known category, a document a model can't confidently read. If you haven't designed that handoff yet, building an exception queue is the place to start, regardless of which method you pick for the automatable core.

Here's where the trade-offs usually land once you run a process through those questions:

The pattern worth noticing: the "money pits" quadrant is mostly about mismatch, not about automation being a bad idea. The invoice processing and ticket triage work in our own production book pairs IDP or an AI agent for the judgment-heavy part with a straightforward integration for the data movement — never one tool trying to do both jobs.

Processes rarely need just one method

Real processes are usually mixed. Accounts payable needs IDP to read the invoice, an integration to check it against the PO, and a human handoff for anything that doesn't match. Support triage needs an AI agent to classify and draft, and an integration into the helpdesk to route and log. If you're trying to decide which parts of a messy process to automate outright and which to leave for manual handling or process improvement, the hybrid workflow guide walks through exactly that split — it's the natural next step once you've picked your methods for the automatable piece.

A decision order, not a checklist

When you're scoping the next automation, work through this order rather than picking a tool first:

1. Map the process and identify where the friction actually is — reading documents, moving data, or making judgment calls.
2. Check for APIs before assuming you need RPA. If one exists, integration almost always wins on cost and durability.
3. Separate the judgment steps from the rule-based steps. Rules get automated with integrations and workflow logic. Judgment gets an AI agent or stays human.
4. Size the exception rate honestly. If a third of cases will need a human anyway, design that path before you build the happy path.
5. Ask how long the systems involved will last. A method that's fine for a two-year bridge may be the wrong call for a core process you'll run for a decade.

None of this requires picking the fanciest method available. It requires picking the right one for the process in front of you — and being honest that most processes need more than one.