“We have an old accounting system, it has no API, automation just isn’t in the cards for us.” We hear this phrase on almost every other assessment. The system has been running for fifteen years, it holds the company’s entire history, the developer has long been unreachable, and no one still on staff has ever seen the documentation. Replacing it means a year of work and the risk of paralyzing your accounting.
The good news: you don’t need to replace it. If an employee can log into the system, an agent can log in too. It sees the same screen, reads the same fields and presses the same buttons – it just doesn’t get tired, doesn’t get distracted and doesn’t slip up on the numbers after lunch.
How an agent “sees” the screen
A UI agent works with the interface on two levels. The first is structure: the window’s elements, fields, tables, buttons, their labels and states. The second is visual: the agent looks at the screen the same way a person does and understands that in front of it is an invoice form, that the “Counterparty” field is still empty, and that the system has shown a modal window with a warning.
The fundamental difference from classic robotic automation is that the agent understands meaning, not coordinates. Old scripts memorized “click at point 640:480” – and broke with the slightest shift in the layout. The agent looks not for a point but for “the ‘Post’ button in the document form.” The button moved, the color theme changed, a column was added to the table – the agent keeps working, because it navigates by the meaning of the elements, the way a person would.
| Method | What the system needs to provide | Speed | Where it fits |
|---|---|---|---|
| API integration | A documented API | Maximum | Modern CRMs, banks, government services |
| Working with the database | DB access, knowledge of the schema | High | Reading and reporting, rarely writing |
| UI agent | Only an account | Like an employee, and faster | Systems without an API, legacy applications |
On the platform these methods are combined: where there is an API, we work through integrations; where there isn’t, through the interface. From the process’s point of view the difference is invisible: the agent receives the task “post the invoice” and chooses the path to the result itself.
Scenario: transferring orders that used to take two hours a day
A typical case from our assessments. A wholesale company: orders come into the CRM, while the warehouse and accounting live in a 2009 system with no API. Twice a day the operator transfers orders by hand: opened the order in the CRM, switched to the accounting system, created a document, picked the counterparty from the directory, retyped 15–40 line items, checked the prices, posted it. Two hours a day, on the order of 44 hours a month, and a steady 2–3% of documents with typos – not because the operator is bad, but because no one can move numbers between windows for eight years straight without slipping up.
The agent takes the same route: it reads the order from the CRM, opens the accounting system, finds the counterparty (and if the spelling differs, matches by business ID), fills in the line items, reconciles the total against the order and posts the document only when they match. If they don’t match, the document stays a draft and a person gets a notification pointing to the specific line of the discrepancy. A transfer that took two hours now runs in the background throughout the day as orders come in.
Step log: the agent works on the record
The main objection to a “robot with a mouse” is that it can’t be controlled. It’s a fair one: no one in their right mind will trust accounting to a process they can’t verify. That’s why every step a UI agent takes is logged: which window it opened, which value it entered into which field, which button it pressed, what the system replied. Critical steps – posting, deletion, changing amounts – come with a screenshot before and after.
The platform’s rule: every agent action has an answer to three questions – what was done, on what basis, and how to undo it. If even one question has no answer, the action requires a human’s confirmation.
In practice this has an unexpected effect: the agent’s work is more transparent than an employee’s. When an operator makes a mistake in an invoice, reconstructing how it happened is nearly impossible. When an agent handled the document, there is a full trace with screenshots. Auditors and the security team usually come to appreciate this faster than anyone.
What happens when the interface changes
Systems get updated: a patch ships, a button moves, a form gains a new required field. For old robotic automation this meant “everything broke on Friday evening, we spend a week fixing it.” The agent behaves differently, and it’s worth describing honestly, level by level.
Cosmetic changes – shifts, renames, new visual themes – the agent handles on its own, because it looks for elements by meaning. More serious changes, for example a new required field, the agent recognizes as an unfamiliar situation: it sees that the system won’t accept the document and doesn’t start pressing buttons at random. The document is set aside, a person gets a notification describing what changed. After a short adjustment – usually hours, not weeks – the agent continues from the set-aside documents. No document is ever posted “blind” in a changed interface: that is a hard rule of the platform.
Limits we mention up front
A UI agent is not a magic wand. It’s slower than a direct API: seconds per document instead of milliseconds. For a flow of hundreds of documents a day that doesn’t matter; for tens of thousands of transactions an hour it does, and then you need a different path. It needs a stable environment: a dedicated account with rights no broader than an employee’s for that operation, and a workstation inside the company’s perimeter where nothing else is hammering the system in parallel. And it doesn’t fix chaos in the process: if operators filled in the counterparty directory any which way, the agent will expose that mess, but clearing out the duplicates is a separate task – which, as it happens, it can also handle.
You can test all of this on your own system with no commitment: we set up a prototype on your real scenario in about a week, for free – you’ll see the agent post your documents in your system. To production it’s from 8 weeks; the platform runs on a subscription from 12 million tenge a year. Most often the very first UI scenario is source documents in accounting; you can book an assessment on the contacts page.
Frequently asked questions
How is a UI agent different from an RPA robot?
RPA executes a rigid script by coordinates and selectors: one step off and it’s an error. The agent understands the meaning of the screen and the goal of the operation, so it survives cosmetic interface changes and knows how to stop in an unfamiliar situation instead of corrupting data. A detailed comparison is in the article on agents, chatbots and RPA.
Which account does the agent work under, and what about permissions?
Under a separate one, allocated specifically to it. Permissions are the minimum necessary for the operation: an agent that posts invoices has no access to the payroll ledger. All its actions are visible in the system’s log and in the platform’s log, so the question “who did this” is answered in a minute.
The system is very slow and sometimes freezes. Is that a problem?
No, that’s an ordinary environment for a UI agent. It waits for the interface to respond, recognizes a freeze, knows how to close the session and repeat the operation from a checkpoint – without creating a duplicate document. It’s precisely on “temperamental” systems that the gain is most noticeable: the agent is more patient than a person.