RPA and AI Agents in Enterprise Architecture: Not Instead of Each Other, but Together

Sergey, head of the operational technologies department at the insurer RGS (Rosgosstrakh), has published an article on Habr asking whether robotic process automation (RPA) and AI agents built on large language models (LLMs) compete with each other or complement each other in corporate system architecture. The author's main conclusion: in the enterprise landscape these technologies are not rivals but complements, forming two layers of one system.

How RPA differs from AI agents

RPA (Robotic Process Automation) has become a mainstream tool in recent years for automating routine business processes. Software "robots" follow strictly defined scenarios and repeat the same steps on structured data, for example transferring data between systems, filling in forms from a template, or generating reports with a fixed algorithm. AI agents based on LLMs work on a fundamentally different principle: they reason over unstructured data such as texts, images and free-form user requests, and can make decisions in situations for which no rigid scenario has been written in advance.

Why choosing one technology is a choice without a choice

The author states the article's key thesis this way: if an organization is forced to pick only one of the two approaches, it inevitably loses efficiency. RPA and AI agents solve different classes of tasks, and replacing one with the other means either overpaying for an LLM where a simple template script would suffice, or running into RPA's rigid limits where unstructured information has to be interpreted.

Key points of the article:

• The author is Sergey, head of the operational technologies department at RGS (Rosgosstrakh).
• Publication platform: Habr, AI section.
• RPA is effective for repeated processing of well-structured, repetitive tasks.
• LLM-based AI agents are effective for working with unstructured data and tasks that require reasoning.
• Conclusion: in enterprise architecture these are two complementary layers, not competing alternatives.

How RPA and agents work together in practice

In the author's view, the most productive architecture for a large organization does not replace one technology with the other. Instead, it builds a system in which each layer handles the tasks it suits best. RPA robots keep running high-volume, predictable, easily verifiable operations, where speed, low cost and 100% repeatability of results matter. AI agents step in where a process requires interpreting context: parsing a customer request written in free text, deciding in a non-standard situation, or synthesizing information from scattered sources before passing a structured result down the chain, including to the same RPA robot for final execution.

For the insurance industry, where the author works, such a hybrid architecture is especially relevant. Processing claims, assessing insured events and handling customer requests combine strictly regulated, document-formalized steps that are ideal for RPA with elements that require understanding natural language and the context of a specific situation, which is the domain of AI agents. The Habr article apparently also examines a concrete case of this combined architecture at RGS, showing why two technologies often pitted against each other in public debate turn out in practice to be parts of one production chain rather than mutually exclusive alternatives.

RPA as a category of enterprise software began spreading widely in the mid-2010s, when companies around the world needed to automate legacy processes quickly, without the ability or the budget to rebuild their internal information systems entirely. The robots simply imitated human actions in existing interfaces, clicking, copying and pasting data. That made deployment fast but inflexible to any changes in the systems themselves.

The arrival of LLM-based AI agents a decade later does not cancel this accumulated automation infrastructure. It gives companies like RGS a chance to build a more flexible layer on top of it, one able to handle exceptions and non-standard cases that a classic RPA scenario simply could not process and handed to a human operator.