Inside an autonomous workflow: how Emerix detects, reasons, and acts

An alert fires. A container is late. Somebody on your team reads it, opens the ERP to see which orders were riding on it, checks the WMS for what is already on hand, digs the customer commitments out of a spreadsheet, and works out what to do.

Every one of those systems worked. You paid for all of them. And a skilled person still spent the morning carrying information between them, because none of them was ever going to do it themselves. That is not a software failure. It is an unclosed loop.

Closing that loop is what an autonomous workflow does, and it is what we mean by a system of action for supply chain execution. One loop, four movements. Something is noticed. Something is worked out about what it means. Something is written back into a system of record. Then somebody checks whether that was the right call. Detect, reason, act, verify.

The four movements are the easy part. Each one already exists in some tool you could buy this quarter. It is the seams between them that decide whether you get an autonomous workflow or an expensive relay, and it is why "the AI handles it" is doing an enormous amount of hiding right now, including in conversations where the underlying software is perfectly good. If you are the person who has to sign off on something that writes into your ERP, you are entitled to know what happens at each movement, what it needs from your business, and where it can break. That is what follows.

Stage one: detection is a listening problem, not a monitoring problem

Ask a room of supply chain leaders how they would detect an exception and most will describe a threshold. Inventory below a number. A ship date past a date. An order aging beyond a tolerance. All of that is real, and all of it is monitoring: you already know the shape of the thing you are looking for, and you are watching a field you already own for it to cross a line.

The trouble is where exceptions actually announce themselves. About 40 to 60% of supply chain execution happens outside the system of record, in email threads, supplier and retailer portals, attached PDFs, and shared inboxes. That is not a data hygiene failure. It is the nature of the work: the moment reality diverges from the plan, a human being writes to another human being about it, in prose, with an attachment. Your system of record was built for reporting, not for reading that.

So detection, done properly, is listening rather than monitoring. The workflow reads an email thread as a thread rather than as a message, and recognizes a supplier's fourth reply as a purchase order revision rather than general correspondence. It watches a retailer's vendor portal so the dispute clock starts when the deduction is posted rather than when somebody next logs in. It takes a carrier status update that means nothing on its own and holds onto it.

Two things follow from that, and both matter for how you evaluate this.

The first is that detection has to be tolerant of messy input, because the input is a human writing to a human. Structure is not guaranteed, formats change without notice, and the same supplier will phrase the same event three different ways in three quarters. This is exactly where the last generation of scripted automation broke, and it is why "your system of record doesn't understand unstructured data" is the sentence we keep coming back to.

The second is that detection alone is nearly worthless. Noticing a thing and doing nothing about it is a dashboard, and the reason dashboards proliferated is that noticing is the cheap half. Which brings us to the expensive half.

Stage two: reasoning is where a workflow stops being a script

Here is where this stops being a parsing problem.

A supplier moves a ship date out by eleven days. That fact, on its own, is not actionable. Whether it matters depends on what the inbound quantity was promised against, whether there is coverage somewhere else, whether the slip crosses a commitment date, and which customer sits behind the order. The same eleven days is routine in one account and an escalation in another, and the difference has nothing to do with the eleven days.

So the workflow's second job is to work out which of several valid responses fits this situation. Not to detect. To decide.

Deciding requires three kinds of knowledge, and it is worth being explicit about them because they are also the three things you will be asked to supply:

1. What the fields actually mean. Which date field is authoritative, who else writes to it, how fresh it is. Not across the enterprise. Across the dozen or so fields this one workflow touches.
2. What your business does about this. The judgment your best operator applies without thinking: this supplier tends to short by a few percent, that customer accepts partials, this account has a compliance clause and gets handled differently. None of that lives in a schema. It lives in people.
3. What is true right now everywhere else. On-hand, in-transit, near-term demand, open commitments, read together rather than one system at a time.

Our CTO Yotam has written the engineering account of what it takes to get those three in place, in Anatomy of an Enterprise-Ready Agentic Workflow. The part worth repeating for a business reader is his scoping point, because it is the one that changes whether a project is fundable: readiness is scoped to the workflow, not to the company. You do not need a master data program before you can act on supplier emails. You need to know what a dozen fields mean and what your team does when a date moves.

This is also the honest answer to "how is this different from the RPA we already bought." A script executes a fixed sequence and breaks on the first case its author did not anticipate. Reasoning is the ability to encounter a situation nobody enumerated in advance and still choose defensibly among the responses your business considers acceptable. We put the full comparison in Agentic AI, RPA, and chatbots: a buyer's field guide, but the one-line version is that the difference shows up on the second step, not the first. Last week's three exceptions are that second step, three times over.

Stage three: acting means writing back inside the systems you already run

The third stage is the one that makes this a system of action rather than a very well-informed observer, and it is also the one that makes procurement nervous, correctly.

Acting means the workflow updates the purchase order line in the ERP. It drafts the dispute in the retailer's own format. It reads the position from the WMS and proposes the transfer. We don't replace your systems. We run the workflow inside them, and the transaction still lands where your auditors, your reports, and your team already look for it. Nothing new becomes the place where the real work happens, which is the failure mode of every tool that ends up as a second inbox.

What makes that safe rather than alarming is that the write path is engineered, not assumed. In practice that means four things travel with every action:

1. Scoped identity. The workflow acts under its own credentials with the minimum permissions this workflow needs, not a borrowed admin login.
2. An approval gate. Every change the workflow drafts passes a gate that decides whether it commits now or waits for a person. The gate is defined by you: change types, thresholds, the accounts you consider sensitive.
3. Reversibility. Running the same change twice does nothing, and any change can be walked back.
4. An audit trail. The draft, the evidence behind it, the gate's decision, the approval if there was one, and the write itself. Reviewable later, which is what an auditor will ask for and what your own team will want the first week.

Note what the gate implies. Autonomy is a per-action decision, not a switch you throw for the whole workflow. Routine changes commit on their own. Changes that carry commercial risk wait for the person who owns the relationship: filing a dispute against a customer, spending freight to protect one account over another. That is deliberate, and it is not a limitation we are working to remove. We made the full argument in The spectrum of autonomy, and it holds: human-in-the-loop is the part that makes the rest of it deployable.

For the technical reader clearing this: Emerix is SOC 2 Type II compliant, and today more than 15 battle-tested workflows run in production across more than $10B in supply chain transactions under management.

Stage four: the loop only closes if somebody checks the work

Three stages in, you have a workflow that notices, decides, and acts. That is enough to be useful and not enough to be trusted, because nothing so far tells you whether the decisions were right.

This is the stage that gets cut when a project is running late, and cutting it is how you end up with something fast and unaccountable. The fix is not complicated in concept: the workflow has to emit signals you can join against outcomes. Did the shipment actually arrive near the revised date. Did the approver accept the draft or rewrite it. Did a human reverse the workflow's update two days later.

That last one is the most valuable thing in the system. Every override is a free, labeled example of the workflow being wrong, and a loop that captures overrides gets better at the specific ways your business differs from the general case. A loop that lets them evaporate into a Slack thread does not.

Two honest notes here. First, verification on probabilistic output at scale is its own discipline, and it is genuinely harder than the other three stages. Our buy-or-build piece on evals is about exactly why the checking machinery, not the acting, is the expensive part to own.

Second, this is why we talk about self-optimizing execution rather than just automated execution. The loop that measures itself is the one that improves. The loop that does not is a script with better manners.

Why the seams, not the stages, are where these projects fail

Here is the pattern I would want to know about if I were evaluating this category, and it is the reason this post is laid out as one loop rather than four separate tools.

Taken individually, none of the four stages is exotic. Plenty of tools detect. Plenty of tools reason, in the sense that plenty of tools will give you a recommendation. Some tools write back. A few measure. You can assemble a version of all four from things you already own, and many teams have tried.

What breaks is the handoffs.

Detection hands the reasoning stage a signal, and the signal arrives without the context needed to reason about it, so a person re-gathers it. Reasoning produces a recommendation, and the recommendation lands in a different tool from the one where the action gets taken, so a person retypes it. The action commits, and the outcome is recorded somewhere the reasoning stage will never read, so nothing is learned. Every one of those seams is a place where the work falls back onto a human, and the human it falls onto is usually your best operator, who is now doing coordination instead of judgment.

That is the execution gap reappearing inside the thing you bought to close the execution gap. It is also, in my experience, the actual reason pilots stall. Not because the model was not smart enough. Because four stages owned by four tools is not a loop, it is a relay with dropped batons, and the dropped batons are exactly the 2% leak: missed dispute windows, stockouts, chargebacks, expediting, and skilled people doing data entry.

Running the four stages as one system, with the handoffs inside it, is the difference. It is also why a first workflow goes live in about 12 weeks rather than becoming a multi-year integration program: the scope is one loop on one exception type, not a platform rollout.

So when you are being shown one of these, the useful question is not "can it detect that." It is: show me the seam. Show me what the reasoning stage receives, show me where the action gets written, and show me what the workflow will know next month that it does not know today.

That is what an autonomous workflow is. Four movements, one loop, no gaps for the work to fall into. Every system in the story at the top of this post was working correctly, and somebody still lost a morning to it.

Which leaves one thing worth deciding: which of your exception types is bleeding the most, and what it would take to close the loop on that one first.

Questions we get about this

What is the difference between an autonomous workflow and automation?

Automation executes a fixed sequence of steps that somebody defined in advance, and it breaks on the first case its author did not anticipate. An autonomous workflow reasons about a situation nobody enumerated, chooses among the responses your business considers acceptable, and acts inside your systems of record. The difference shows up at the decision, not at the trigger.

Does the workflow act without a human approving it?

It depends on the action, by design. You define which change types, thresholds, and accounts commit automatically and which stop at an approval gate. Actions that carry commercial risk, like filing a dispute against a customer or spending freight to protect one order over another, wait for the person who owns that decision.

Does Emerix replace our ERP or WMS?

No. Emerix runs the workflow on top of the systems you already have and takes action inside them, so the transaction still lands in your system of record where your reports and your auditors expect to find it.

How much data cleanup do we need before we can start?

Less than most teams assume, because readiness is scoped to the workflow rather than to the enterprise. A single workflow typically touches around a dozen fields across two systems, and what is needed is knowing what those fields mean and who writes to them. That is bounded work, not a master data program.

How long before the first workflow is live?

About 12 weeks for a first workflow, because the scope is one exception type and one write path rather than a platform program.

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.