1 Overview
The arrival of capable language-model agents has led many teams to ask whether their existing robotic process automation estate is now obsolete. The honest answer is that agents and bots solve different halves of the same problem. An agent is good at reading messy context, deciding what should happen next, and handling variation in language or format. A bot is good at doing the same deterministic sequence of clicks, keystrokes, and file movements every single time without improvising. Neither one replaces the other cleanly.
Consider an accounts payable workflow. An agent can read an emailed invoice, extract the vendor, amount, and due date, match it against a purchase order, and decide whether the invoice is ready to pay or needs a human to look at it. But when it is time to enter that invoice into a finance system that has no usable API, the agent should not be the thing typing into the screen. That job belongs to a bot, which follows a fixed script, reports success or failure, and can be tested and versioned like any other piece of software.
The practical pattern is agent-led orchestration with bot-led execution. The agent owns judgment, routing, and exception triage. The bot owns repeatable interaction with user interfaces, legacy systems, and file shares. Teams that keep both layers get the flexibility of agents without giving up the reliability and auditability that made RPA useful in the first place.
2 Is this task worth automating?
Before wiring an agent to a bot, decide whether the underlying task deserves automation at all. A good candidate is high volume, rule-bounded, and painful enough that people notice the time it consumes. It should also have a clear definition of done, meaning you can state in one sentence what a successful run produces. If the task changes shape every week, or if nobody can agree on what correct output looks like, automation will simply freeze the confusion into code.
Look at frequency and variance together. A task that runs twice a year is rarely worth the build and maintenance cost, even if it is tedious. A task that runs hundreds of times a month with low variance is a strong candidate. High variance is not automatically disqualifying, but it changes the design: the agent handles the variation, and the bot handles only the stable steps. If almost every case is an exception, you probably need better process design before you need automation.
Also weigh the cost of being wrong. Automating a low-stakes internal report is different from automating payment release or customer data changes. For higher-stakes work, plan for human review at defined checkpoints rather than full autonomy. The question is not whether agents are impressive, but whether this specific task, with its specific error tolerance, is a sensible place to spend engineering and operations attention.
3 Mapping the workflow
Map the workflow before you choose any technology. Start by writing down the trigger, the systems touched, the decisions made, and the artifacts produced. Then mark each step as either judgment or mechanics. Judgment steps involve ambiguity, context, or trade-offs. Mechanics steps involve a known sequence against a known interface. This split is what tells you where the agent ends and the bot begins.
Be specific about system boundaries. Note which applications have stable APIs, which only expose a user interface, and which are accessed through a terminal, a shared drive, or an email inbox. Bots are usually the right answer for interface-only systems, while APIs are preferable wherever they exist because they are less brittle. Agents can call either, but the reliability characteristics differ sharply, and your error handling must reflect that.
Finally, identify the handoff points. Every place where the agent passes control to a bot, or a bot reports back to the agent, is a place where state can be lost or duplicated. Define what data moves across each handoff, in what format, and how the receiving side confirms it. A workflow map that ignores handoffs will produce an automation that works in demos and fails quietly in production, which is the most expensive kind of failure.
4 Choosing the trigger and action
The trigger is the event that starts a run. Common choices include a new item in a queue, an inbound email, a file landing in a watched folder, a scheduled time, or a status change in a business system. Prefer event-driven triggers over polling where the source supports them, because polling wastes resources and introduces latency. Where polling is unavoidable, set an interval that matches how quickly the business actually needs the work done, not the fastest interval the scheduler allows.
The action is what the bot actually performs once the agent has decided. Keep actions small and idempotent where possible. An action that can be safely repeated without creating duplicate records is far easier to operate than one that cannot. If an action cannot be made idempotent, add a deduplication key so retries do not double-post. This single design choice prevents a large share of production incidents.
Separate the decision from the execution in your design even if they run in the same process. The agent should produce a structured instruction, and the bot should consume that instruction without reinterpreting it. This keeps the bot testable in isolation and makes it possible to swap the agent, change the model, or adjust prompts without rewriting automation logic. It also gives you a clean audit trail showing what was decided and what was executed.
5 Handling errors and edge cases
Errors fall into a few families, and each needs a different response. Transient errors, such as a timeout or a locked record, should be retried with backoff a limited number of times. Deterministic errors, such as a missing field or a changed screen layout, should not be retried blindly because the same failure will recur. Business exceptions, such as an invoice that fails a policy check, should be routed to a human queue with enough context to act quickly.
Agents introduce a new failure mode: confident wrong answers. A model may extract the wrong value, misclassify a document, or invent a plausible-looking field. Guard against this with schema validation, range checks, and cross-references against authoritative systems before any irreversible action. Where the cost of a mistake is high, require human approval before the bot commits the change. Human review is still required for payment release, regulatory filings, customer-facing communications, and any action that is difficult to reverse.
Design the exception path with the same care as the happy path. Every run should end in one of a small number of explicit states: succeeded, retried, routed to a human, or failed with a reason. Log the inputs, the decision, and the outcome so that operators can reconstruct what happened. Silent failures are the main reason automation programs lose trust, and they are almost always a design choice rather than an inevitability.
6 Maintaining the automation
Maintenance is where most automation programs quietly die. Bots break when a vendor changes a screen, a field label, or a login flow. Agents drift when prompts, models, or upstream data change. Treat both as living systems with owners, monitoring, and a change process. Assign a named owner for each automation, and define what alerts should fire and who responds to them.
Version everything. Prompts, bot scripts, configuration, and credentials should all be tracked so you can tell what changed when behavior shifts. Run a small set of representative test cases on a schedule, including at least one known exception case, to catch breakage before users do. When a bot fails repeatedly on the same step, fix the root cause rather than adding retries, because retries mask drift and delay detection.
Review the automation periodically against the process it supports. Processes change, systems get replaced, and an automation that was valuable last year may now be redundant. Retire it deliberately rather than letting it run unattended. The goal is not to accumulate automations but to keep a small, well-understood set that reliably does work people would otherwise do by hand, with human review retained wherever judgment or risk demands it.
7 Frequently asked questions
Do agents make RPA obsolete? No. Agents handle interpretation and decisions, while bots handle deterministic interaction with interfaces that have no API. Most real workflows need both, and the combination is more capable than either alone. Teams that replace working bots with agents often rediscover why the bots existed.
Can an agent call a bot directly? Yes, and that is the common pattern. The agent produces a structured instruction, and the bot executes it. Keep the interface between them explicit and versioned so each side can be tested and changed independently. Avoid letting the agent improvise the bot's steps at runtime.
How do I know when human review is required? Review is required whenever an action is irreversible, financially material, legally significant, or customer-facing, and whenever confidence is low or validation fails. Build the approval step into the workflow from the start rather than adding it after an incident.
What should I monitor? Track run volume, success and failure rates, retry counts, exception queue depth, and time to resolution. Alert on changes in these trends, not just on hard failures, because gradual drift is easier to fix early.
Where should a new team start? Pick one high-volume, low-variance task with a clear definition of done and a low cost of error. Build the bot first, add the agent for routing and exceptions, and expand only after the first workflow runs reliably for several weeks.