What are the three approaches, precisely?
The words get used loosely. Here is what each one actually is.
RPA replays a recorded sequence of interface actions. Open the screen, read the field, copy it, paste it elsewhere, click submit. It does exactly what it was told, in exactly that order, every time. It has no model of what it is doing.
No-code automation connects applications through prebuilt triggers and actions. When a form is submitted, create the record, then post the message, then update the sheet. The path is drawn by a person in a visual builder and never changes on its own.
An AI agent is given a goal and chooses its own steps. It reads the case in front of it, including text nobody structured, decides the next action, calls a tool, checks the result and continues or escalates. Full definition in what an AI agent for business is.
How do the three compare across the dimensions that matter?
Eight dimensions decide almost every real choice. Read down the column that matches your process, not the one that matches the pitch you last heard.
| Dimension | RPA | No-code | AI agent |
|---|---|---|---|
| Unstructured input | Cannot handle it without an extra layer | Passes it through untouched | Handles it natively — the core reason to use one |
| Tolerance to change | Low. A moved button breaks the script | Medium. Vendor APIs absorb most changes | High. Adapts to variation inside the same goal |
| Maintenance cost | High. Rebuild on every interface change | Low to medium. Reconnect on API changes | Medium. Continuous evaluation and threshold tuning |
| Implementation time | Weeks to months per process | Hours to days | 4 weeks for a scoped deployment |
| Who can build it | An RPA developer or platform specialist | An operations person with no engineering background | An engineering team or a delivery partner |
| Predictability | Deterministic. Same input, same output | Deterministic within the path drawn | Probabilistic. Same input can produce different output |
| Cost per run | Very low and flat once built | Rises with volume — most platforms bill per task | Highest. Every call consumes input and output tokens |
| Best use case | High-volume repetition on a stable legacy screen | Connecting modern apps along a fixed path | Judgement over messy input, at volume |
When is RPA still the right answer?
More often than the current conversation suggests. RPA wins whenever all four of these hold.
- The system has no API and the interface is the only way in — common with older on-premise software.
- The data is already structured. Fixed fields, known positions, no interpretation required.
- The rule is fixed and audited. Same input, same output, provable in a compliance review.
- Volume is high and the screen is stable. Cost per run approaches zero and stays there.
Putting an agent on that job adds cost, latency and non-determinism in exchange for flexibility the process does not need. That is not modernisation. It is a worse fit at a higher price.
When is no-code enough?
When the systems already expose APIs, the path never branches on judgement, and the person who understands the process can build it themselves. Lead routing, form-to-CRM, notification chains, scheduled reports, approval reminders. Days to build, cheap to change, and it produces something valuable even if you later replace it: a documented workflow with the integrations already exposed.
No-code stops being enough at a specific point — when the exception rate stops falling. Every rule you add makes the builder more brittle and the logic harder to read. Twenty branches in a visual canvas is a maintenance problem that a person built by hand.
When do you actually need an AI agent?
Three conditions. You need at least two of them, and the first is close to mandatory.
- The input is unstructured. Email threads, scanned documents, free-text notes, chat messages. Anything a person has to read before deciding.
- The decision requires judgement across sources. The answer depends on combining a record, a history and a policy, not on reading one field.
- The cases vary. Same goal, different shape every time, so no fixed path covers enough of the volume to be worth building.
Invoice intake from a hundred suppliers who each format things differently. Ticket triage across a support inbox. Pipeline prioritisation that weighs deal history against activity.
Where are AI agents the wrong answer?
This section is the useful one. An agent is a poor choice in six situations, and the credibility of any vendor depends on saying so.
- Deterministic calculations. Tax, payroll, interest, pricing formulas. If the same input must produce the same output every time and survive an audit, write code. A model that is right 99% of the time is wrong for arithmetic.
- Low volume. A process that runs twice a month will not amortise a build. Keep it manual, or use no-code if the connection already exists.
- Fully specified rules. If the logic is already written down completely and never changes, encoding it directly is cheaper, faster and easier to test than teaching a model to infer it.
- Hard latency limits. An agent that reasons across several steps takes seconds. Inside a checkout or a real-time control path, that is a design failure, not a tuning problem.
- No tolerance for a wrong answer. Hallucination can be reduced by retrieval, structured output and review. It cannot be eliminated. If a single wrong output is unacceptable and undetectable, do not automate the decision — automate the preparation and leave the decision with a person.
- An undocumented process. An agent cannot infer rules that the organisation has never agreed on. It will produce confident output built on the wrong assumption, which is worse than the manual version.
There is a seventh, quieter one: an agent can degrade silently. An RPA script fails loudly when the screen changes. An agent keeps running while the input distribution shifts underneath it, and the quality falls before anyone notices. That risk is manageable with evaluation and an exception queue, but it is a real operating cost that RPA does not carry.
How do you combine all three in one process?
Most production automations are not one technology. They are a chain, and each link uses the cheapest tool that can do that step. A supplier invoice pipeline is the clearest example.
| Step | Tool | Why |
|---|---|---|
| Collect the file from the inbox | No-code | A trigger and an action. Nothing to interpret |
| Read the document and extract the lines | AI agent | Every supplier formats it differently |
| Match lines against the purchase order | AI agent | Descriptions never match exactly |
| Recalculate totals and taxes | Deterministic code | Arithmetic must be exact and auditable |
| Post the entry into the legacy ERP | RPA | No API. The screen is the only interface |
| Route mismatches for approval | Human-in-the-loop | Money moves. A person signs |
The agent is used only where interpretation is needed. That is what keeps cost per run under control and the audit trail intact.
Which one should you pick? A decision sequence
- Is the input unstructured? No → go to step 2. Yes → you need an agent for that step.
- Do the systems have APIs? Yes → try no-code first. No → go to step 3.
- Is the screen stable and the volume high? Yes → RPA. No → keep it manual until one of the two changes.
- Does any step require exact, auditable arithmetic? Yes → that step is code, whatever the rest of the chain uses.
- Does money, legal exposure or a customer relationship move? Yes → a person approves, regardless of the technology.
Common questions about agents, RPA and no-code
Is RPA obsolete now that AI agents exist?
No. On a stable screen with structured data and a fixed rule, RPA is faster, cheaper per run and completely predictable. An agent adds interpretation you do not need and cost you do not want. RPA loses only where the input is unstructured or the rules change often enough that rebuilding the script becomes the main expense.
Can no-code tools call an AI model?
Yes, and that combination covers a large amount of useful work. It is still not an agent: the sequence of steps is fixed by whoever built the automation, and the model only fills one slot inside it. An agent chooses the sequence at run time. If your process needs a fixed path, the no-code version is the better engineering choice.
Which approach is cheapest per run?
RPA, usually, because a script executing on a schedule costs almost nothing per execution once it is built. No-code sits in the middle and rises with volume because most platforms bill per task. Agents cost the most per run, since every call consumes tokens on input and output. Cost per run only matters at volume, so calculate it against your real run count.
Can we start with no-code and move to an AI agent later?
Yes, and it is often the right sequence. A no-code build forces you to document the workflow, expose the integrations and produce a baseline metric, which are the three things an agent deployment needs anyway. Migrate when the exception rate stops falling, because that is the signal the fixed path no longer fits the work.
What does running an AI agent require that RPA does not?
Continuous evaluation. An RPA script either runs or fails visibly. An agent can keep running while quietly getting worse, because the input distribution shifted. That means a test set of real cases, a confidence threshold, an exception queue somebody reads weekly, and a named owner. Budget the attention, not only the build.
Where to go next
Black Ops (blackopss.com) scopes the chain, not just the agent, and says in writing which steps should stay in code, in RPA or in a person’s hands. How each agent is built is described on the Black Ops services page. If you are building the budget, the seven variables that set the investment covers cost per run for each approach. If your operation runs across Latin America, local systems and document formats change the answer. Definitions for every term used here are in the AI automation glossary.