There is a robot in your finance function that has run every weeknight for three years without a complaint, and somebody sensible built it. It opens two systems, matches what one says against what the other says, and writes the result into a third. Nobody thinks about it, which is the highest compliment an operations team can pay a piece of software. So when you describe the work you want handled next, the offer is reasonable: extend the robot, add branches. What is on offer is a machine repeating a decision somebody already made. What you asked about is work where nobody has made the decision yet.
Repeatability, and what it costs at the edges
Say the honest thing about the robot first, because it stays true to the end of this page. It is deterministic. Given the same input it produces the same output, tonight and next March, and that property is worth more than most on offer. An auditor can be shown the sequence and told what it will do, and a finance director signs off a control because the control has no opinions. Where volume is high and the shape never changes, nothing an agent does is an improvement, and the robot is cheaper per item by a wide margin.
The ceiling arrives with the input it did not expect. A rule holds only for the cases somebody enumerated, and the others still turn up: the invoice carrying two purchase orders, the clause written in a form nobody has seen, the supplier who renamed themselves. The robot has no judgement to fall back on and nothing to consult, so it either stops or proceeds confidently on a resemblance.
The Cabinet, ArkOne’s reference design for an executive agent, answers a case rather than a pattern. Ten specialists sit at the Table, the fan-out letting a meeting consult them at once, capped at the size of the roster rather than a smaller number. Board, Counsel, Finance, Marketing and the rest, alphabetically each read the same awkward invoice and answer from their own instructions. That is slower than a rule, and it is what you buy where a rule cannot be written.
The six rows
Suppose an equipment distributor of three hundred people, invented for this exercise. A robot has matched supplier invoices against orders and receipts every night for three years, and it clears the great majority without a person. What is on no slide is the exception queue: the items the robot set aside, which two people work through each morning, and which nobody has counted since it went live.
| The row | A rule-based robot | The Cabinet |
|---|---|---|
| Who decides | Whoever wrote the rules, when they wrote them; the run decides nothing | A specialist at its authority setting, on the case in front of it: act, propose and wait, or escalate. Every one ships at propose |
| What it can touch | The screens and fields named in its script, in the order named | Named systems through named tools, with approval rights written per person |
| What it remembers | Nothing between runs beyond a log; tonight begins where every night begins | Decisions written after the work and read back at the next start: the eight most recent, plus open initiatives |
| What it costs to run | Very little per item, the same whatever the item is | More per case, because reading and reasoning are billed. It buys judgement rather than throughput |
| What happens when it is wrong | It repeats the same wrong step on every matching item until a person notices | The reason is returned rather than swallowed, so work is rescheduled instead of retried. The ledger is append only: a correction is a new entry and the original stands |
| Who owns it afterwards | The person who can read the script, and increasingly nobody | Instructions written as text a policy owner edits, the authority settings, the roster, the ledger, each with a named owner or none |
Exhibit 1. Illustrative. Six rows separating a tool that repeats a rule from one that forms a judgement.
The third row is where the two things stop being comparable. A robot begins each night identically by design, which is exactly right for matching a document against a record and useless for a case that only makes sense in the light of something decided a fortnight ago. When your buyer agreed an exception with one supplier in March, the robot treats April the way it treated February, correctly by its own lights and wrongly by yours.
The fifth row reaches a board paper eventually. A rule that is wrong is wrong at scale and in silence, because determinism applies to mistakes as faithfully as to successes. Three hundred items handled the same defective way is not three hundred errors to a robot; it is one instruction, working.
The fourth row is honest in the other direction. Judgement costs more per case than a rule and takes longer, so on the invoices that match cleanly, paying for reasoning is paying for nothing.
When the robot is the right machine
Two situations settle it in the robot’s favour, and both are ordinary.
The first is high volume with a fixed shape. Moving records between two systems, reconciling a file arriving in the same format every week, keying figures a form has already validated. The variation was designed out upstream, so no judgement is left to exercise and a rule is the correct, cheap, auditable answer.
The second is a control somebody has to defend. Where a regulator or an auditor asks what the process does, a script doing one thing is easier to evidence than a system that decides. That advantage does not disappear because a ledger exists; predictability is bought for reasons unconnected to cost.
The question that tells you which situation you are in is about the queue rather than the robot: how many items did your automation set aside last quarter, and what did the people who handled them have to work out?
If the queue is small and the items in it are broken data, the answer is better data upstream and the robot stays. If it is large, or small but full of cases where somebody had to weigh two considerations against each other and decide, then the queue is the actual work, and it has sat outside the automation the whole time.
Ask for the exception count for the last three months, and ask the people who clear it what they had to decide. The number is rarely on a report, which is why the afternoon is worth spending. A queue of malformed records argues for keeping what you have. A queue of judgement calls is a specification. The Cabinet and a chatbot runs the same six rows against a tool holding no authority at all, and every setting cited here sits on the Register.
component: null
Asked plainly
Is robotic process automation the same as an AI agent?
No. Robotic process automation follows a written sequence of steps and produces the identical outcome on every run, because repeatability is the whole point of it. An AI agent forms a judgement about the case in front of it, which means two similar cases can be handled differently and correctly. The first is what you want for a process that never varies. The second is what you want where the variation is the work.
What happens when an RPA robot meets a case its rules do not cover?
One of two things, and the second is the expensive one. Either the robot stops and the item joins a queue for a person, which is orderly and simply moves the work rather than removing it. Or the input resembles the expected shape closely enough that the robot proceeds and produces a confident, wrong result. Ask any automation supplier for the size of that exception queue over the past quarter, because the queue is the honest measure of coverage.
Why would an AI agent cost more per run than an RPA robot?
Because it reads and reasons rather than repeating steps. A rule-based robot executes fixed instructions, so its cost per run is small and stable. An agent may consult several specialists about one case, re-read what it has been given, and write down why it decided as it did. That is more expensive and slower per item, so it earns its place on the work where a wrong answer costs more than the reasoning does.