Buying orchestration software for an AMR fleet is not like buying most enterprise software. The integration surface is more complex, the operational stakes are higher (robots that behave unpredictably in a live warehouse cause real problems), and the category is young enough that vendor claims are difficult to verify from marketing materials alone. The right questions to ask are not obvious.
This guide covers the evaluation criteria that actually matter from an operations standpoint. We are writing it as a vendor in this space, which means we have an obvious interest in how the criteria are framed. We have tried to write this as a genuinely useful guide for a 3PL operations lead or warehouse manager who is doing their own evaluation, not as a disguised pitch. If a criterion disadvantages us, we have included it anyway.
Start With Your Actual Fleet Composition
The first question to answer before evaluating any vendor is: what robots do you actually have, and what robots might you add in the next two years?
Orchestration software connects to robot fleets via the robot's native command API or a published integration protocol such as VDA 5050. The practical question is not "does vendor X support AMRs" but "does vendor X have a working integration with the specific robot models I'm running today, and how long did that integration take to build?"
Ask vendors directly: which robot models do you have tested integrations with? How is the integration structured (direct API, VDA 5050 adapter, custom connector)? When a robot manufacturer pushes a firmware update that changes the command interface, who maintains the integration and on what timeline?
A vendor who can name specific robot models and describe the integration architecture is credible. A vendor who talks about "any robot with a REST API" without specifics is probably describing aspirational capability, not working code.
For 3PL operators specifically: your clients may bring in their own robots or specify preferred vendors. Ask whether the orchestration layer can handle a mixed fleet from two different manufacturers within the same ops request. This is a harder integration problem than single-vendor deployments, and not every orchestration platform handles it well.
Replanning: The Questions That Actually Matter
Most AMR orchestration vendors claim some form of dynamic rerouting or replanning capability. The question is what that capability actually covers.
The simplest version of "replanning" is robot-level collision avoidance: the robot detects an obstacle and navigates around it autonomously. This is a feature of the robot hardware and firmware, not of the orchestration software. Nearly every AMR platform has it. It is not what you should be evaluating as an orchestration capability.
What you want to understand is what happens at the task graph level when a lane becomes persistently unavailable: a blocked aisle that is not going to clear in the next few minutes, a dock that is occupied and won't free up for 20 minutes, a section of the facility locked out for maintenance. Can the orchestration layer identify which active tasks are affected, and can it generate alternative task routes without halting the unaffected parts of the fleet?
Useful questions to ask vendors during evaluation:
- If I report a lane as blocked via your API, what happens to active robots whose routes pass through that lane? Walk me through the response.
- How quickly does the replan complete? What is the latency between block detection and updated route commands being issued?
- Do robots that are not affected by the block keep moving while the replan runs?
- How does the system know which tasks are affected by a specific lane block versus which tasks are unaffected?
- Can I trigger a replan manually (via API or dashboard) without waiting for sensor detection?
A vendor who can answer these concretely, with specific latency numbers and a description of what the system actually does at each step, is describing real capability. Answers that stay at the "our platform handles disruptions intelligently" level without operational specifics should prompt follow-up.
WMS Integration: Depth and Maintenance
An orchestration layer that cannot receive tasks from your Warehouse Management System is not useful. But there are significant differences in how WMS integration is implemented, and those differences affect how easy the system is to maintain and extend.
The first question is whether the integration is inbound-only (the WMS pushes ops requests to the orchestration layer and receives status callbacks) or bidirectional (the orchestration layer can also pull task queues from the WMS and query inventory data). Bidirectional is more capable and more complex. For most warehouse deployments, inbound push with status callbacks is sufficient.
The second question is how the integration is structured. A direct API integration requires the orchestration vendor to maintain a connector for each WMS they support. A standards-based approach (using something like the Blue Yonder or Manhattan task APIs, or a neutral middleware layer) is more portable but may have limitations. Ask how many WMS platforms the vendor has live integrations with, not just claimed compatibility with.
The third question is who owns the integration when something breaks. WMS vendors push updates. Data schemas change. Error formats change. If the orchestration vendor's connector breaks on a WMS update, what is the response time and who is responsible for fixing it? This is an operational question, not a technical one, but it matters a great deal for a warehouse that depends on the integration to function daily.
Task Model and State Visibility
How does the orchestration system model the work it is doing? The answer to this question reveals a lot about what the system can and cannot do under real operating conditions.
A flat task model treats each robot dispatch as an independent command: robot A goes to location B, picks up item C, goes to location D. Tasks are independent of each other, and the system's view of work is at the individual command level.
A task graph model represents a whole ops request as a directed structure with dependencies: before robot B can pick item C, robot A must have deposited the pallet at staging. Before the dock assignment can be made, the inbound status must have been confirmed. Tasks are linked, and the system understands the precedence relationships.
The difference matters most at recovery time. If a task graph is partially complete and something goes wrong, a system with a flat model has to restart from the beginning or rely on a human to figure out what was already done. A system with a graph model knows which tasks completed successfully before the disruption and can target recovery to the affected portion of the remaining work.
Questions to ask: Can I query the current state of a running ops request and see which individual tasks have completed, which are in progress, and which are pending? If a task fails, can the system tell me what dependencies were satisfied before the failure? Is this state accessible via API, or only visible in the dashboard?
Deployment Model and Operational Boundaries
Orchestration software for warehouse operations needs to be highly available. A system that is down for 15 minutes during a peak pick window is a production incident. Understanding the deployment model is essential.
Is the system cloud-hosted, on-premises, or edge-deployed in the facility? Cloud-hosted systems have the advantage of vendor-managed infrastructure but introduce network dependency: if connectivity between the facility and the cloud host degrades, what happens to robots that are mid-task? Most vendors have a local fallback mode, but the specifics vary widely. Ask: if internet connectivity is lost for 60 seconds while robots are active, what happens?
On-premises deployments eliminate the network dependency but require the operator to manage the infrastructure. For warehouse operators without a strong IT function, this can be a significant operational burden.
Edge deployments place the orchestration software in the facility on local hardware, with cloud sync for configuration and monitoring but local task execution. This is often the best operational model for warehouses but requires the vendor to have designed for this deployment pattern from the start.
Also worth asking: how is the system monitored in production? Is there a dashboard that shows real-time task graph state and robot status? Can alerts be sent via webhook or email when the system detects an unresolved blockage or a task that has been in flight longer than expected? Operational visibility matters as much as the technical capability.
Pricing Model and Early-Stage Risks
The AMR orchestration market is early. A number of the vendors you will evaluate are small teams, some of them pre-revenue. This matters for procurement.
A vendor with a per-robot pricing model aligned with fleet size is generally easier to budget for than a vendor with flat enterprise licensing or per-ops-request pricing. As your fleet scales, costs should scale predictably. Understand what happens to your pricing if you add 10 robots mid-contract.
For vendors that are early-stage, ask about data portability: if you decide to switch orchestration platforms after 18 months, can you export your ops request history, task logs, and floor maps in a standard format? Vendor lock-in through proprietary data formats is a real risk in this market. The answer to this question also tells you something about how the vendor thinks about long-term customer relationships.
A pilot structure that lets you test in a bounded zone before committing to facility-wide deployment is prudent regardless of vendor size. Any vendor who is not willing to support a scoped pilot is worth treating with skepticism.
What This Guide Does Not Cover
This guide focuses on orchestration software evaluation criteria. It does not cover robot hardware selection, warehouse management system replacement, or the specifics of any individual vendor's product. The evaluation questions here apply broadly and should help you structure conversations with any vendor in this space.
The answers you get will vary, and some of them will be incomplete or oversold. The goal of this kind of evaluation is not to find a vendor who gives perfect answers to every question. It is to find a vendor who answers the hard questions honestly, can demonstrate real capability in scenarios close to your operating conditions, and has a deployment model that fits your operational reality.