You have an Intelligent Document Processing stack feeding data into an RPA bot that types it into an ERP. The bot has worked for two years. Then the finance team redesigns the accounts payable portal. The selectors break. The bot stops. A developer spends three days rewriting the logic, testing it, and redeploying. Meanwhile, the backlog of AP documents piles up. This is the reality for many enterprises today. The gap between IDP and RPA is filled by brittle automation that needs constant babysitting.
Why IDP plus RPA breaks here
IDP engines are great at reading documents and extracting structured fields. They rely on OCR and NLP models that are updated regularly. RPA, however, is built around brittle bindings to UI elements. Most platforms use selectors and XPath patterns to find buttons, input fields, and tables. When a vendor changes a CSS class, a button moves, or the portal switches from a web app to a SPA, the bot fails. Enterprises report that UI changes cause 30 to 50 percent of bot failures. Each failure triggers a rebuild cycle that IT estimates at 2 to 5 days of developer time per incident. Over a year, that can mean dozens of developer-weeks spent on maintenance instead of new automations. The IDP engine still requires its own integration point, often separate from the RPA orchestration layer. This creates two interfaces to maintain and two places to handle exceptions. When a document is rejected by OCR, a workflow must route it to a human. When the RPA bot hits an error on a form, it may halt or escalate. The combined stack becomes harder to debug and harder to scale.
What changes with computer use agents
- Survives UI changes
- No brittle selectors
- Recovers from exceptions
- Follows the SOP as written
- Works on legacy and Citrix
Computer use agents see the screen and act like a human instead of binding to selectors. They can follow a standard operating procedure written in plain English without a flowchart bot to build.
How agents see and act on documents
A computer use agent connects to a real desktop or virtual machine. It can open a PDF, scan the document, and read fields using OCR or multimodal understanding. It does not need a prebuilt IDP model trained on your document types. It can adapt to new forms on the fly. Once data is extracted, the agent clicks through an ERP or portal to type it into the right fields. It can handle multi-step workflows: validate, reject, approve, attach files, and change statuses. Because the agent moves the mouse and types like a person, it works on legacy apps, Citrix environments, and web portals where RPA struggles. It also recovers from exceptions. If a form shows an unexpected error message, the agent can read it, take a defined step, or escalate to a human. It can retry on timeouts, switch between tabs, or pause and wait for approval. The resilience comes from the agent’s ability to reason about the current state of the screen, not from brittle selectors.
From IDP plus RPA to a single agent workflow
A single computer use agent can run the full document workflow end to end. You still use your existing IDP engine if you already have one, but you can replace the RPA layer with an agent. The agent can pull documents from storage, run them through the IDP engine, and then type the results into your ERP. Or it can ingest documents directly and extract fields itself. The workflow remains the same, read, validate, type, approve, but the engine changes. You no longer need to maintain two integration points. You also simplify exception handling. The agent can route rejected documents to the same human queue used by the current system. Over time, you can expand the agent to handle multiple document types and multiple enterprise applications. The benefit is a workflow that adapts when UIs change and does not require a developer each time the portal is updated.
Where RPA still fits
RPA still has a place for very high-volume, deterministic backend tasks. Think of a bank that processes millions of account updates through a stable mainframe interface. A bot that logs in, runs a batch job, and logs out can run continuously with minimal changes. The value of computer use agents is in the long tail of work: changing UIs, exception-heavy processes, and tasks that are documented in SOPs. A phased migration strategy makes sense. Start with a document workflow that is high-risk and high-friction. Run the current IDP plus RPA stack in parallel while you pilot a computer use agent on the same process. Measure uptime, error rates, and mean time to resolution. If the agent reduces downtime and developer effort, expand it to other workflows. Keep RPA for the stable backend tasks where it already works well.
The combination of IDP and RPA is increasingly brittle and expensive. A single computer use agent can run document workflows on any screen, adapt to UI changes, and follow SOPs directly. To see how this works in your environment, book a demo with the Coasty team at https://cal.com/coasty/15min .
Want to see this in action?
View Case Studies