Agentic orchestration

What one agent actually does, step by step

It helps to follow a single order the whole way through, because the word "agent" hides how ordinary the individual steps are.

An email arrives: "Hi bro, same as last month but 20 cartons instead of 12, deliver Thursday." A rule-based system cannot do anything with that. The agent starts by working out who sent it — matching the address against your customer list, and noticing that this sender has ordered eleven times before.

Next it needs to know what "same as last month" means, so it looks up that customer's previous order and finds three line items. It adjusts the quantity on the one the message mentions and leaves the other two alone. Then it checks stock for all three, and finds one of them is short by six units.

This is the point where a script would either crash or silently do the wrong thing. The agent has a choice to make, and the choice is where the value is: it drafts the order with the two available lines confirmed, flags the short line with the actual available quantity, and writes a one-sentence note explaining what it did and why. Then it stops and waits for a person.

That is the whole loop — read, decide, act, check, escalate when unsure. Repeat it forty times before anyone arrives in the morning and you have the system we actually build. Nothing in it is magic. What is genuinely hard is the deciding, and specifically deciding when not to decide.

The five things that decide whether it works

Almost every agent project that disappoints fails on one of five things, and none of them is the model.

First, goal clarity. "Use AI on our orders" is not a goal, it is a wish. "Read every order that arrives by email or WhatsApp, draft it into the system, and flag anything you are not sure about" is a goal, because you can tell whether it was met. If we cannot write the sentence, we do not start the build.

Second, tool access. An agent is only as capable as the things it is allowed to touch. If the order system has no API and nobody will give us a login, no amount of intelligence helps. This is usually the thing that decides the timeline, not the AI work.

Third, data quality. The agent has to recognise your customers. If the same buyer exists three times under slightly different names, it will hesitate on all three, and you will conclude the agent is unreliable when the real problem is the customer table. This is why data pipelines keep showing up as the first project.

Fourth, escalation design. The most important thing an agent does is notice it should stop. Deciding in advance what "unsure" means — an unknown customer, a price that does not match, a quantity outside the normal range — is what turns it from a risk into an asset.

Fifth, observability. When something looks wrong, you need to see what the agent thought at the time. Every decision it makes is written down in plain language, so a supervisor can read the reasoning rather than guess at it. Agents that cannot explain themselves do not survive contact with a real business.

How much authority to give it, and when to widen it

The question we get asked most is not "can it do this" but "what if it gets it wrong". The answer is that you do not hand over authority on day one; you widen it as the agent earns it, and you can always narrow it again.

In the first phase the agent drafts and a person approves everything. This feels like it defeats the point, but it does not: approving forty drafts takes twenty minutes, where typing forty orders takes two and a half hours. You are already most of the way to the benefit, and you are watching every decision while you get comfortable.

After a few hundred orders you will have a clear picture of where it is reliably right. Usually that is existing customers ordering familiar items in normal quantities — which is most of the volume. That category can go through automatically while everything else still stops for a person.

The threshold is a business decision, not a technical one. Some clients let anything under a ringgit value through and review the rest. Others go by customer: the twenty accounts they know well are automatic, everyone else is checked. Both work, and both are set by you and changeable in an afternoon.

What we will not do is give an agent unattended authority over something irreversible on the promise that it is probably fine. Sending money, cancelling orders and emailing customers directly stay behind a person until you explicitly decide otherwise.

What it costs to run, honestly

There are two costs and they behave differently. The build is a one-off. The running cost is per transaction, and it is worth understanding before you commit, because it is the part that decides whether the economics hold as you grow.

Every time the agent reads an order and reasons about it, that reasoning is billed by the AI provider based on how much text goes in and comes out. For order processing the realistic figure is a few sen per order, not ringgit. At forty orders a day that is a rounding error against the labour it replaces.

Where it stops being a rounding error is very high volume with very low value per transaction. If you are processing ten thousand tiny items a day, per-item AI reasoning is the wrong tool and a conventional rule-based system is both cheaper and more predictable. We will tell you when you are in that territory.

The other running cost is maintenance, and it is real. Systems change, suppliers redesign their portals, your own processes shift. Budget a small amount of ongoing attention rather than assuming a built system stays correct forever. A retainer covers this, but you can also just call us when something breaks.

How it is tested before it touches anything real

No agent we build meets your live systems on day one. The testing sequence matters more than the build, and it is the part clients are usually most reassured to hear described.

The first stage is replay. We take a few hundred real orders from the last several months — ones you have already processed, so the correct answer is known — and run the agent against them with every write disabled. It cannot change anything; it can only say what it would have done. Then we compare its decision to what actually happened.

That comparison is where the real work begins, because the disagreements are informative in both directions. Sometimes the agent is wrong and we adjust it. But reasonably often the agent is right and the original human entry was wrong — a transposed quantity, a stale price, a line missed on a busy morning. Clients are frequently surprised by their own baseline error rate, and it makes the eventual comparison fairer.

The second stage is shadow running. The agent processes live orders in parallel with your team, still writing nothing. Every morning someone can see what it would have done with the real inbox, including the messages that are genuinely hard. A week or two of this settles most nerves, and it surfaces the edge cases that historical data never contains — the customer who replies to a three-month-old thread, the order sent as a photograph of a handwritten note.

Only then does it start writing, and initially only as drafts nobody has to accept. If at any point the numbers look wrong, turning it off is a switch, and your team carries on exactly as before because nothing was removed. That is deliberate: we do not dismantle the manual process until the automatic one has earned it.

What happens when something breaks

Every automated system fails eventually. What separates a manageable failure from an expensive one is entirely decided at build time, so it is worth being explicit about how these behave.

The first principle is that the agent fails loudly. If it cannot reach your order system, if a price lookup returns nothing, if the number of orders it sees is suspiciously far from normal, it stops and tells someone. It does not carry on with partial information and it does not guess. Silent failure — where a system appears to run for a fortnight while quietly producing nothing useful — is the one outcome we design hardest against.

The second is that everything is reversible. Actions are logged with enough detail to undo them, and during the early phase the agent's writes are drafts rather than commitments. If a bad batch goes through, you can identify exactly which records were touched and when, rather than reconstructing it from memory.

The third is that the manual path never disappears. Your team keeps the ability to process an order by hand, and the agent being unavailable is an inconvenience rather than a stoppage. Any consultant who tells you to decommission the old process on go-live day is optimising for their invoice, not for your Tuesday.

In practice, most failures are dull. A supplier changes a page layout. An API key expires. Someone renames a spreadsheet column. These produce an email, somebody spends twenty minutes, and the system carries on. The dramatic failures people worry about — an agent confidently doing something catastrophic and unnoticed — are precisely what the approval gates and the logging exist to prevent.