Routine automation and AI: robots, app builders and language models

This article is also available in Russian: Russian version.

The three classes in this article get bought for the same reason: there is work being done by hand, and there is no budget to rewrite the corporate systems. A robot moves data between windows. A builder assembles an application without developers. A language model answers questions about your documents and drafts the first version of things. All three promise a result quickly and without a large programme — and all three end in disappointment more often than anything else on the map.

The disappointment has one common cause. None of these tools changes the process — all three set it in concrete. The robot dutifully walks through three unnecessary approvals. The builder lets you assemble, in a week, an application built around a badly thought-out way of working. The model answers confidently from policies that contradict each other. The speed you bought them for works in both directions.

That is why they should be looked at together. These are not three competing answers but three rungs of one ladder: each has its own entry threshold and its own price of failure. We will go through what each class does, who needs it and what has to be in place first. At the end — how they connect, the vendors you will actually meet, and a shared checklist.

What's in this article

• Routine automation: RPA and document processing — moving data between systems and parsing inbound documents

• App builders: low-code and no-code — applications without developers, and what that freedom costs

• LLM platforms and AI agents — a governed loop for working with language models

• How the three loops connect — the automation ladder and the order of moves

• What AI has in common across all three — what it amplifies, and which risk it raises

• Vendors you will actually meet — the names that show up on shortlists in each subclass

• Typical mistakes and a selection checklist — the shared diagnosis, and what to check before buying

Routine automation: RPA and document processing

This is the most seductive class on the whole map. The robot is shown in a demo, it does in a minute what takes a person half a day, and the buying decision gets made in the meeting itself. A year later it turns out that twenty robots need a dedicated person to keep them alive and that they fall over after every update to the accounting system. Let us go through what actually works here, where the line runs between a robot and a proper integration, and why automating an unsorted process costs more than the process itself.

What a robot does — and what it does not

RPA — robotic process automation — is software that works inside other software's interfaces the way a person does: it opens windows, copies fields, clicks buttons, carries data from one system to another. IDP — intelligent document processing — is the neighbouring class: it pulls data out of documents (invoices, delivery notes, contracts, certificates) and passes it on into the transactional systems.

What a robot does not do: it does not change the process. It repeats it faster and without typos. If the process contains three redundant approvals, the robot will faithfully walk through all three. It does not replace an integration: where two systems can be joined by an API, a robot is a prosthesis, and an expensive one to maintain. And it does not think. Any deviation from the script is not "I'll work it out" but "I've crashed".

Subclasses: what the automation loop consists of

Unattended robots. They run on a schedule on a dedicated machine: overnight reconciliation, pulling bank statements, allocating payments, filling in reporting forms.

Effect: the routine that used to eat the accountant's morning happens before the accountant arrives.

Drawback: a robot fails silently — and if nobody watches the run log, you find out from a counterparty.

Attended robots at the desk. Launched by an employee and doing a slice of the work in the middle of a task: assembling a customer file out of three systems, filling in a standard form.

Effect: a fast, legible win exactly where a complex process resists full automation.

Drawback: the benefit is smeared across many people and is almost invisible in reporting — justifying a second wave of the programme is hard.

Intelligent document processing (IDP). Recognition, classifying the document, extracting fields, reconciling against the transactional system, routing the doubtful cases to a human.

Effect: the inbound flow of paper and scans turns into rows in a system, and people only handle the exceptions.

Drawback: accuracy is never one hundred per cent, and an extraction error costs more than manual entry — because nobody goes looking for it.

Orchestrator and monitoring. The console that launches robots, distributes queues, keeps the log and reports failures.

Effect: ten robots become a managed estate rather than ten scripts on ten computers.

Drawback: it usually gets bought at around the thirtieth robot, once the chaos has already set — and then it has to be untangled retrospectively.

Process analysis: process mining and task mining. Reconstructing how the process actually runs, from system logs and from what people do at their desks — so that you automate what genuinely eats time rather than what is being complained about loudest.

Effect: automation candidates get chosen from data instead of from a manager's intuition.

Drawback: it needs logs of decent quality and an honest conversation about how the working day is spent — the second is harder than the first.

Who needs robotics, who is too early — and what to implement it after

You need it when moving data between systems consumes the labour of two or more people in full-time-equivalent terms. That is the working threshold: below it, the project pays back more slowly than the process changes. Other symptoms that it is time: the same figures are keyed by hand into two systems; the month-end close hinges on an overnight reconciliation; the flow of identical documents keeps growing while the finance team does not.

Too early, or not at all: if the process changes every quarter; if there are only two systems involved and a supported integration already exists between them; if the routine rests on one person and the question is really about redistributing duties. And separately: if nobody has ever documented the process — document it first.

What it connects to and when to implement. Robotics comes after the processes you intend to automate have stabilised. The rule is simple: a robot on an unstable process breaks weekly. The order of moves is worth keeping in your head as the routine automation ladder: remove the unnecessary step → connect the systems with a supported integration → add a robot → add document processing. The robot is the third rung, not the first. Its input is the documents and the interfaces of existing systems; its output is records in the transactional systems. In the trade-and-services trajectory of the two implementation tracks, robotics appears early, next to document flow and the digital workplace: CRM → document management and e-exchange and the digital workplace / RPA → order in the reference data → ERP, BI and EPM → decision-support systems built on generative AI. The caveat is the same: early does not mean "on any process". The robot goes onto a process that is already stable, even if the class itself appears early in the chain. Both trajectories are set out in the implementation-order map in the hub article. Robotics does not build a loop; it takes the pain out of a loop that already exists but whose joins are still manual.

What robotics gives the business — and its typical drawbacks

Effect. Speed and predictability on the operations where humans make mistakes out of fatigue. Relieving people of work that requires no qualification but does require time. And a side effect that is often the most valuable one: to describe the scenario to a robot you finally have to describe the process — plenty of programmes pay for themselves at that step alone, before the robot ever runs.

Drawbacks that get discussed less. Brittleness: a robot is tied to an interface, and any system update can break it — total cost of ownership is made not of licences but of support. Preservation: an automated process becomes harder to change, because now you have to change the robot too — a bad process acquires concrete formwork. Shadow automation: employees and departments run their own robots around IT, frequently under personal credentials — an operational and a security risk at once. If you are audited under SOC 2, or you hold ISO/IEC 42001, expect the question of exactly whose account a robot logs in as. And the illusion of benefit: hours saved on an operation do not turn into money by themselves unless the freed-up time is redirected somewhere.

Why a robot on an unsorted process is an expensive mistake

This is the case where the technology performs exactly as promised and there is still no result. Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation" lists seven sins of digitalisation, and the fourth is no change in the processes. The system is placed on top of the old order of work and people carry on as before. Adoption stays at a tenth of the user base and the promised return never arrives. The prescription there is blunt: rebuild the process first, then automate.

The same order is backed up by an observation from the same source: most of the effect comes from putting the process in order, before any automation at all. Technology laid over an orderly process adds a comparable increment on top (on the cases in the book, shown there on AI projects — process optimisation delivers around 75% of the improvement, and the technology on top adds a further ~89%, now measured from that new level). Reverse the order and you get automated chaos — fast, reproducible and, precisely because of that, more durable than the manual kind.

In the language of this article the rule reads: before you put a robot on an operation, answer honestly why that operation exists at all. A sizeable share of automation candidates simply evaporates after that question — and that is the best outcome the project can have.

2026: the context

Classic RPA has stopped being a separate market and has become a feature inside automation platforms: the same vendors sell orchestration, document processing and AI agents in one package, and the licence you sign covers the bundle whether or not you use it. The decision has moved from "which robot" to "which platform, and how much of it will we actually run". At the same time IDP got noticeably smarter: language models removed the main pain of classic recognition — having to build a template for every new document type. The trade-off came with it: template-based extraction failed loudly and visibly, model-based extraction fails plausibly.

Sizing it. A pilot robot on a simple, stable process is a matter of two to four weeks; a complex cross-system process runs to six to twelve. The cost drivers are the number of processes you automate, the transaction volume each one carries, and the licence model — per bot, per orchestrator, per run — which differs enough between vendors that the same estate can cost a multiple more on one than on another. What gets cheaper is not the robot but the process: a stable process is automated several times faster than a volatile one. Cost a full year of operation, including support after every system update, rather than the pilot.

App builders: low-code and no-code

Every company has a queue to IT. In it sit thirty small jobs, each of them "about a week": a travel-request log, a pass register, a contractor agreement list, an idea submission form. Not one of them is big enough to be a project; together they hang there for months. Low-code is an attempt to drain that queue: assemble the application from ready-made blocks without pulling in developers. Below — where it works, where it breaks, and how freedom without rules ends.

What the class does — and what it does not

Low-code is a construction kit: interfaces, forms, reference lists, approval routes and integrations are assembled with a mouse, and code is written only where nothing else will do. No-code is the same principle without the option to program at all.

What the class does not do: it does not replace corporate systems and will not carry complex logic. Product costing, production planning and legally binding document flow do not get built on a builder — that is the territory of ERP, MES and document management. And it does not abolish the IT function: an application assembled by an accountant still has to be supported, updated and secured by somebody.

Subclasses: what the class consists of

Business application builders. Register-style applications, logs, forms, simple workstations.

Effect: a job that waited six months in the development queue is closed in two weeks by an analyst.

Drawback: every such application is a new object in the landscape; with no register of them, in a year nobody can list what exists.

Low-code process platforms. Approval routes, tasks, procedures — effectively BPM inside a builder; the boundary with a full business process management platform runs along process complexity and analytics requirements.

Effect: the process is described and launched in the same motion, without the "requirements — development — acceptance" cycle.

Drawback: the ease of launching invites the automation of half-thought-out processes — chaos can be set in concrete faster here than anywhere else.

No-code for working teams. Table-databases, simple forms, automations between services — usually arriving bottom-up, from the employees themselves.

Effect: a team solves its own problem without occupying anyone's queue.

Drawback: the classic shadow IT system: it lives on an employee's personal account and disappears when they do.

Portals and front-ends. Internal portals, self-service areas, service catalogues layered over existing systems.

Effect: a single point of entry without rewriting the systems underneath.

Drawback: a front-end inherits the data quality of its sources — on dirty reference data it simply shows the mess to a wider audience.

Integration connectors. Ready-made links to mail, messengers, transactional systems, the bus.

Effect: the application does not stay an island.

Drawback: the temptation to wire everything to everything directly, bypassing the integration layer — and to end up with a fresh point-to-point cobweb.

Who needs the class, who is too early — and what to implement it after

You need it when the development queue has passed three months and is filled with dozens of small patchwork jobs, each too minor to be a project. Symptoms that it is time: departments keep their records in personal spreadsheets; standard requests travel by email; IT declines on capacity rather than on merit.

Too early, or not needed: if the queue is short and the jobs can be closed by standard functionality in systems you have already paid for — a platform will only add cost and add objects. And clearly too early if the company has neither shared reference data nor an integration layer.

What it connects to and when to implement. The entry threshold depends on scale. A small company needs no more than shared reference lists and integration rules. For mid-market and above, the class is normally introduced after a basic integration bus is in place. Without that foundation, low-code breeds new silos — applications with their own copies of the data that nobody can reconcile afterwards. Its input is data from MDM and the integration layer; its output is processes that mature into full business process management, and applications that IT eventually takes on for support.

Where low-code sits in the buy-or-build decision

There are always three delivery strategies: buy a ready product (Buy), configure and extend it (Modify), or develop from scratch (Build). Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation" contains an observation worth remembering this choice for. Ready-made solutions take root far more often than bespoke development: on the sample of cases in the book, around 67% success for buying against 8% for building from scratch. From the same source comes a practical rule: the team almost always wants to Build, because it is more interesting — and that wish is worth resisting.

Low-code lives exactly in the middle, in the Modify zone: you are not buying a finished product for the job and not constructing a system from nothing, you are assembling what you need from the platform's blocks. Hence the right question when choosing: does a ready-made solution cover nine tenths of the need? If it does, take it. If it does not, but the task is not unique — this is where a builder earns its place. And only when the task really is unique to your business does the conversation turn to development.

What the class gives the business — and its typical drawbacks

Effect. Speed: weeks instead of quarters on small jobs. Relief for IT: the queue gets shorter and developers go back to what genuinely needs developing. And engagement: people who assembled a tool for themselves use it differently from people who had one handed down to them.

Drawbacks that get discussed less. The zoo: two years in, the company has a hundred applications, a third of them abandoned, and the author of each is established from the change log. The cost of support grows quietly and outside the IT budget. The platform ceiling: what was easy at the start runs into performance limits and complex logic — and then everything has to be rewritten at once. And vendor dependence: moving what you assembled to another platform is close to impossible, because a builder is not portable code.

2026: the context

Two forces are shaping this class, and neither is about features. The first is the talent gap: a shortage of developers turns a builder from a fashionable toy into the only way to close jobs there is nobody to staff. The second is governance catching up with the freedom. Applications assembled outside IT handle personal data, and under GDPR the question of who is the controller of that data does not care whether the application took a week or a year to build. Where NIS2 or SOC 2 obligations apply, an unregistered application sitting on a personal account is an audit finding, not an internal inconvenience. The mature answer is not to forbid the builder but to put a register, an owner and a review gate around it. Meanwhile vendors are selling AI generation of applications from a text description, which lowers the entry threshold again — and raises the same governance question one more notch.

Sizing it. Entry cost is driven by the licence model — most platforms sell in minimum blocks of seats, and per-seat pricing means the bill scales with how widely you succeed, not with how much value you get. In a good case the first working application is assembled in about six weeks, but that is a specific case, not a norm: the timeline depends on how well the process itself is documented. Count the hidden part too — supporting applications that were not built by programmers, and paying for the seats of people who assembled something once and moved on. Cost a full year of operation, not the pilot.

LLM platforms and AI agents

This is the youngest class on the map and the only one that would not have made an overview like this two years ago. It is also the most underestimated on risk: a system that answers any question confidently is easy to mistake for a system that knows the answer. What follows: what the class is made of, what it demands of the company before launch, and which checks it has to pass before it goes into live work.

What the class does — and what it does not

The class gives a company a governed loop for working with large language models: where the model runs, which data it can reach, who assigns it what, how that is logged and controlled.

What it does not do: it does not replace transactional systems and it does not create data. The model works with what has already been accumulated — and that is the first thing expectations break against. The second: it does not reason in the human sense, it imitates reasoning by pattern extremely well, which is why a confident tone tells you nothing about whether the answer is right.

Subclasses: what the class consists of

Model serving platforms. The infrastructure: cloud models over an API or your own loop on your own servers, access control, limits, logs.

Effect: employees work with models inside the perimeter rather than through personal accounts.

Drawback: your own loop means hardware and people; the cloud means answering the question of what data you are handing over and where it is processed.

RAG assistants over the corporate knowledge base. The technique that gives the model access to your documents at answer time: first retrieve the relevant fragments, then answer on the basis of them.

Effect: answers rest on the company's own policies and cite the source instead of being invented; the base can be topped up instantly, with no retraining.

Drawback: answer quality equals document quality — on contradictory policies the assistant will confidently pick one version and will not tell you there were two.

Copilots inside the workplace. An assistant inside the tool — in mail, code, documents, CRM: it produces a draft, the person edits it.

Effect: it saves time on the routine part of the work while leaving the decision with the human.

Drawback: the benefit is smeared and measures badly; with no "before" baseline, the payback conversation turns into an argument about impressions.

AI agents. They do not answer, they act: calling systems themselves, executing steps of a process.

Effect: they close whole operations rather than advising on them.

Drawback: an agent needs boundaries, tools and a failure scenario; without an explicit definition of "done" it will execute the task too literally — and that will be your wording, not its mistake.

Multi-agent systems. Several agents with an orchestrator, for complex processes with parallel flows.

Effect: automation of what one role cannot cover.

Drawback: there is a non-obvious thing here: designing such a system works like designing an org structure for people — roles, areas of accountability, rules for resolving conflicts. Companies that cannot do this with people rarely manage it with agents.

MLOps and AI governance. Running models in production: versions, quality monitoring, retraining; and the management layer — which scenarios are permitted, who owns them, how launch decisions get made. This is also where an external standard becomes useful rather than decorative: ISO/IEC 42001 exists to give this layer a shape, and the EU AI Act makes having one a compliance question rather than a preference.

Effect: models live as products with an accountable owner, not as enthusiasts' experiments.

Drawback: the most frequently skipped subclass — until the first incident it looks like bureaucracy.

RAG or fine-tuning: which to choose

The two ways of landing a model on your specifics get confused constantly. RAG connects documents at answer time: the data is always current, updating means adding a file, the cost is low, and you can always see what the model relied on. Fine-tuning changes the model itself: it is about style, industry terminology and manner of response; it costs more, it is frozen at the training date, and it needs retraining when things change.

The practical rule is simple: facts and documents are RAG; style and terminology are fine-tuning. Most of the corporate tasks people start with are RAG, not fine-tuning — even though the second sounds more impressive.

Who needs the class, who is too early — and what to implement it after

You need it when data and documents have accumulated, there is a process worth strengthening, and there is an owner ready to be accountable for the outcome. Symptoms that it is time: employees hunt for answers across scattered policies; routine correspondence eats hours; the company already uses public models — just without any control.

Too early, or not needed: if the process is undocumented and the data has not been put in order, there is nothing for an AI layer to stand on. And a separate marker of "too early": no answer to who owns the scenario and by which metric you will know it is working.

What it connects to and when to implement. This is the top layer of the IT systems pyramid: it goes on top of whatever maturity already exists, not instead of it. The top rung of both trajectories is management decision support assembled on this layer. Its input is data from every system in the landscape, the knowledge base, and the rules from data governance; its output feeds every loop AI strengthens. And the order of work here is the same as for robotics: put the process in order first, then lay AI over it. The numbers behind that rule are above, in the section on the robot and the unsorted process. The terms cannot be swapped: on chaos you get accelerated chaos.

What the class gives the business — and its typical drawbacks

Effect. Speed of working with knowledge: an answer from company policy in seconds instead of half an hour of searching. Removal of routine: drafts, summaries, classification. And control over AI itself: instead of dozens of personal accounts, a loop with permissions, logs and rules.

Drawbacks that get discussed less. Hallucinations are not a bug that will be fixed in the next release but a property of the architecture: you design around them rather than wait for them to go away. Running cost is variable and grows with usage — the driver is token consumption, so the bill rises exactly as adoption succeeds; cost a full year of operation, not the pilot. Copilot benefit is hard to prove without a "before" measurement. And shadow usage: with no governed loop, employees work with models anyway — just through personal accounts, with corporate documents inside.

A separate layer is the executive's own working loop with a model: not the corporate contour but their own goals, decisions and preparation for meetings. It runs on the leader's context rather than on the company's document base, and it answers to a different owner and a different set of questions. The honest boundary: that layer does not connect to your systems and is neither an LLM platform nor an agent orchestrator in the sense of this section.

What to check before go-live: crash tests

Before an AI solution goes into live work, it is worth trying to break it. The implementation book describes this set of checks as mandatory, and it maps well onto any corporate scenario:

• A deliberate attempt to break it — malformed and provocative prompts: what does the system produce under pressure.

• Resistance to poisoned data — what happens if an incorrect or planted document gets into the knowledge base.

• A bias check — does the solution discriminate on grounds it must not.

• Explainability — will you be able to explain the system's decision if you have to defend it to a customer or a regulator.

• A failure scenario — what happens when the model is unavailable or has answered with nonsense: who picks the work up.

• Load — how the system behaves at peak, not in a demo.

Separately — the unacceptable events: what specifically, in your case, must never happen. A leak of personal data or trade secrets into a cloud model, a public hallucination in official communication, an autonomous decision with legal consequences. That list is written before the pilot — it determines which scenarios can be given to AI at all. This is also where regulation stops being abstract: the EU AI Act, GDPR and your data residency commitments are inputs to that list, not a separate compliance exercise afterwards.

Sizing it. A survey takes weeks, a pilot one and a half to three months, industrial operation six to nine. On money the fork is fundamental. On cloud models you pay a subscription plus consumption, and the driver is token volume — which means the cost curve follows adoption, not headcount. Your own loop on your own hardware is capital expenditure of a different order, plus engineers to run it. Budget support from the outset: without it the assistant degrades along with the knowledge base. In both cases, cost a full year of operation rather than the pilot — this is the class where the pilot budget and the operating budget differ most.

How the three loops connect

The most common mistake in choosing is comparing these classes against each other. "Robot or builder?", "RPA or an AI agent?" The question is put wrongly: they cover different layers of one job and stand at different levels of maturity.

The shared frame is the routine automation ladder. The order of moves is the same regardless of which class you are looking at: remove the unnecessary step → connect the systems with a supported integration → add a robot → add document processing. The robot is the third rung here, not the first. The builder and the language model slot into the same ladder, just at other points on it. Low-code covers the case where the step you need does not exist in any system at all. LLM covers the case where the step requires understanding text rather than moving fields.

Three questions that separate the classes. The data sits in systems but has to be carried across, and there is no API between them — that is RPA. The application you need does not exist, and the task is too small for a development project — that is low-code. The task is about the meaning of text: find the answer in the policies, parse the email, produce a draft — that is LLM. If the answer to all three is no, there is nothing to automate yet: the process needs describing.

The entry threshold rises along the chain. A robot needs a stable process and access to the interfaces. A builder needs shared reference data and rules for publishing applications — otherwise it breeds copies of the data. A language model needs both of those plus documents that have been put in order: it literally answers from what has been accumulated. Which is why companies that start at the top rung usually come back to the lower ones — only now with the budget already spent.

Where they touch in practice. IDP is already the seam between RPA and AI: language models removed the main pain of classic recognition, the need to mark up a template for every new document type. Low-code platforms sell AI generation of applications from a description. RPA vendors sell agents in one package with the orchestrator. The boundaries between the three classes are blurring at the product level — but not at the level of what they demand from the company: each keeps its own entry threshold.

A shared input and a shared output. The input for all three is order in processes and reference data, which is to say data and documents. The output is records in the transactional loop and people freed up. None of the three classes builds a loop: they take the pain out of a loop that already exists but whose joins are still manual.

What AI has in common across all three

In the other articles in this series, this section answers the question "what does AI add to the class". Here it reads differently: one of the three classes is itself built on AI, and the other two are amplified by it. So I will set out what is common.

What AI already solves. In robotics — extracting data from documents without rigid templates: the model parses an invoice it is seeing for the first time, classifies the inbound flow and understands an email by meaning rather than by keywords. In builders — a first-pass form and data model from a text description of the job, prompts while configuring processes, an analysis of what has already been assembled to find duplicates and abandoned applications. In the LLM loop — assistants over the corporate knowledge base, document drafts, analysis of calls and correspondence, data analysis in natural language.

What is close (a forecast, not a fact): agents that assemble a robot's script or an integration from a description of the task; robots that survive an interface change without being rewritten; agents that run a standard process end to end with control points.

The conditions without which none of it flies — and they are the same for all three. Data: shared reference lists and access to the receiving systems; without reference data, AI will cheerfully assemble an application with its own copy of the item master, and an assistant will confidently answer from an obsolete policy. Processes: a documented scenario and explicit exception rules — what to do when the system is not sure. People and security: every robot, application and AI scenario has an owner by name; permissions no wider than those of the employee the system is standing in for; separate service accounts, logs, and somebody who actually reads those logs.

The honest boundary — and the main conclusion of this section. AI here lowers the entry threshold, and by doing exactly that it amplifies the class's risk rather than curing it. Previously, to breed a crop of ungoverned applications you needed at least an analyst; now a text description is enough. Previously a robot stopped when it failed — unpleasant, but honest. A language model in its place does not stop; it produces a plausible answer, and there is nobody to notice.

Hence a practical rule for all three classes: the higher the cost of the operation, the lower the system's autonomy should be. Data extracted from a million-dollar invoice gets checked by a person, however good the recognition is. An application that handles personal data goes through review, even if it was assembled in a day. A scenario with legal consequences is not given to an agent at all. This is the same axis as the autonomy scale above — assistant, copilot, agent, multi-agent system — and the choice of rung is a risk decision, not a technology one.

Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation" describes a trap that captures the shared failure of all three classes — "AI as a sticking plaster": a technological solution applied to an organisational problem. A robot on an undocumented process, a builder with no architectural rules, and an assistant over contradictory policies are three forms of the same plaster. The cure is not giving up the tool but the order of operations: process first, automation second.

Vendors you will actually meet

The names below show up on most shortlists in these classes. No ranking, no market shares, no claims about who leads. The LLM class in particular is young, and the list changes faster than overviews get published — treat this as a starting set for comparison, not a market picture.

• RPA and integration automation — UiPath · Automation Anywhere · Blue Prism (SS&C) · Microsoft Power Automate · Nintex · Workato

• Intelligent document processing (IDP) — ABBYY Vantage · Rossum · Hyperscience · Google Document AI · Amazon Textract · Azure AI Document Intelligence

• Low-code and no-code — Microsoft Power Platform · OutSystems · Mendix · Appian · ServiceNow App Engine · Retool · Airtable · Bubble

• Model platforms — OpenAI · Anthropic · Google · Mistral · Meta Llama · AWS Bedrock · Azure AI Foundry · Google Vertex AI · Databricks · Hugging Face

• Agent orchestration and assistant building — LangChain / LangGraph · LlamaIndex · CrewAI · Microsoft Copilot Studio · Semantic Kernel

Two notes on the table. Several vendors appear in more than one row in real life — the automation platforms sell RPA, document processing and agents in one package, and which row a product belongs to depends on the edition you buy rather than the brand. And the last two rows are not comparable like for like: model platforms are where inference happens, orchestration frameworks are how you assemble a scenario on top, and one does not substitute for the other.

The choice in each of the three loops does not start with a product. In robotics it starts with a list of candidate processes: three scenarios and thirty scenarios need different platforms, and the difference in cost of ownership is a multiple. In builders it starts with answering who will assemble the applications: platforms for IT analysts and platforms for citizen developers are built differently, and handing the first kind to the second group ends badly every time. In the LLM loop it starts with two questions: where your data is physically processed, and what happens to your solution when the vendor changes the model under the hood. Add a third if you operate across borders — which residency commitments the vendor will put in the contract, as opposed to on the marketing page.

Typical mistakes and a selection checklist

The mistakes across the three loops differ in form and are identical in substance, so here they are in one list.

1. Putting in a robot instead of an integration. If there is an API between the systems, a robot in the interface is a temporary fix that somehow lives for years and gets more expensive as it goes.

2. Automating an undocumented process. The robot's script or the diagram in the builder becomes the first description of the process — and locks in every absurdity it contains.

3. Building on a builder what belongs in a corporate system. The platform ceiling reveals itself at the least convenient moment, and then everything has to be rewritten at once.

4. Handing out a builder with no rules. Freedom with no application register and no named owners turns into a zoo within a year to eighteen months.

5. Starting from the technology rather than the problem. The question "where should we apply AI" is almost always more expensive than the question "which process hurts".

6. Confusing RAG and fine-tuning. Facts and documents are RAG, style and terminology are fine-tuning; the mistake costs a budget and a quarter.

7. Counting the benefit in hours rather than money. Freed-up time with no redistribution of workload is not a saving, it is a report.

8. Not appointing an owner. A robot, an application and an AI scenario each have an author but no owner — six months later nobody knows what it does or whether it can be switched off. This is sin No. 6 from the same book, no governance, in its most everyday form.

9. Allowing shadow automation. Robots under somebody else's credentials, applications on personal accounts, model use through personal mail — the risk surfaces at the first audit.

10. Costing the pilot rather than operations. In all three classes the cost of ownership grows with usage and lives outside the project budget.

Checklist before choosing a system

1. The alternative has been checked: can this step be removed? can these systems be connected in a supported way? does a ready-made solution cover nine tenths of the need? The buying conversation happens after those three questions, not before.

2. There is a list of candidate processes with an estimate of effort and of how often each one changes — on paper, before meeting any vendor.

3. The pilot is assigned to a stable process, not to the most painful one. A loud process is usually loud precisely because it keeps changing.

4. The rules are stated: who may assemble applications, what gets published, where the register lives, which scenarios may be given to AI at all. And separately — the list of unacceptable events: what must never happen.

5. The support model is defined: who fixes the robot after a system update, who supports an application that was not built by a programmer, who refreshes the knowledge base. I would walk away from a project with that line empty — it degrades within a year.

6. A full year of operation is costed, not the pilot budget: licences per bot and per seat, model consumption, integrations, support, retraining.

7. Permissions and logs are set: separate service accounts, least privilege, logging — and a named person who looks at those logs.

What next

The overall map of classes is in Enterprise IT systems: the map. Other guides in the series: Production, assets and warehouse · Customers and sales · Money, planning and analytics · Data and documents · People and the IT function · IT infrastructure.

To go deeper, see Dzhimsher Chelidze's books "Digital Transformation for Directors and Owners" and "Artificial Intelligence. Freefall" — third edition, free download. If you still have questions, reach out to us for training or consulting.