1 Overview
Agentic AI is good at judgment and bad at typing. It can read a messy email, infer intent, decide which of several policies applies, and draft a response. What it should not do is log into a transactional system, hunt for the right field, and click through a dozen screens to record the result. That work is deterministic, repetitive, and unforgiving of small mistakes, which is exactly the profile that robotic process automation was built for.
The practical pattern is a division of labor. The AI agent handles the ambiguous front end: classifying an incoming request, extracting the relevant values, resolving which record it belongs to, and deciding the next step. The RPA layer handles the back end: authenticating, navigating the interface, entering values, attaching documents, and submitting the transaction. The agent never needs direct write access to the system of record, and the robot never needs to reason about intent.
This matters because giving an agent broad access to an enterprise resource planning system or a similar transactional platform is risky. A reasoning model can hallucinate a value, misread a field, or take an action that is technically valid but commercially wrong. Constraining the write path to a narrow, auditable robot reduces the blast radius. The agent proposes; the robot performs; a human reviews the exceptions. That separation also makes the automation easier to test, because the robot's steps can be verified independently of the model's judgment.
2 Is this task worth automating?
Start with volume and variation. A task performed a handful of times a month rarely justifies the build and maintenance cost, even if it is tedious. A task performed hundreds of times a month with a small number of predictable shapes is a strong candidate. The sweet spot is high volume, low variation, and a clear definition of done, such as a record that either exists in the destination system or does not.
Next, look at the cost of an error. If a wrong entry is caught immediately and corrected with a few clicks, the automation can tolerate a moderate exception rate. If a wrong entry triggers a payment, a shipment, or a regulatory filing, the design needs stronger validation and a mandatory human checkpoint before submission. The question is not whether the robot can do the task, but whether the business can absorb the failure mode when it does the task incorrectly.
Finally, examine the stability of the interfaces involved. RPA depends on the target system behaving predictably. Frequent screen redesigns, unstable session handling, or heavy reliance on visual coordinates raise maintenance costs. Where a stable application programming interface exists, prefer it over screen scraping, and reserve UI automation for the systems that offer no other path. A task that is valuable, high volume, low variation, and reasonably stable is worth automating. A task that is rare, highly variable, or catastrophic when wrong usually is not, at least not end to end.
3 Mapping the workflow
Before writing any automation, document the current process step by step as a human performs it. Capture the trigger, the systems touched, the fields read, the fields written, the decision points, and the places where the human pauses to check something. This map becomes the contract between the agent and the robot, and it exposes the hidden steps that people perform without noticing, such as copying a reference number from one window to another.
Then draw a clear boundary. Everything before the boundary is agent territory: interpreting unstructured input, choosing a category, extracting values, and deciding whether the request is complete. Everything after the boundary is robot territory: opening the destination system, entering the approved values, and confirming the result. The boundary should be a structured payload, not a free-text instruction. If the agent hands the robot a well-defined set of fields with types and validation rules, the robot can reject malformed input instead of guessing.
Identify the read-back step as well. After the robot submits, it should retrieve the created or updated record and compare it against the intended values. This confirmation closes the loop and gives the agent something concrete to report. It also produces the audit trail that reviewers need. A workflow map that includes the trigger, the payload, the write steps, the read-back, and the exception path is complete enough to build from.
4 Choosing the trigger and action
The trigger should be an event that is unambiguous and durable. A new item in a queue, a status change, or a scheduled batch window all work well because they can be detected reliably and replayed if processing fails. Avoid triggers that depend on a human remembering to start something, and avoid polling loops that hammer a system. Where the source system can emit a notification, use it; where it cannot, poll at a sensible interval and track what has already been processed.
The action should be the smallest complete transaction the destination system supports. If the system offers a bulk import, use it rather than entering records one field at a time. If it only accepts interactive entry, keep the robot's scope narrow: one record, one submission, one confirmation. Narrow actions are easier to retry safely and easier to reason about when something goes wrong. Idempotency matters here. The robot should be able to detect that a record already exists and skip it rather than creating a duplicate.
Keep credentials and permissions separate from the agent. The robot should run under a dedicated identity with only the access it needs, and that identity should be rotated on a schedule. The agent should not hold the transactional credentials at all. This separation means a compromised or misbehaving agent cannot write to the system of record directly, and it gives auditors a single place to look when they ask who changed a record.
5 Handling errors and edge cases
Assume the happy path is the minority of real traffic. Records arrive with missing fields, values in unexpected formats, duplicate identifiers, and attachments that fail to open. The robot should validate before it writes, and it should fail loudly rather than improvising. A clear rejection with a reason is far more useful than a creative guess that lands in the system of record.
Classify failures into categories. Transient failures, such as a timeout or a locked session, can be retried with backoff. Data failures, such as a missing required field, should be routed to a human queue with the original input attached. System failures, such as a changed screen layout, should page the automation owner because they indicate the robot itself needs updating. Treating all three the same way leads either to endless retries or to silent data corruption.
Human review remains essential at specific points. Any transaction above a value threshold, any record that fails validation twice, any case the agent classifies with low confidence, and any action that cannot be reversed should stop and wait for a person. The reviewer needs enough context to decide quickly: the source document, the extracted values, the proposed action, and the reason it was flagged. Design the exception queue as a first-class part of the workflow, not an afterthought, because it is where trust in the automation is won or lost.
6 Maintaining the automation
Automations decay. Target systems get redesigned, field labels change, authentication policies tighten, and business rules shift. A robot that worked flawlessly last quarter can start failing silently this quarter if nobody is watching. Maintenance is not optional overhead; it is part of the cost of the capability, and it should be budgeted from the start.
Monitor outcomes, not just executions. A run that completes without an error can still be wrong if it wrote the wrong value or skipped a record. Track the ratio of successful writes to exceptions, the age of items in the human review queue, and the frequency of retries. Alert on changes in these patterns rather than on individual failures, so the team is not flooded with noise. Keep a versioned record of the robot's steps and the agent's prompts so a regression can be traced to a specific change.
Schedule periodic reviews. Revalidate selectors and interfaces after any upgrade to a connected system. Rotate credentials and certificates on a defined cadence. Re-examine the human review thresholds as volume and confidence change. When a process is retired or a system is replaced, decommission the automation deliberately so it does not linger and create confusion. The teams that get long-term value from this pattern are the ones that treat the automation as a product with an owner, a backlog, and a health dashboard, rather than as a one-time project.
7 Frequently asked questions
Why not just give the AI agent direct access to the transactional system? Because reasoning models can produce plausible but incorrect values, and a direct write path turns a small mistake into a committed transaction. Routing writes through a narrow, auditable robot constrains what can go wrong and creates a clear record of what was changed and why. The agent's strength is judgment; the robot's strength is repetition. Keeping those roles separate plays to both.
Does this pattern replace human workers? It replaces specific keystroke-level tasks, not whole roles. People move to exception handling, quality review, and process improvement, which are the parts of the work that require context and accountability. The automation handles the volume; humans handle the judgment calls that fall outside the defined rules.
What if the destination system has no stable interface? Then the automation is more fragile and needs more monitoring. Prefer an application programming interface where one exists, and treat UI automation as a fallback. If the interface changes often, weigh the maintenance cost against the value of the task before committing.
How do we know the automation is working correctly? Compare what the robot intended to write against what the destination system actually contains, and review the exceptions regularly. Correctness is measured at the record level, not at the run level, and the human review queue is the best early warning that something has drifted.