Agentic RPA (agentic automation) is an automation model in which an AI agent based on a large language model makes decisions in unstructured and nonstandard situations, while an RPA bot carries out verified actions in the interfaces of accounting systems: 1C, ERP, browser, email. The agent does not replace the bot; it fills the gap where classic automation stops: free-form emails, scans with different layouts, and exceptions to the rules. The bot, in turn, remains a predictable executor that can be tested and audited.
Prepared by AIrassvet based on publicly available sources, verified on October 2, 2026. It is intended for executives who already use RPA bots or are choosing between RPA and AI agents, as well as IT directors and process owners in accounting, logistics, procurement, and customer service. The products mentioned are presented as market examples; AIrassvet is not affiliated with their manufacturers, and the section at the end describes the publisher’s services.
Contents
- In brief: RPA, AI agent, and agentic RPA
- Why classic RPA hits a ceiling
- What an AI agent can and can’t do
- How agentic RPA architecture works
- When RPA is enough, when you need an agent, and when you need both
- Common processes for agentic RPA
- How to implement agentic RPA: six steps
- Risks and how to address them
- Frequently asked questions
- Primary sources and verification method
In brief: RPA, AI agent, and agentic RPA
| Approach | How it works | Strength | Weakness |
|---|---|---|---|
| RPA bot | Repeats a pre-recorded workflow in an interface or via API | Predictability, speed, clear audit trail | Breaks on exceptions, new formats, and interface changes |
| AI agent | The language model interprets the task, selects steps, and chooses tools | Understands free text and documents with different structures | Can make mistakes or hallucinate; by itself, it has no access to corporate systems |
| Agentic RPA | The agent makes the decision at the point of uncertainty, the orchestrator calls the bot, and the bot executes | Covers exceptions without losing control over actions | Requires orchestration, logging, and escalation rules to humans |
Main takeaway: agentic RPA is not about “replacing bots with a neural network,” but about division of labor. The agent makes the decision, the bot performs the action, and the orchestrator and humans provide control.
Why classic RPA hits a ceiling
An RPA bot works well where the process is described in detail: open the system, take a value from one field, paste it into another field, click a button. Such a bot works quickly and the same way every time. But it is tightly bound to rules, and that limitation shows up in three places.
- Unstructured input. A request arrived as a free-form email, an invoice came in as a scan with an unfamiliar layout, or a customer sent a voice message in a messenger app. The bot does not understand the meaning of the text; it needs fields in predefined locations.
- Exceptions. In real-world processes, you run into nonstandard cases: the counterparty is missing from the reference data, the amount does not match, or the item is named differently. For a bot, every exception means either a stop or a separate branch of the workflow that has to be programmed.
- Interface changes. The form in the accounting system or on the supplier’s website was updated, and the workflow tied to screen elements stops working until it is adjusted.
In a Habr article by Rosgosstrakh’s IT team dated April 6, 2026, the authors describe it this way: pure automation typically covers 60–70% of a process, then exceptions remain, and adding an agentic layer in mature implementations raises the share of the process completed without human involvement to 90–97% (Habr, RGS IT blog). This is an estimate from one company’s practice, not industry-wide statistics: in your process, the shares will be different, and they need to be measured using your own data.
What an AI agent can and can’t do
An AI agent is software in which the language model does more than answer a question: it plans steps, calls tools, and checks intermediate results. For more on how such a model works, see the article How GPT Works and How to Use LLMs in Business.
What an agent does well:
- extracts meaning from free text: it understands that the email is a shipping request and finds the address, timing, and line items;
- processes documents with different structures: invoices, acts, and specifications from different counterparties;
- makes decisions in the gray zone: which expense account to choose, which contract to assign a payment to, whom to escalate to;
- explains its decision in text that an employee can review.
What an agent cannot do on its own:
- reliably and consistently perform hundreds of clicks in an interface — for that, you need a deterministic executor;
- work with corporate systems without the tools and access rights granted to it;
- guarantee error-free results: the model may misread a document or make a confident mistake.
The last point is the main reason you should not give an agent direct, unlimited access to an accounting system. For how to manage the level of an agent’s autonomy, see the article Managing the Autonomy of AI Agents.
How agentic RPA architecture works
A typical three-layer setup, described by both Russian practitioners and international vendors, looks like this.
| Layer | Role | What happens in it |
|---|---|---|
| AI agent | “Intelligence layer” | Reads the input, classifies the case, extracts data, and decides which tool is needed |
| Orchestrator | Mediator and controller | Selects a bot from the tool registry, passes parameters, logs activity, handles errors and timeouts, and escalates to a human |
| RPA bots and APIs | “Workforce” | Carry out actions in 1C, ERP, the browser, and email under service accounts |
In Rosgosstrakh’s description, the agent initiates a call through the orchestrator, which selects the required script bot from the Tool Registry, passes the context and parameters to it, the bot performs the operations through the interface, and the orchestrator returns the result to the agent so the chain can continue. Important detail: robots operate under service accounts, and the agent does not receive system credentials (Habr, RGS IT blog).
The same principle is built into commercial platforms. UiPath describes its Maestro orchestrator as a cloud platform that brings together automation, AI agents, and human involvement in end-to-end processes modeled in BPMN notation (UiPath Maestro documentation). Russian RPA vendors are also moving toward combining robots with AI: for example, Sherpa Robotics published a piece back in 2024 about the shift from RPA to AI agents and its “neuro-employees” on the Sherpa AI Server platform (Habr, Sherpa Robotics blog).
Why the orchestrator matters. It provides three advantages:
- reuse: already written RPA scripts become agent tools without rework;
- model replacement without process rework: if you change the language model, only the agent’s skill changes, while access to the robots remains the same;
- audit: every robot action is tied to the agent’s decision and recorded in a log, so you can reconstruct the chain from the incoming document to the entry in the accounting system.
When RPA is enough, when you need an agent, and when you need both
| Situation | What to choose | Why |
|---|---|---|
| Stable process, structured data, rare exceptions | Classic RPA or API integration | An agent adds cost and error risk without delivering a gain |
| Free-form input, but the action is simple (for example, answering from a knowledge base) | AI agent without robots | There are no actions in accounting systems that need to be executed |
| Free-form input, action in an accounting system | Agentic RPA | The agent interprets the input, and the robot executes the action |
| Many exceptions in an already automated process | Add an agent layer to existing robots | The agent handles exceptions that are currently escalated to people |
| A high-cost-of-error process (payments, legally significant documents) | Agentic RPA with mandatory human approval | The agent prepares the decision, a person approves it, and the robot executes it |
If an accounting system has a proper API, a robot clicking through the interface is not necessary: a direct API call can be the agent’s tool. How to connect agents to 1C is covered in the article How to Connect AI Agents to 1C.
Typical processes for agentic RPA
Below are processes where the combination of “the agent decides, the robot does” appears most often. This is not a promise of results, but a list of candidates for evaluation.
| Process | What the agent does | What the robot does |
|---|---|---|
| Email request intake | Understands the email, extracts items, deadlines, and address | Creates an order in the accounting system |
| Source documents | Reads invoices and acts of varying layouts, reconciles them with the order | Posts the document in 1C or sends it for approval |
| Product matching | Finds the match between the supplier’s item name and the product card | Updates the master data or the order |
| Claims and returns | Classifies the request, checks the conditions | Processes the return or routes it to the responsible person |
| Reconciliation with counterparties | Explains discrepancies in the reconciliation statement | Exports data and generates documents |
| Customer requests | Identifies the topic and urgency | Registers the request in CRM or a service desk |
For each of these areas, AIrassvet has a separate deep dive on its site, for example Automating Email Requests with AI, Automating Source Documents in 1C and Product Matching with AI in 1C.
How to implement agentic RPA: six steps
- Choose one process and measure the baseline. How many cases per month, how much time each one takes, what share currently gets through without manual work, and how many errors are found during review.
- Map the decision points. Walk through the process step by step and mark where the action is unambiguous (that is the robot’s or API’s job) and where you need to understand the meaning or choose an option (that is the agent’s job).
- Collect a sample of real cases. You need real emails, documents, and exceptions from past periods, including difficult ones. The agent will be tested on them before launch. For data preparation, see the article Preparing Data for AI Implementation.
- Connect actions through the orchestrator. Package existing robots as tools, and define input parameters, permissions, and error-handling rules for each one.
- Run in suggestion mode. The agent proposes the solution, the employee confirms it, and the robot executes it. This lets you build accuracy statistics without putting your data at risk.
- Expand autonomy based on metrics. Remove human approval only from the types of cases where the agent consistently makes fewer errors than the acceptable threshold, and keep it for high-cost mistakes. Which metrics to track is covered in the article AI Agent Performance Metrics.
Acceptance criteria and responsibility boundaries should be documented in advance: the structure of this kind of document is described in the article Technical Specification for an AI Agent.
Risks and How to Address Them
| Risk | How It Shows Up | How to Reduce It |
|---|---|---|
| Recognition error | The agent misread the amount or payment details | Cross-check against ERP data, confidence threshold, human approval for ambiguous cases |
| Excess permissions | The agent can do more than the process requires | Actions only through robots and APIs with minimum permissions, service accounts |
| Malicious instructions in incoming data | An email or document contains text that tries to control the agent | The agent does not execute instructions from incoming documents; the list of allowed actions is limited by the orchestrator |
| Lack of transparency | You cannot understand why a decision was made | Log: input, agent decision, invoked robot, result |
| Interface fragility | A form update breaks the robot | Monitor robot errors, switch to APIs where available |
| Data leakage | Documents are sent to an external cloud service | Anonymization, and models kept in your own environment for sensitive data |
More on the third risk in the article AI Agent Hacking: Prompt Injection and Tool Attacks, and on observability in the article Monitoring LLMs and AI Agents.
Frequently Asked Questions
What is Agentic RPA in simple terms?
Agentic RPA, or agent-based RPA, is a combination of an AI agent and an RPA robot. The agent, based on a language model, understands free-form text and documents and decides what to do in an unusual situation, while the robot performs verified actions in business systems. An orchestrator sits between them, keeps a log, and escalates complex cases to a human.
Will AI agents replace RPA robots?
In most processes, no. Practitioners describe the approach as “not instead of, but together”: the robot remains a predictable executor of actions, while the agent takes on unstructured data and exceptions. If a system has an API, the robot’s role can be handled by a direct API call.
How is an AI agent different from an RPA robot?
An RPA robot follows a predefined workflow and stops when it encounters exceptions. An AI agent understands the meaning of text, plans steps, and chooses tools, but can make mistakes and does not have access to enterprise systems on its own. That is why an agent is usually given a limited set of tools through an orchestrator.
Which processes are a good fit for agentic RPA?
Processes where the input comes in free form and the output is an action in a business system: intake of requests from email, processing source documents, matching items, claims and returns, and customer case registration. Stable processes with structured data are often better automated with classic RPA or APIs.
Do already working RPA robots need to be thrown out?
No. In an orchestrator-based setup, existing RPA workflows become agent tools without rework. The agent layer is added where exceptions are currently routed to employees.
How do you start implementing agentic RPA?
Start with one process: measure the current volume, time, and share of manual work, map decision points, gather a sample of real cases, and launch the agent in suggestion mode, where the employee confirms the decision. Autonomy is expanded only based on measured accuracy metrics.
Source Material and Verification Method
Verified on October 2, 2026:
- Habr, RGS IT blog: “RPA and AI Agents in Enterprise Architecture (Not Instead of, but Together)”, published on April 6, 2026 — a three-layer model of “agent — orchestrator — robots,” a tool registry, service accounts, and the author's estimates of 60–70% and 90–97%.
- UiPath Maestro documentation — description of orchestrating automation, AI agents, and people in BPMN processes.
- Habr, Sherpa Robotics blog: “From RPA to AI Agents”, published on September 30, 2024 — the Russian RPA vendor’s move toward AI agents.
Comparison tables for approach selection, candidate processes, implementation steps, and risks — AIrassvet editorial analysis. The percentage estimates for automation share are presented as one company’s observation and are not a forecast for your process.
How AIrassvet helps implement agentic RPA
If you already have robots that stop on exceptions, or a process where employees manually sort through emails and documents before entering data into a business system, this task can be broken down step by step. On the AIrassvet website, which also uses the name “AI Studio by Vladimir Lomtev,” the following relevant services are described:
- Process audit with decision-point mapping: where an agent is needed, and where a robot or API is enough.
- Agentic RPA: AI agents that work with 1C, ERP, and browser interfaces, with action logging.
- Integration of agents with company communication channels and business systems.
- Deployment of language models in your own environment if documents cannot be sent to external services.
The first step is to choose one process, describe its current metrics, data sources, constraints, and the criterion by which you will consider the pilot successful.
Bottom line: the decision belongs to the agent, the action to the robot
Agentic RPA removes the main limitation of classic robotic automation — the inability to work with unstructured input and exceptions — without giving up predictable robots. The working setup is: the agent interprets the input and makes the decision, the orchestrator calls the right robot and keeps the log, the robot executes, and a human approves expensive and ambiguous decisions.
Start with one process, a measured baseline, and suggestion mode. The agent’s autonomy should be expanded only where metrics show consistent accuracy.