Most of the capital deployed into warehouse technology over the past five years has gone into the physical automation layer — autonomous mobile robots, goods-to-person systems, robotic picking arms, automated sorting infrastructure. These are large capital investments with 5–10 year payback periods and significant integration complexity. The companies selling them are solving a genuine productivity problem for large distribution centers running high-volume repetitive workflows.
What has received far less investment is the software intelligence layer that sits above this physical automation. This is the layer that decides what the robots pick, in what order, on what schedule — the orchestration logic that determines whether a $15 million automation investment generates 30% efficiency improvement or 18% efficiency improvement. That gap in outcome, entirely determined by software, is where we see the underappreciated opportunity.
What the orchestration layer actually does
A modern automated fulfillment warehouse contains multiple automation subsystems: an ASRS (Automated Storage and Retrieval System) for high-density storage, AMRs (Autonomous Mobile Robots) for horizontal transport, goods-to-person pick stations, automated conveyor and sortation. Each system has its own control software — a WCS (Warehouse Control System) that interfaces with the physical equipment at the machine level.
Above the WCS sits the WMS (Warehouse Management System), which handles inventory records, order allocation, and operational workflows. Traditional WMS systems were designed for manually operated warehouses. Applying them to automated facilities creates a mismatch: the WMS makes slot assignment and order sequencing decisions using heuristic rules that were adequate when human pickers could adapt on the fly to suboptimal pick paths. Robots cannot adapt in the same way. They execute exactly what the WMS tells them. Poor orchestration decisions become immediately visible in throughput rates and travel time inefficiency.
The intelligence layer between the WMS and the physical automation — sometimes called a WES (Warehouse Execution System), sometimes just referred to as automation orchestration software — is the control point for operational performance. It decides how to sequence work across automation subsystems to minimize bottlenecks, how to buffer orders in goods-to-person stations to maintain pick station utilization, and how to dynamically reprioritize task queues when inbound volume patterns shift during peak periods.
Why heuristic-based orchestration falls short
Traditional WES software uses rule-based logic to make these orchestration decisions. Rules like "if pick station utilization drops below 70%, pull forward the next wave of orders" or "prioritize same-day delivery orders in the ASRS queue when carrier cutoff is within 3 hours." These rules are defined during implementation, tuned over several months of operation, and then largely static.
The problem is that warehouse operations are not static. Inbound volume patterns, order mix, SKU velocity distributions, and staffing levels all vary continuously. Rules that were tuned for steady-state operations during the initial months degrade as conditions change. A distribution center that processes a significantly different product mix in Q4 than in Q2 will see its rule-tuned orchestration software underperform in ways that are difficult to diagnose and even harder to fix through rules alone.
I spent time as COO of a warehouse automation startup where we dealt with exactly this gap. Our clients had invested in sophisticated physical automation and were running it on orchestration software that couldn't adapt to operational variation. The throughput numbers on paper — what the automation vendor had promised — were achievable in steady-state test conditions. In real operations with seasonal variation and order mix changes, actual throughput was 15–25% below the nameplate figure. The automation wasn't broken. The orchestration decisions were suboptimal in ways that compounded across thousands of decisions per hour.
The ML opportunity in orchestration
Applying ML to warehouse orchestration is not a new idea, but it's one that is only recently becoming practical at the facility level for operators who aren't running Amazon-scale operations. The combination of better sensor data from automation equipment (real-time throughput rates, queue depths, task completion times), lower cost of compute, and improved reinforcement learning frameworks has moved this from research project to production possibility.
The core opportunity is in dynamic work sequencing — continuously reoptimizing how work flows through automation subsystems in response to real-time conditions rather than executing a pre-planned wave schedule. A model trained on historical throughput patterns can learn that pulling orders for carrier X earlier than the nominal cutoff, when goods-to-person station 3 is running ahead of pace, consistently reduces late shipments without degrading throughput for other carriers. These multi-variable interactions are exactly what rule-based systems fail to capture and what ML models are well-suited to learn.
The data moat here is meaningful. An orchestration intelligence platform that has learned from thousands of operational hours across multiple facility types and order profiles will generate better throughput optimization than one trained only on a single site's data. Each new customer site adds to the model's exposure to operational variation, and that improved generalization compounds across the customer base.
The buyer landscape and go-to-market path
The primary buyer for orchestration intelligence software is the operations director or VP of fulfillment operations at a mid-to-large distribution center running automated systems. This person lives and breathes throughput, and they are acutely aware of the gap between their automation vendor's promised performance figures and what they actually observe day-to-day. They have budget authority for operational software improvements when the business case is clear in cost-per-unit terms.
The go-to-market dynamic is not straightforward, because this software sits in a complex ecosystem. The automation vendor has a relationship with the customer and often has an orchestration software product of their own — sometimes mediocre, sometimes actually good, and always positioned as part of the integration. A standalone orchestration intelligence company needs to either partner with automation vendors as a complementary layer, or enter through a direct path that demonstrates performance improvements against whatever the current orchestration approach is.
We're not saying the automation vendor's integrated stack is always inferior — for some use cases, the tight hardware-software integration is genuinely better than a third-party intelligence layer. What we are saying is that for facilities with complex, variable order profiles across multiple automation subsystems, the generic orchestration software bundled with most automation equipment is leaving meaningful throughput on the table. The companies that can quantify that gap and capture it as software revenue are building something with real and durable value.
What we look for in this space
Founders who have operated automated warehouses at a level of detail where they understand both the WCS/WMS architecture and the day-to-day operational variation that makes static rule-based orchestration fall short. The combination of ML engineering capability and this operational depth is the right founding team for the orchestration intelligence category. One without the other builds the wrong product for the wrong buyer.