This is the first post we are publishing as a team. We are writing it at the start of 2025, which means we are early: we have working software, an internal test bench, and a clear view of the problem we are solving. We do not yet have live warehouse deployments. That position gives us a certain kind of perspective that we think is worth sharing honestly.
The question we get most often from warehouse and 3PL operations leads is not "does your orchestration work?" It is "how do I start?" Full-facility fleet orchestration deployments are complex, involve multiple integration points, and take time to get right. The people asking this question have operational floors to run. They cannot bet the floor on a first deployment with an early-stage vendor they have never worked with before.
The answer we give, and the answer we think is genuinely correct regardless of vendor, is: start with a sub-facility pilot. One zone. One shift. A bounded set of tasks and robots. This post lays out how we think about structuring that pilot and what it is actually trying to find out.
What a Sub-Facility Pilot Is Trying to Answer
A pilot is not a proof of concept in the sense of "does the technology work in a lab." By the time you are running a pilot on a live floor, you presumably believe the technology can work. What the pilot is actually trying to answer is a set of operational questions that cannot be answered in a lab or from a vendor's documentation.
The first question is integration: does the orchestration software actually connect to your WMS and your robots in your environment? Every warehouse has its own WMS configuration, its own network setup, its own robot firmware versions. Integration that works in a reference environment may hit unexpected issues in yours. Finding those issues in a bounded pilot, with one zone affected, is far less disruptive than finding them after a facility-wide rollout.
The second question is operational fit: do the workflows the orchestration layer expects match how your team actually operates? Orchestration software is built with assumptions about how ops requests are issued, how exceptions are handled, and how the system interacts with floor supervisors. Some of those assumptions may not match your operation, and the mismatches need to be identified and either resolved in the software or adapted in the workflow. A bounded pilot surfaces these quickly.
The third question is failure behaviour: when something goes wrong, how does the system respond, and is that response acceptable in your operational context? A vendor can describe their replanning logic in a document. Observing what actually happens when a lane blocks in your facility, with your robots, with your task types, is categorically more informative.
Choosing the Right Zone for a Pilot
Not every zone is a good candidate for a first pilot. The goal is to choose a zone where the pilot can produce meaningful results without creating operational risk to your most critical workflows.
A good pilot zone is one with a defined set of task types that the orchestration layer can handle with a relatively straightforward integration. A pick zone with a single robot type, a bounded set of pick locations, and a staging area with clear task start and end points is easier to instrument and observe than a mixed-use zone with multiple robot types and complex dependencies.
A good pilot zone is not your highest-throughput zone during your highest-volume shift. If the orchestration layer has a problem during the pilot, you want that problem to affect a zone where the operational cost is manageable while you work through it. Some teams choose an off-peak shift for the pilot period for the same reason.
The pilot zone should also have clear physical boundaries. If robots from the pilot zone regularly interact with robots from adjacent zones, the integration surface is more complex and the operational separation between "pilot scope" and "rest of facility" is harder to maintain. A zone that has defined entry and exit points and relatively low cross-zone robot traffic is easier to pilot cleanly.
What to Map and Configure Before the Pilot Starts
A floor map is the starting point for any orchestration layer. The map defines the nodes (bays, staging areas, docks, charging stations) and the edges (navigable paths between them) that the orchestration system uses to plan routes and assign tasks.
For a sub-facility pilot, you only need to map the pilot zone. This is a practical advantage of starting small: the mapping effort is proportional to the pilot area. A full facility map can take weeks to build and validate. A single zone can typically be mapped in a few days if the zone layout is reasonably stable.
The map needs to be accurate. Inaccurate maps produce incorrect route plans and incorrect conflict predictions. Common mapping errors include: nodes placed at approximate rather than measured positions (causes path traversal time estimates to be wrong), edges missing directional constraints (allows robots to be routed the wrong way through a one-way lane), and staging area capacity set incorrectly (causes the system to assign more robots to a staging node than it can accommodate).
Before the pilot starts, the map should be validated by walking the routes the system plans and checking that they match the physical layout. This is not a glamorous step but it catches errors that are very difficult to diagnose once robots are moving.
Robot configuration is the other upfront requirement: each robot in the pilot zone needs to be registered in the orchestration system with its correct type, payload capacity, speed profile, and communication endpoint. For the pilot, it is worth double-checking that each robot's reported telemetry (position, battery, task status) is being received correctly by the orchestration layer before the first live task is issued.
Defining Pilot Success Criteria Before You Start
A pilot without defined success criteria produces data but not a decision. Before the pilot starts, agree on what questions it needs to answer and what results would indicate those questions are answered satisfactorily.
Integration criteria: the orchestration layer successfully receives ops requests from the WMS, compiles them into task graphs, and issues commands to the pilot zone robots. A threshold like "95% of ops requests within the pilot scope are handled without manual intervention" is concrete and measurable. "The integration works" is not.
Replanning criteria: when a lane block event occurs (either simulated or live) in the pilot zone, the system identifies affected tasks and issues updated routes. A threshold like "affected robots receive updated route commands within 30 seconds of block detection" is measurable. Whether that threshold is acceptable for your operation is a judgement call that requires your operational context.
Operational fit criteria: floor supervisors and operations managers can observe the pilot zone state through the orchestration dashboard and the information visible there is sufficient to manage the zone without requiring access to the robot control interfaces directly. This is a qualitative criterion that requires feedback from the people actually using the system.
Exception handling criteria: when the orchestration layer encounters a task it cannot complete (blocked route with no alternative, robot fault, dependency failure), it fails gracefully and alerts the operator in a way that makes the issue clear and actionable.
Running the Pilot and What to Observe
During the pilot, assign a dedicated observer for the first few days. This does not need to be a technical person. An experienced floor supervisor who understands the normal flow of work in the pilot zone is well-positioned to notice when something is behaving unexpectedly, even if they cannot immediately diagnose why.
The most useful observations to collect are: which tasks required manual intervention (and why), which situations caused the orchestration layer to issue unexpected commands or fail to issue expected ones, and which parts of the operator-facing interface caused confusion or required multiple interactions to accomplish a simple goal.
Keep a log. The pattern of issues that emerges over the first week of a pilot is usually more informative than any individual incident. Three separate incidents where the system behaved unexpectedly when a specific task type ran during a cross-shift period suggest a specific interaction worth investigating. Three unrelated one-off errors suggest different things. The log is what lets you distinguish between them.
Expanding from Pilot to Facility-Wide
A successful sub-facility pilot answers the three core questions outlined earlier. It does not automatically mean facility-wide deployment is the right next step, or that expanding to additional zones will be friction-free.
Each zone expansion adds integration surface: new nodes and edges to map, potentially different robot types, potentially different task types, potentially different priority rules. These are smaller integration tasks than the original pilot setup, but they are not zero. Planning for each zone expansion as a mini-project with its own configuration, validation, and brief observation period is more reliable than assuming zone N+1 will work exactly like zone N.
The facility-wide data your operations team starts to generate once orchestration is running across multiple zones is genuinely valuable: which task types produce the most replan events, which zones have the highest frequency of lane conflicts, which time periods have the highest cross-zone dependency complexity. These are not insights you can get from a single-zone pilot. They are the basis for operations improvements that become visible only at scale.
We are writing this as a team that has not yet run a live deployment at scale. We will be updating our thinking based on what we actually observe. The principles here are grounded in how we think about the problem and in conversations with operations leads who have run similar deployments with other software. But we are honest about what we do not yet know from first-hand experience, and we think that honesty is more useful to you than overclaiming.