AI employee vs RPA

What is the difference when the warehouse is busy?

I think about this on a clipboard, not a slide. A person walks a path. Scan, click, confirm, next. If that path never changes, record it. That is RPA. It is honest work. It has been honest work for years.

Now the input is a photo of a delivery note, or an email that says 'send the usual' and the usual is not usual. A click path cannot read that. A person can. An AI employee can attempt the read, fill a shape, and stop if the confidence or the policy says stop.

The mistake I see is swapping the words. A team has RPA. They hear 'agents'. They try to make the bot 'smarter' so it can survive a redesigned vendor portal. Then they have two problems: a broken path and a model that will invent a quantity.

When is a click path still the right tool?

When the screen is yours, or it changes on a calendar you control. When the fields are the same. When being 100 percent the same is the point, like posting a journal entry that must match a file.

RPA is also right when the risk of a fluent error is worse than the cost of a missed click. A missed click is loud. A person sees the red box. A fluent error is quiet. The number looks fine. It is the wrong number.

I like loud failures in operations. I have kept clinics online. Loud is how you wake someone. Quiet is how you discover the miss in a reconciliation two weeks later.

What happens when the screen changes?

RPA dies. That is the known tax. You either pay a team to update selectors or you accept downtime on that path. There is no poetry here. The button moved.

An AI employee that was clicking through a browser dies too, if that is how you wired it. 'Agent' does not make a DOM stable. If you needed an API, you still need an API. I said this at Zeeh in a different costume: banks plug in if the call is boring. The same is true for the systems you ask a worker to touch.

If there is no API, be honest. You have a brittle integration. A model that describes the screen in English does not remove the brittleness. It changes the story you tell yourself about it.

What does messy input do to each tool?

Messy input is why people want an AI employee. Invoices that do not match the template. Clinic documents that were photographed under fluorescent light. Support emails that start in the middle of a fight.

RPA wants the template. Give it a different template and you get nothing, or you get a click on the wrong field. An AI employee will try. Trying is the feature and the risk. It may pull the right total. It may pull the date that looks like a total.

So you do not 'trust the model'. You force a shape. Amount. Currency. Date. Vendor. Confidence. Then a rule: if the total does not match the line sum, stop. If two dates appear, stop. The intelligence is the stop, not the paragraph.

• RPA: empty output or a crash when the layout changes.
• AI employee: a filled form that might be right, which is more dangerous if unchecked.
• The fix for both: a system of record write that can be rejected.
• The owner reads rejects. That is the job that remains.

How do you decide which failure you can live with?

Ask which miss you will see first. A bot that cannot find the submit button fails in the open. A worker that submits a plausible refund fails in the ledger.

For money and health I prefer the open failure unless the click path is so stable that RPA is boring. Boring is good. I have sold companies. Buyers like boring paths they can explain.

For document piles, the AI employee is the better first pass if a person still sees the rejects. That is how review time dropped on compliance work I have done. The model was not the hero. The reject queue was.

Can you use both without pretending they are the same job?

Yes. Extract with the employee. Click with RPA if you must. Keep the decision log on the extract. When finance asks why a payment went out, you do not want 'the bot clicked'. You want the fields, the policy, and the person who approved the gate.

Do not run a program called 'automation' that mixes these and reports one savings number. You will not know what to fix when the number moves.

If you are choosing a first hire, pick the messy pile with a written policy. Leave the stable click path alone. It is already working. Working things are allowed to stay ugly.

Write the choice down so the next manager does not reopen it. 'RPA on portal X until they ship an API. AI employee on the invoice pile with a reject queue. Person on anything over this amount.' That paragraph will save you a quarter of meetings.

What should you tell finance about the choice?

Tell them the unit of cost. RPA is often licensed per bot or per run, plus the people who repair selectors. An AI employee is tokens or a project fee, plus the person on the gate. If you only show one number, someone will pick the smaller sticker and ignore the babysitters.

Tell them the unit of failure. A broken click is a job that did not post. A fluent miss is a job that posted wrong. Finance already knows which one they find in reconciliation. They should choose with that memory, not with a vendor category.

I sold companies. Diligence likes a path you can draw. 'The bot clicks this screen' is a draw. 'The worker reads the PDF, writes these fields, a person signs over this line' is also a draw. 'We have automation' is not a draw. Do not take that third sentence into a finance review.

If they ask which to kill first when money is tight, kill the path that needs a babysitter and does not move a pile. Keep the first pass that a person still reviews. Hours you can see are easier to defend than scripts you cannot explain.