The most common concern we hear when talking to operations teams about adding an orchestration layer is: will this break my WMS? The concern is legitimate. Warehouse management systems in production facilities are typically load-bearing infrastructure. They have been configured over years, customised for the facility's specific workflows, and integrated with upstream ERP systems and downstream carrier connections. Anything that touches the WMS carries real risk.
The short answer is that Stateful Robotics does not replace or modify the WMS. It sits between the WMS and the robot fleet, consuming outputs from the WMS and providing status updates back. The WMS continues to own everything it currently owns. The division of responsibility is clean, and the integration surface is narrow.
This post describes what that integration surface looks like, where the boundary between WMS responsibility and orchestration layer responsibility falls, and what the practical steps for establishing the integration are.
What the WMS keeps owning
The WMS owns the business logic of the warehouse operation. That includes: inventory position (what is at which bay, in what quantity), order management (what needs to ship, by when, to whom), task prioritisation based on business rules (which order has the highest SLA urgency), dock door assignment, carrier scheduling, and inventory reconciliation after execution. None of this changes when an orchestration layer is added.
Critically, the WMS continues to own the decision of what work to release. When the WMS decides that order batch A47 should be picked now (rather than holding it for a wave later), it generates an outbound work instruction. That instruction is the input to the orchestration layer. The WMS is not asked to restructure how it generates work instructions; it continues using its existing queue management and release logic.
The WMS also continues to own inventory updates after task completion. When the orchestration layer reports that a pick task completed (item removed from bay 3), the WMS uses that event to update its inventory records. The orchestration layer does not write directly to WMS inventory; it fires a completion event that the WMS processes according to its existing inventory update logic. This preserves the WMS as the authoritative source of inventory truth.
What the orchestration layer takes over
The orchestration layer takes ownership of everything between "work instruction received" and "work instruction completed." That means: decomposing the work instruction into robot tasks, assigning tasks to robots, monitoring execution, handling mid-run disruptions through replanning, and reporting task-level completion back to the WMS.
Before the orchestration layer, the WMS was typically sending task assignments directly to robots or to a simple robot management console. That direct dispatch path is what changes. After integration, the WMS sends work instructions to the orchestration layer, which translates them into the fleet's task graph and manages execution. The robots no longer receive instructions directly from the WMS.
This is the core architectural shift. The WMS's robot-task interface, which was direct before, becomes mediated by the orchestration layer. The WMS does not need to know about individual robots, their current locations, or which corridors are available. It submits work instructions and receives completion events. The orchestration layer handles everything in between.
The integration surface: two endpoints
The practical integration between a WMS and Stateful Robotics involves two endpoints. The first is the ops request endpoint: the WMS (or a lightweight adapter layer) posts work instructions to the orchestration layer's REST API. The second is the completion webhook: the orchestration layer sends task-level and ops-request-level completion events to a webhook URL that the WMS exposes for receiving external status updates.
The ops request API accepts a structured payload: source location, destination location, item reference, priority, and an optional deadline. The payload format is defined in the orchestration layer's API documentation, and the WMS adapter maps the WMS's native work instruction format to this payload. In most cases this mapping is straightforward: WMS work instructions already contain source, destination, and item fields. The adapter primarily handles field name translation and authentication.
The completion webhook receives events in the following forms: task-started (a robot has begun executing a specific task), task-completed (a task has completed with outcome), ops-request-completed (all tasks for an ops request have completed), and replan-event (a task was replanned, including the reason and expected completion time impact). The WMS can subscribe to whichever events it needs for its own tracking. Most WMS integrations only need task-completed and ops-request-completed events to update inventory and order status; the replan-event can be consumed by a monitoring dashboard if the operations team wants visibility into disruption events.
What happens to existing WMS robot integrations
Many WMS deployments that already have AMR fleets have some form of existing integration between the WMS and the robots, usually a direct dispatch path through the robot vendor's fleet management console or a simple middleware connector. When adding the orchestration layer, this existing path needs to be redirected.
The typical approach is to leave the WMS's robot dispatch configuration in place but redirect the outbound work instruction target from the robot fleet console to the orchestration layer's API endpoint. From the WMS's perspective, it is still sending work instructions outbound to a robot system; the destination has changed. This often requires only a configuration change in the WMS rather than a code change, though this depends on how the WMS implements its outbound dispatch integration.
The robot vendor's fleet management console may still be in use for monitoring and direct robot-level operations (firmware updates, diagnostics, manual overrides). The orchestration layer interacts with each robot through that same console's API, so the existing vendor relationship and tooling are not displaced. The orchestration layer calls the robot vendor API; the WMS no longer calls it directly for operational dispatch.
Handling the handoff: what defines a work instruction boundary
One decision point in the integration is defining what constitutes a complete ops request from the orchestration layer's perspective. In some WMS configurations, the WMS generates granular task instructions (one per item, one per pick location). In others, it generates higher-level instructions (move batch, pick wave). The orchestration layer can handle either, but the compilation logic differs.
When the WMS sends granular item-level instructions, the orchestration layer's compilation step is simpler: each instruction maps to a small task graph with limited branching. When the WMS sends higher-level batch instructions, the compilation step does more decomposition work, resolving the batch into individual pick tasks, determining staging requirements, and planning for the full execution sequence.
Our recommendation for new integrations is to start with the WMS's natural instruction granularity rather than restructuring the WMS's output to fit an assumed input format. The orchestration layer's compilation handles both granularities; the integration adapter maps whatever the WMS naturally produces. Restructuring the WMS's outbound format to match an external system's preferences is engineering work that often reveals unexpected dependencies in the WMS configuration and is better avoided if the default format is functional.
A concrete integration sequence
To make this concrete, consider a facility running an established WMS with a 12-robot AMR fleet. The WMS currently sends pick task instructions directly to the fleet management console via a REST connector. The operations team wants to add orchestration and replanning without changing their WMS configuration significantly.
The integration proceeds roughly as follows. First, the orchestration layer is deployed and configured with the warehouse map (a graph representation of corridors and bays) and the fleet's robot profiles (types, capabilities, speed profiles). Second, a lightweight adapter is written that accepts the WMS's existing outbound work instruction format, translates it to the orchestration API's ops request format, and forwards it. Third, the WMS's REST connector target is updated to point to the adapter endpoint instead of the fleet console. Fourth, the orchestration layer is configured with the WMS's webhook URL for completion events. Fifth, the existing fleet console's dispatch queue is monitored to confirm that work is now arriving via the orchestration layer rather than directly.
In this sequence, the WMS requires no internal changes beyond a URL update in its outbound connector configuration. The WMS operators continue to manage order priorities, release timing, and inventory in exactly the same way. The orchestration layer handles the execution layer transparently from the WMS's perspective.
Where the integration approach has limits
The integration model described here works cleanly when the WMS treats the robot fleet as a transport execution layer that it dispatches to and receives completion events from. There are WMS configurations where the boundary is not this clean. Some older WMS systems have tight coupling between their task dispatch and their inventory lock logic: items are locked in WMS inventory at the moment a robot task is dispatched, and the lock is held in the WMS until the WMS itself confirms the task is complete. In these configurations, delegating dispatch to an intermediary layer can create timing issues where the WMS believes items are locked on tasks that have already completed (or vice versa).
This is not a problem we can solve generically from the orchestration layer. It requires working with the WMS configuration to either update the inventory lock trigger to consume completion events from the orchestration layer, or to implement a more synchronous handoff pattern where the WMS's lock confirmation is part of the ops request lifecycle. We are not saying this is an insurmountable problem; we are saying it requires WMS-specific configuration work, not just deploying the adapter.
For facilities where the WMS manages inventory locks tightly, the integration scoping step is important: before starting the integration, map exactly what the WMS does at task dispatch time and at task completion time. That map will show whether the adapter approach is sufficient or whether deeper WMS configuration work is needed. Starting the integration without that map is a reliable way to encounter blocking issues mid-deployment.