In the last weeks I read three articles titled "The best AI tools for business". All three had affiliate links, and none would have helped a dispatcher who wants to automate a customer portal tomorrow. So here is no ranking, but the toolbox behind an agent that does exactly that. Six building blocks, what each delivers in operations, and what happens when it is missing.
The example is an agent that operates the customer portal at a contract logistics provider: log in, check orders, confirm, take over quantity changes. Eight weeks, 39 runs, between 900 and 5,300 orders per run.
The portal has no API. So the agent needs what the dispatcher has: a browser. Browser automation opens the portal, logs in, clicks through the list and reads the fields. That is classic technology, not a language model, and that is good: it does the same thing on the same page every time.
What happens without it: there is no agent. Without this block, only the API remains, the one the customer has been announcing for two years.
What it cannot do: cope with change. If the portal changes its login form or the session breaks, the automation stops. For our agent, four of 39 runs ended with the message that page or browser had been closed. That is what blocks 2 and 5 are for.
The model reads what the automation does not understand. A message that is not in the script, for example "This order was cancelled by the customer". An order with free text in the quantity field. A PDF attached to the order. It classifies and proposes. It does not click.
What happens without it: every unknown message is an abort. With the model it becomes an entry in the review list with a reason.
What it must not do: book. A language model does not always answer the same input the same way. For reading that is acceptable, for confirming 5,000 orders it is not. Confirming is done by block 1 following rules that block 3 knows.
Every order the agent sees lands in a database with timestamp, status and source. Plus the rules: which customer has which tolerance for quantity changes, which orders are never confirmed automatically. And the match with the TMS: does the order exist there, does the quantity fit?
What happens without it: the agent has no memory. It confirms on Wednesday what it already confirmed on Tuesday, and nobody can trace why.
Every run writes an entry: start, end, orders checked, confirmed, changed, review cases, errors with text. It is a table, not a dashboard, and it is the part the customer reads most.
What the protocol showed the customer: Wednesday is correction day. The number of quantity changes jumps to up to 1,600 that day; on other days it is under 100. Nobody in dispatch knew, because nobody had counted. (The interesting part of an agent is rarely the agent. It is the table.)
A service that checks whether the agent delivered. Not whether it ran. If on a working day the number of confirmed orders stays at zero although the portal had open orders, an alarm goes out. To us and to the customer. If the agent hits the same error four times in a row, it stops itself instead of hammering the portal with login attempts.
What happens without it: the agent stands still and nobody notices. We had that in another process: it ran for a week without delivering, because a prior step had stopped silently. Since then the watchdog counts results.
Unspectacular, but there is no way around it. Portal login codes arrive by mail. Review cases go by mail to dispatch. The weekly report goes by mail to management. The agent needs its own mailbox it may read and send from, with the customer's sender, not ours.
What happens without it: the login code lands with a dispatcher who is on vacation.
No tool name with a star rating. Which browser automation, which model, which database we pick depends on the customer. What runs there already? Where may data live? Who operates it in two years? The six blocks stay the same. The brands behind them are interchangeable, and that is deliberate, because the customer has to be able to take over the agent.
A caveat: this is the toolbox for portal and document processes with one to four runs a day. Real-time tour planning or telematics streams at second intervals add blocks that are not listed here.
Which portal does your dispatch open by hand every morning? Tell me its name. I will tell you which of the six blocks get hard there, and show you the protocol of one run. Ask for a process check: 30 minutes, no sales pitch.
