General
Why Rules-Based TMS Logic Breaks at Retail Scale: Three Shifts and Five Symptoms in 2026
Sep 3, 2026
13 mins read

Rules-based TMS logic is transportation planning built on predefined conditional rules that lock a plan against a snapshot of the network, then hand deviations to a human exception queue. It was designed in the late 1990s and early 2000s for logistics that was predictable and largely linear, and it works well under those conditions. Modern retail broke three of its assumptions at once: data now arrives continuously rather than in batches, decisions are interdependent rather than isolated, and a single misfired rule cascades downstream faster than a person can intervene. Retail logistics leaders rarely diagnose this as an architecture problem, because it presents as peak season chaos, store-fulfillment cost spikes and planners’ firefighting.
Key Takeaways
- Rules-based TMS logic is not badly built. It was correctly built for conditions that no longer hold: batch data, isolated decisions and recoverable exceptions.
- Three shifts broke it. Data velocity outran batch cycles, decisions became interdependent, and exceptions began cascading faster than manual recovery.
- The failure is architectural rather than operational. Recovery leaves the planning loop and enters a human queue, and latency consumes the options while it waits there.
- Symptoms mislead. Peak chaos, slot adherence drift and returns leakage get treated as execution problems when each traces to a specific architectural cause.
- Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027, and 56% of chief supply chain officers name legacy integration as a major challenge. Replacement fails more often than it succeeds.
- The alternative is continuous replanning rather than a rip-and-replace. Plans recompute at every state change, and recovery stays inside the loop.
Why rules-based logic breaks at scale: the business case
The evidence for autonomous resolution is now strong enough to make the comparison concrete. McKinsey QuantumBlack, in Seizing the Agentic AI Advantage (June 2025), reports up to 80% of common incidents resolved autonomously and a 60% to 90% reduction in time-to-resolution. Those are the numbers a human exception queue is competing against.
The counter-evidence matters just as much, and it is why this is an architecture question rather than a shopping question. Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027 (June 2025), and a Gartner survey found 56% of chief supply chain officers citing integration of AI with legacy systems as a major challenge (April 2026). Rules-based logic does not fail because nobody tried to replace it. It persists because replacement attempted as a rip-and-replace usually fails.
The cost of an architecture that cannot recompose is visible in the public record. ASOS in 2019 hit a put-away backlog at its Berlin Eurohub that the automation could not recompose around. The consequences were a £20M to £25M immediate profit hit, warehouse transition costs escalating from a £35M budget to £47M, and full-year profit falling 68%. The automation was not broken. It could not re-plan around a state it had not anticipated.
The exposure concentrates where retail already spends most. McKinsey puts the last mile at 60% to 70% of total parcel delivery cost, so a planning architecture that degrades in the final leg degrades in the most expensive leg.
Also Read: Modern TMS Alternative: Why Logistics-First Companies Are Adopting Agentic TMS in 2026
How rules-based logic breaks, step by step
Step 1: The plan is locked against a snapshot
Planning runs on a batch cycle and produces a plan optimized against the network as it was at that moment. Every downstream instruction inherits that snapshot’s assumptions about capacity, traffic, inventory position and appointment times.
Step 2: The state changes and the plan does not
Orders arrive, appointments move, a carrier rejects a tender, a store’s inventory position shifts. Under a batch architecture, none of this reaches the plan until the next cycle, so the plan continues to execute correctly against conditions that no longer exist.
Step 3: Recovery exits the planning loop
This is the decisive step and the one most often missed. When state diverges from plan, a rules-based system does not re-plan. It raises an exception, which leaves the optimization loop and enters a human queue. The intelligence that built the plan is not the intelligence recovering it.
Step 4: Latency consumes the recovery options
While the exception waits, the options degrade. The alternative carrier’s capacity gets taken, the diversion point is passed, the appointment slot is filled by someone else. By the time a planner reaches the item, the best available answer is worse than the one that existed when the exception was raised.
Step 5: The exception cascades
Retail decisions are interdependent, so one unrecovered exception propagates. A late inbound moves a cross-dock, which moves outbound loads, which breaks delivery slots, which generates customer contacts and reattempts. Each downstream effect arrives as its own exception, and the queue grows faster than it clears.
Step 6: Rules are recalibrated manually, and the network has already moved
Eventually someone recalibrates the rules against what went wrong. But networks evolve continuously, and manual recalibration cycles are slow enough that the new configuration is detached from physical reality before it is fully deployed. This is logic degradation, and it is why rules-based systems feel progressively less accurate over years without anything visibly breaking.
Five symptoms and what each one actually indicates
Retail teams rarely present this as an architecture problem. They present one of these five, and each maps to a specific cause.
| What you observe | What it actually indicates |
|---|---|
| Peak season chaos | Data velocity exceeding what a batch cycle can absorb, so plans are stale for longer at exactly the volume that punishes it most |
| Store-fulfillment cost spikes | Decision interdependency left unresolved, where node, carrier and route choices are optimized separately and conflict |
| Slot adherence drift | Cascading delay, where small unrecovered deviations compound across a route rather than being re-planned out |
| Planner firefighting | A missing learning loop, so the same exception classes recur and human attention is the only recovery mechanism |
| Returns routing leakage | Static defaults applied to a flow whose economics change constantly, so returns route by rule rather than by current cost |
The diagnostic value is in the mapping. Treating peak chaos as a staffing problem adds planners to a queue that will grow again next peak. Treating it as a data velocity problem changes the architecture that produces the queue.
Also Read: Agentic-Washing: How to Tell a Real Agentic TMS From a Rebranded Rules Engine in 2026
Rule-based versus composable architecture
| Property | Rule-based, static plan-and-execute | Composable, continuous replanning |
|---|---|---|
| When the plan is set | Locked at a snapshot, on a batch cycle | Recomputed at every state change |
| Where recovery happens | Outside the loop, in a human exception queue | Inside the loop, automatically |
| Effect of latency | Consumes the recovery options while the item waits | Minimal, because the response is immediate |
| Response to interdependency | Each decision optimized separately, conflicts surface later | Decisions solved together against total cost-to-serve |
| How it improves | Manual rule recalibration, obsolete before full deployment | Learns from outcomes and overrides continuously |
| Behavior under exception load | Queue grows faster than it clears | Cascades are recomposed before they propagate |
Also Read: Seven Tenets of an Agentic TMS: Vendor Evaluation Rubric
The same shock, two architectures: Walmart and Target in 2022
The clearest comparison available is not a vendor benchmark. It is two retailers meeting the same pandemic-era inventory collapse.
Walmart executed item-by-item recomposition, canceling billions in orders and trimming roughly a third of its excess US inventory across the second and third quarters. Target absorbed the shock instead, taking inventory charges within weeks and accepting heavy markdowns, with margin compression continuing into 2023.
Same shock, same industry, same quarter. The difference in outcome came from whether the operation could recompose at item level or could only respond in aggregate. That capability is architectural, and it is decided long before the shock arrives.
What to look for when replacing rules-based logic
Recovery inside the planning loop. The single most important question. Ask what happens when state diverges from plan: does the system re-plan, or does it raise an exception for a person. Everything else follows from that answer.
Continuous replanning on state change, not on a cycle. Confirm the trigger is an event rather than a clock. Ask to move an appointment mid-demo and watch whether the plan responds now or in the next run.
Decisions solved together rather than sequentially. Node allocation, carrier selection and route construction have to be solved against one objective. Ask how the platform resolves a conflict between the cheapest node and the cheapest carrier.
A composable path rather than a replacement project. Given that Gartner expects more than 40% of agentic AI projects to be canceled, the deployment model matters as much as the capability. Ask whether one module can go live against your existing estate and prove itself before the next.
Learning from overrides. Ask how planner overrides change future decisions. If the answer is that someone reviews them quarterly, the learning loop is manual and will fall behind the network.
Also Read: What Is an Agentic TMS? Enterprise Logistics Guide for 2026
Continuous replanning in action: real-world results
North American retail enterprise, several hundred stores. Ocean, rail and road ran across six legacy systems, which is logic degradation and decision interdependency in their most expensive form: no single definition of on-time, and exceptions surfacing in six queues. Consolidating execution onto Locus produced more than $1M in savings with 99%+ on-time store delivery, exceptions resolved in under two hours and 95%+ route compliance, with 80%+ less manual dispatch and break-even in year one. The manual dispatch reduction is the exception queue disappearing.
Fortune 50 parcel and freight, 4,500 drivers, 51 sites. Dispatch decisions were made locally with no consistent basis for comparison, the condition in which rule sets drift apart site by site. Centralizing execution on Locus lifted the weekly execution rate from 75% to 92% and uncovered more than $14M in unused contracted capacity, at 99.99% uptime.
Common mistakes when rules-based logic starts failing
Adding planners to the exception queue. It works for one peak. The queue is produced by the architecture, so headcount treats the symptom and guarantees the same conversation next year.
Tightening the rules. More granular rules make the system more brittle, not more accurate, because every additional condition is another assumption that can detach from reality and another thing to recalibrate.
Attempting a rip-and-replace. This is what the Gartner cancellation figure is measuring. Replacing a planning architecture wholesale is the highest-risk path available, and legacy integration is the most cited reason those projects fail.
Reading the symptom as the problem. Peak chaos, slot drift and returns leakage each have a specific architectural cause. Fixing the visible surface without touching the cause moves the symptom rather than removing it.
How Locus replaces rules-based logic without a replacement project
Locus, the world’s first Decision-Intelligent, Agentic TMS, is built on continuous replanning rather than a locked plan with an exception queue attached. The Digital Supply Chain Officer (DiSCO) framework runs a Sense-Decide-Execute-Learn cycle across eight specialized agents, reasoning over 250+ real-world constraints, which means recovery happens inside the planning loop rather than outside it.
That addresses the three shifts directly. Against data velocity, plans recompute on state change rather than on a batch cycle. Against decision interdependency, the Dispatch, Capacity and Carrier Agents solve node, capacity and carrier choices against one objective instead of sequentially. Against exception cascading, the Orchestrator Agent recomposes downstream effects before they propagate, and normalizes events across carriers so a deviation is visible while options still exist.
The deployment model matters as much as the architecture, given how often replacement projects are canceled. Locus is composable: Fulfillment Automation with Order Management and Delivery Linked Checkout, Dispatch Planning with Hub Operations, Capacity Management and Route Planning, Delivery Orchestration with Transporter Management and ShipFlex, Track and Trace with the Driver Companion App, Control Tower and Tracking Page, and Analytics and Insights all deploy independently against an existing estate. One module can prove itself before the next is committed, which is the opposite of a rip-and-replace.
Across more than 1.5 billion deliveries for 360+ enterprise customers in 30+ countries at 99.99% uptime, Locus has produced over $320M in documented logistics cost savings. Locus has been recognized by Gartner for seven consecutive years, including the 2026 Gartner Hype Cycle for Supply Chain Execution and Logistics Technologies, is a Leader in Transportation Management Systems in the QKS Group SPARK Matrix, and ranked #1 in Route Planning on G2’s 2026 Best Software Awards.
In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.
Request a Locus architecture assessment to find which of the five symptoms your operation is carrying and what is producing it.
Also Read: Scaling Retail and Grocery Transportation: Why Enterprise Networks Require Orchestration
Frequently Asked Questions (FAQs)
What is rules-based TMS logic?
Rules-based TMS logic is transportation planning driven by predefined conditional rules, where a plan is optimized against a snapshot of the network on a batch cycle and deviations are routed to a human exception queue. It was designed for logistics that was predictable and largely linear, and it performs well under those conditions. It struggles when data arrives continuously, when decisions are interdependent, and when exceptions cascade faster than a person can recover them.
Why does rules-based TMS logic fail at retail scale?
Because three of its assumptions no longer hold. Data velocity now exceeds what a batch cycle can absorb, so plans are stale while they execute. Decisions are interdependent, so optimizing node, carrier and route separately produces conflicts that surface later as cost. And exceptions cascade, so an unrecovered deviation propagates through cross-docks, outbound loads and delivery slots faster than a queue clears. Crucially, recovery leaves the planning loop and enters a human queue, and latency consumes the options while it waits.
What is the difference between rules-based and composable TMS architecture?
A rules-based architecture locks the plan at a snapshot and handles recovery outside the optimization loop through human exceptions. A composable architecture recomputes plans at every state change and keeps recovery automated inside the loop. The practical differences are where recovery happens, whether latency destroys the available options, and whether the system improves from outcomes or only from manual rule recalibration.
What are the signs your TMS rules are failing?
Five symptoms map to specific causes: peak season chaos indicates data velocity exceeding batch cycles, store-fulfillment cost spikes indicate unresolved decision interdependency, slot adherence drift indicates cascading delay, planner firefighting indicates a missing learning loop, and returns routing leakage indicates static defaults applied to changing economics. Each is usually treated as an execution problem when the cause is architectural.
Should we replace our TMS to fix this?
Not as a single project. Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027, and a Gartner survey found 56% of chief supply chain officers citing legacy integration as a major challenge, so rip-and-replace is the highest-risk path. A composable approach is more survivable: deploy one capability above the existing estate, prove it against the symptom that costs most, then extend.
Does more granular rule configuration solve the problem?
No, it usually makes it worse. Every additional rule is another assumption about the network that can detach from physical reality, and another thing to recalibrate manually. Because networks evolve continuously and recalibration cycles are slow, more granular rule sets degrade faster. The fix is not better rules but recovery that stays inside the planning loop.
Anas is a product marketer at Locus who enjoys turning complex logistics problems into simple, clear stories. Outside of work, he’s usually unwinding with a book or catching a good movie or series.
Related Tags:
General
Seven Tenets of an Agentic TMS: How to Test a Vendor Against Each in 2026
Seven tenets separate an agentic TMS from a legacy platform with AI features. Each one has a test a buyer can run in a demo, and most vendors fail at least three.
Read more
General
Human-in-the-Loop Logistics: The Operating Model Behind Agentic Logistics Orchestration in 2026
Human-in-the-loop is not a setting you switch on. Supervisory judgment degrades when automation handles the routine cases, so the human role has to be designed and maintained.
Read moreInsights Worth Your Time
Why Rules-Based TMS Logic Breaks at Retail Scale: Three Shifts and Five Symptoms in 2026