Agentic, in practice: three exceptions and how the workflow handled them

Autonomous. Agentic. The words are everywhere in this category now, and they rarely come with a concrete picture of what the software actually does when something breaks.

This post is that picture. We're walking through three exceptions, the small everyday breakages that make up most of a supply chain team's week, and what happens between the moment one is detected and the moment it's resolved: what the workflow saw, what it reasoned about, what it did, and in each case the point where a person still made the call.

If you want the groundwork first, our CTO Yotam laid it out in Anatomy of an Enterprise-Ready Agentic Workflow. This post picks up where that one left off and puts it to work on three real situations.

Quick note before the three: these are composites drawn from real patterns, not any one customer's story.

In short

• An exception is not a system failure. It is the ordinary case where reality stops matching what the system of record says.
• Roughly 40 to 60% of supply chain execution happens outside the system of record, in email, portals, PDFs, and shared inboxes. That is where exceptions live and where they go unhandled.
• The difference between a script and an autonomous workflow shows up on the second step: not detecting the exception, but reasoning about which of several valid responses fits this situation.
• In all three exceptions below, the workflow did the gathering, the correlating, and the drafting. A person approved the action that carried commercial risk.
• Human-in-the-loop is not the part we are apologizing for. It is the part that makes the rest of it deployable.

Exception one: a purchase order that changed in an email, not in the ERP

A supplier replies to a confirmed purchase order. Not through a portal, not through EDI. In a threaded email, four messages deep, with a revised PDF attached. The quantity has dropped and the ship date has moved out by eleven days.

Here is what the system of record knows about this: nothing. The PO in the ERP still reads the original quantity and the original date. Every downstream calculation, the availability promise, the allocation, the replenishment signal, is now running on a number that a supplier has already told you is wrong. It will keep running on it until a buyer reads that email, opens the PDF, and rekeys the change.

What the workflow does is read the thread as a thread. It recognizes the message as a PO revision rather than a general reply, extracts quantity and date from the attached document, matches them against the open PO line in the ERP, and identifies what changed. Then it does the part that matters: it works out what the change breaks. Which customer orders were relying on that inbound quantity. Whether the eleven-day slip crosses a commitment date. Whether there is coverage elsewhere.

That last question is where a script stops and reasoning starts. A script can rekey a number. Deciding whether an eleven-day slip is absorbable requires knowing what the quantity was promised against, and knowing that the answer differs depending on the customer, the channel, and what else is inbound.

The workflow updates the PO in the ERP and flags the two customer orders now at risk, with a recommended reallocation for each. The buyer sees the change, the consequence, and the proposed response in one place, and approves or overrides. Rekeying is gone. The judgment is not.

Exception two: a chargeback with a dispute window measured in days

A retailer posts a compliance deduction. It arrives in the retailer's vendor portal, not in your ERP, described in the retailer's own shorthand, against a shipment that left the dock weeks earlier. The window to dispute it is short and it starts running immediately.

Most of these are never disputed. Not because they are all valid, but because disputing one means someone pulling the ASN, the carrier's proof of delivery, the original order acknowledgment, and the appointment record, then reading them against a compliance rule to work out whether the miss was actually yours. That is an hour of skilled work for a deduction that may be small on its own. Multiplied across a quarter, the ones nobody got to are a meaningful part of the 2% leak.

The workflow monitors the portal, so the clock starts when the deduction is posted rather than when someone next logs in. It pulls the deduction, identifies the shipment behind it, and gathers the supporting records from wherever they live, which is usually three different systems and one inbox. It reads them against the stated reason code and forms a view: this one is supportable, this one is not, this one is ambiguous.

Then it drafts the dispute. Reason, evidence, references, in the retailer's format.

It does not file it. Disputing a customer's deduction is a commercial act with a relationship attached, and that decision belongs to the person who owns the account. What changes is that the decision now takes two minutes on a prepared case instead of an hour of assembly, which means the deductions that used to expire unexamined actually get examined. Stop losing revenue you already won.

Exception three: an inbound delay that quietly became a stockout

The third one is the one nobody sees coming, because on the day it happens it does not look like anything.

A container is a few days late. That is normal, it happens constantly, and on its own it is not worth anyone's attention. Two weeks later a fast-moving SKU is out of stock at a regional distribution center, a customer order is short, and the team is expediting a transfer at several times the normal freight cost to cover it.

Between those two moments there was a window where the outcome was still cheap to change, and nobody was standing in it. Not through negligence. The delay lived with the carrier, the demand signal lived in the planning system, the inventory position lived in the WMS, and the customer commitment lived in the order. No one system held enough of the picture for the risk to be visible in it.

Correlating across those four is what the workflow does continuously rather than at a weekly meeting. It ties the delayed inbound to the specific SKU and location, reads that against current on-hand, in-transit, and near-term demand, and calculates whether the delay is genuinely absorbable or whether it becomes a shortfall on a particular date. When it becomes a shortfall, the alert names the date and the quantity, and comes with options: pull from a location with surplus, adjust the allocation, or expedite, with the cost of each.

The choice among those is a business decision. Which customer gets protected, and what you will spend to protect them, is not something a workflow should decide on its own. It is exactly the kind of decision that a human should be making. The point is that they get to make it two weeks earlier, on a real forecast rather than a fire.

What the three exceptions have in common

Read them together and the same shape appears three times.

1. The signal arrived outside the system of record. An email thread, a vendor portal, a carrier update. In none of the three did the ERP have what was needed, which is why none of the three could have been caught by monitoring the ERP more carefully.
2. Detection was the easy half. Any of these could be surfaced by a rule. The work is in the second step, understanding what the signal means against everything else that is true right now, which differs every time and cannot be enumerated in advance.
3. The workflow acted inside the systems you already run. It updated the PO in the ERP, drafted the dispute in the retailer's format, read the position from the WMS. Nothing was replaced and nothing new became the place where the real work happens.
4. A person made the call that carried risk. Approving the reallocation, filing the dispute, spending the freight. In each case the workflow did the assembly and the reasoning and stopped where a commercial judgment began.

That fourth point is the one that gets misread as a limitation, so it is worth being direct about it. A workflow that acts without approval on decisions of consequence is not a more advanced version of this. It is a version nobody responsible would deploy. How much any individual workflow does on its own varies, and it moves as trust is earned.

What none of these three required was replacing a system. The ERP still runs the transactions. The WMS still runs the warehouse. Emerix runs the workflow on top of them and acts inside them, which is why a first workflow goes live in about 12 weeks rather than becoming a multi-year program.

The question worth carrying into September is this: how many of these went unhandled at your company this week, and would anyone know?

Alison Crawford is Director of Product Marketing at Emerix, the system of action for supply chain execution. She has spent her career in supply chain software, with prior roles at RELEX Solutions, Aera Technology, o9 Solutions, and Kinaxis, and was recognized in the 2023 Women in Supply Chain Awards. She writes about the distance between what supply chain software promises and what it actually executes.

Connect with Alison on LinkedIn.