For a mid-market operation, the useful question is pretty simple: what does each order actually cost us, and how quickly can we recover when something goes short? Software and a delivery partner matter only if they shorten the time from exception to action.
On a normal Tuesday, that latency looks like this. The WMS records a short pick at 10:17. The OMS still carries the original customer promise. The TMS may already have a carrier booked against a load that no longer makes sense. Finance does not see the margin impact until someone prices the expedite. Every system can be technically correct while the operation is still three hours behind the event.
That’s really what decision latency is: the time between seeing the problem and getting a new instruction back into the system that actually runs the work.
The Economics of Decision Latency
The interesting part is where that spending is going. Companies already have WMS, TMS, and OMS, so the next dollars are increasingly going into the gap between an exception showing up and somebody actually doing something about it. Gartner’s April 2026 SCM forecast reflects this, projecting software with agentic capabilities to jump from under $2 billion in 2025 to $53 billion by 2030.
Prove One Agent Before You Add the Next One
That forecast gets more useful when you look at what companies are actually buying. Gartner’s note on the same topic splits the $53B: simple task agents account for most of the spending; multi-step agents follow once a firm can demonstrate shorter exception cycle times. For a mid-market company, I wouldn’t move into more complicated workflows until the first one has actually changed an operating metric. That’s how you know you’re buying capacity rather than just another demo.
A company does not need a supply-chain brain on day one. It needs one repetitive decision where somebody is already noticing the same exception, pulling together the same four facts, and making the same next move. So that’s the loop I would start with.
And once you decide to outsource some of that build, the question becomes less about technology and more about capacity and ownership: who owns the data product, the integration map, and the policy that lets an agent move a shipment or freeze a PO?
I would include those three owners in the SOW before kickoff, because they really are three distinct responsibilities.
The data product owner needs to define what a transaction means across systems, while the integration owner knows where each update comes from and which application is allowed to accept the write-back. And then somebody on the business side still has to own the policy and decide where the automation stops.
A vendor can supply engineering capacity across all three areas, but it shouldn’t quietly become the business owner of any of them. If those owners keep changing mid-build, that’s usually how a temporary dual-run turns into a permanent one. So the automation limits need to be written down in the policy from the beginning.
The Value Starts When the Exception Gets Closed
Suite licenses already cover receiving, wave planning, and rating. Where companies are actually spending money now is on closing the gap between the system record and a decision the business can act on within the same hour.
I’d rather have one action that works reliably all day than twenty things that look impressive in a demo. Operations teams trust software after they watch the same decision hold up under different conditions. And I would keep the first workflow narrow enough that the operations desk can explain every miss without bringing the AI team back into the room.
When Custom Code Becomes Necessary
Custom code makes sense when the suite leaves a gap the operation is already paying for: multi-node inventory truth, broker-to-carrier tender, bonded paperwork, or a plant-to-DC sequence.
Take a late tender. The TMS already knows the carrier has not accepted the load. The cost shows up in what happens next: a transportation analyst notices it and manually re-tenders the load. The opportunity is to take the exception off the desk, not put another dashboard beside it. When the tender expires, the service checks the policy, selects the next approved carrier, re-tenders the load, and writes the accepted result back into TMS.
The service can run off the events you’re already getting from WMS, TMS, and OMS and expose only a small number of actions the operation actually understands: re-slot, re-tender, or re-promise, each with a clear limit and an audit trail.
Closing the Loop Between Record and Reality
The existing systems still need to stay the systems of record. What you’re adding on top is really a control loop that can see live inventory and in-transit positions, predict a miss, and recommend or execute the next allowed action. If the result never gets written back into the system that runs the work, you still only have reporting.
How You Know the Loop Is Actually Working
The easiest way to test whether you actually have a control loop is to follow one exception all the way through: something happens, the system interprets it, chooses an allowed response, and then writes the result back into the application responsible for execution. If the workflow dies before that fourth step, the company has better visibility, but the operation is no faster.
And from there, each action should have one obvious place to write back to: WMS for a re-slot, TMS for a re-tender, and OMS for a re-promise. You can move those shared events across one bus, but that doesn’t mean the bus becomes the owner of the decision. That distinction keeps the architecture from turning into another mess.
Ideally, you publish order, inventory, ASN, POD, and invoice events once and let the different workflows reuse them, rather than copying the same information into another project spreadsheet.
WMS still owns warehouse execution, TMS owns the transportation move, and OMS owns the customer promise. The automation coordinates across them without creating a fourth source of truth.
And when the automation writes something back, it should do so under a named service account so the audit trail can show exactly which policy version authorized the change. I wouldn’t run those writes through a shared planner login because once you do, you lose the ability to tell who or what actually made the change.
And software isn’t the only thing that can stop you here.
And even when the software is ready, the contract may not be. A 3PL or broker agreement can still block write-back even when the software is ready.
The ‘Shadow Run’: How to Trust Automation Before You Flip the Switch
Before you automate the workflow, make sure everybody agrees on what the core data actually means: order, inventory, ASN, proof of delivery, invoice. The contract does not have to be elegant. It has to remove ambiguity. Does “available inventory” mean physically on hand, released from quality, or available to promise? Does the shipment number survive unchanged from warehouse to carrier to invoice? Which timestamp counts as carrier acceptance? Humans paper over those differences every day. Automation cannot safely paper over them.
Once you do let the agent take an action, its authority needs a hard limit. When it is allowed to act, it can take the next step — re-route, split a wave, open a carrier claim, or update ATP — but only inside a defined tool-call budget. That’s basically a hard ceiling on the workflow’s operational freedom. It may be allowed to check three approved carriers and accept a rate within 4% of the plan. On the fourth carrier or above that threshold, it stops. The point is to put a fence around its authority so everybody knows where it stops before a real shipment depends on it.
I would keep credit release, bonded cargo, and customer-promise changes behind a human approval step until the shadow run shows that the automation is actually beating the current desk on OTIF and cost-to-serve.
During the shadow run, the agent proposes the action and the desk still releases it. Run both against the same set of live exceptions for a fixed period and compare the results. Did the agent see the miss earlier? Did the planner accept its recommendation? Did recovery happen faster? Did premium freight rise? A shadow run is only useful if it produces a clear rule for when to flip the switch; otherwise, it’s just shelfware with live data.
Once late-tender and short-pick recovery times are consistently better than the baseline, you can open write-back on that workflow. Before that first live week, make sure one person owns rollback and that the desk-release process remains available as a fallback.
Data Lineage is Your First Line of Defense
By this point, the audit question gets pretty practical: can you reconstruct who changed the promise date, which tariff code went with the ASN, and where the supporting product data came from? That’s really what lineage means here. Customers experience bad lineage long before anyone calls it a data problem. They call about an order while three systems show three different states.
Good lineage means the company can reconstruct the decision: what event changed the promise, which rule was applied, which shipment now satisfies the order, and which system committed that answer to the customer.
I also wouldn’t add a ledger everywhere just because you can. Use one where a counterparty or regulator actually requires an immutable handoff, and keep that supporting lineage tied to the ASN instead of storing the carbon or due-diligence fields in a separate spreadsheet that never makes it into the booking workflow.
OMS should still be the place that owns the customer promise across channels. RFID and GPS start to matter when they tell the operation something it can actually act on: dwell, diversion, a seal break. A truck moving around on a map by itself doesn’t really change anything.
Freight and broker desks lose significant time and margin to tender delays and invoice disputes. If the same broker service can select the carrier, post tracking, and raise the claim against the ASN the warehouse already published, you’ve taken real work off the desk. A separate portal that requires someone to re-key the TMS load does the opposite.
For a broker desk, I would watch two simple times: how long it takes to go from tender to an accepted carrier, and how long it takes to go from POD to a paid invoice.
Turning Cost-to-Serve from a Metric into a Lever
Cost-to-serve becomes useful when the same data links the operational exception to the financial consequence, such as a pick short, a late tender, or container detention. A container stuck at a port for a week may start with storage fees, but the real cost can show up later as an expedite to protect another customer’s order.
The reason to price the exception at the moment it happens is that logistics savings can shift costs elsewhere. A carrier may look $180 cheaper on the transportation report and still result in a larger loss if the missed appointment causes a customer to expedite. Cost-to-serve forces those consequences back onto the decision that created them.
IMS, TMS, and fleet tools already hold pieces of that information, so the build doesn’t need to recreate it. It needs to pull those updates together and price the exception early enough that finance sees the margin impact before it’s too late to change the decision. That’s also why I would put cost-to-serve next to OTIF rather than treating it as a separate finance metric. A cheaper lane that misses the promise date doesn’t eliminate the cost; it just shifts it to the customer desk.
Treat Compliance Like an Operations Problem
Compliance becomes an operations problem the moment a missing field stops the freight. Customs does not care that the origin certificate exists somewhere in SharePoint if the shipment event cannot retrieve it. And a perfect compliance database doesn’t help the warehouse much if the broker still has to email somebody for the product identifier after the booking is already made.
The Paperwork Has to Move With the Shipment
For EU-bound freight, the exact requirements will keep changing, but the operational problem remains pretty much the same: the product and due diligence data needs to be available when the shipment is booked. If an SKU already has a registry identifier, include that identifier on the ASN so the broker or customs team can resolve it without another manual handoff. That may apply to DPP, battery, or other due diligence requirements, depending on the product.
Ideally, the packet and the booking come off the same event, so the team is not chasing documents after the load has already left the desk.
For US-bound freight, the regulations differ — AES filing, partner screening, and so on — but the operating pattern is the same: the required paperwork must be available when the shipment is booked.
The Bottom Line
Global networks usually fail at the handoff: DC to carrier, broker to customs, promise to customer. So the practical architecture is to keep WMS, TMS, and OMS connected through a shared event layer and then add one bounded automation around the workflow that is already burning margin, whether that’s a late tender, a short pick, or a detained container.
I would sequence the work around the exception the desk already handles every day, not around a list of software features. Start with the people who own that exception now and trace it all the way through until every write-back has a clear owner.
Keep the first rollout small enough that you can actually explain the result: one lane, one DC, and one exception type. Once that first workflow has actually improved the operating numbers, then add the next one. Before you add a second agent, I’d want to see two numbers: how many minutes it takes to get from a shortage to a new promise, and what the order costs after that exception is resolved. If those two numbers aren’t moving, I wouldn’t add another agent yet.
That’s basically the sequence we use at Devox too: get the data contract clear, automate one exception workflow, run it in shadow mode, and only open write-back once you have an OTIF and cost-to-serve baseline to compare it against. If you want to see how we approach the broader system around that workflow, take a look at our work in Supply Chain Management, Procurement & Traceability System Development.
