Ask a warehouse team why an AMR project stalled and the answer is rarely the robot. It is almost always the interface. The machines arrive, they run perfectly on their own, and then somebody has to answer a question nobody costed: who decides which robot does which job, and where does that decision actually live?
That decision is what AMR integration with WMS or ERP is about. It is an architecture question, not a hardware one, and it has three common answers. This guide sets out what each of them means, what the host system has to provide in every case, and what to demand from a supplier before you commit to a pilot.
What the host system actually has to tell the robot
Whatever the architecture, four kinds of information have to cross between your systems and the fleet. Miss any one of them and the integration is incomplete:
| What crosses | Direction | Example |
|---|---|---|
| Transport tasks | Host → fleet | Move this pallet from the inbound station to buffer location B. |
| Task status | Fleet → host | Picked up, delivered, failed, waiting for an operator. |
| Traffic and layout | Fleet internal | Which robot takes which route when two of them want the same aisle. |
| Exception handling | Both | A blocked path, a missing load, an operator overriding a task. |
The third row is the one that surprises people. Traffic control inside the fleet is usually owned by the robot vendor rather than by the WMS, and the boundary between “your system decides this” and “our system decides this” is exactly where projects get stuck. Write that boundary down before the first integration meeting.
Three models of AMR integration with WMS
In practice there are three ways the split gets made, and they differ in who holds the intelligence rather than in what the hardware can do.
Host-driven: the WMS owns every task
In this model the warehouse system decides the work and the robot is a mobile executor. Every task is issued explicitly, and the fleet does not optimise beyond following instructions.
- Strengths. All logic sits in one place, so behaviour is predictable and auditable, and the WMS remains the single source of truth for the operation.
- Costs. The host has to understand transport well enough to sequence it, which means real development work on your side. Changes to flows become WMS changes rather than configuration.
- Fits. Operations with a mature WMS and an in-house integration team, where consistency matters more than throughput.
Fleet-managed: the robots own the routes
Here the WMS hands over a higher-level instruction — a flow, an origin-destination pair, a replenishment need — and the fleet manager works out the rest, including which robot, which route and when.
- Strengths. Faster to deploy, because the transport logic already exists in the fleet manager and does not have to be rebuilt in your system.
- Costs. You are trusting a black box with traffic decisions, and multi-vendor fleets become hard to mix.
- Fits. Pilots and single-vendor deployments where speed to first value matters most.
Hybrid: the usual answer in practice
Most production sites end up here. The WMS owns the business rules — orders, inventory, cut-off times, priority — and hands transport work down. The fleet manager owns the physical layer: route planning, traffic, charging and lift calls where they exist.
The work then shifts to defining the interface properly: which events trigger a task, what a task contains, how completion is reported, and how failures get escalated back into a human queue. Get those four right and the split works. Leave them implicit and every exception becomes a joint investigation.
What to demand from a supplier before you sign
Integration quality is where AMR suppliers differ most, and it is measurable before you buy. Ask for all of the following in writing:
- The interface, in detail. REST, message queue, database, file drop or something proprietary — and whether the vendor supports more than one.
- Documentation you can read without an NDA whisper. A published API reference tells you how much the supplier has invested in being integrated rather than in being clever.
- A sandbox or simulation environment. You want to test task flow and error handling before hardware lands on site.
- Who supports which side. Named responsibilities for the interface itself, not just for the robot.
- Checksum-free handover on the load. If the WMS cannot confirm the correct item was loaded, someone will be walking the aisle to check.
- Failure behaviour. What the robot does when the network drops or the host is unavailable. A machine that stops mid-aisle on a network blip is a different risk from one that finishes its task first.
These questions also sort the product range for you. The platforms in our logistics and AMR range — F150, F300 and F600 — are documented by the flows they are built for, and the integration requirements are confirmed per project rather than assumed from a datasheet.
The pilot that proves the integration
A pilot that only proves the robot drives is worth very little. The pilot should be designed to break the interface, because that is the part that has no fallback.
Four scenarios, run deliberately:
- Task injection under load. Issue transport work faster than the fleet can clear it, and watch what the queue does. If nobody knows the discard policy, it will not exist.
- Deliberate failure. Block a route and see whether the task is re-planned, queued or dropped — and whether the WMS is told either way.
- Host outage. Take the WMS offline for ten minutes and observe. This is the scenario that separates a documented integration from an implied one.
- Operator override. Have a person take a task away from the fleet. If there is no clean way to do that, the operation will invent an unsafe one.
Run in parallel with a realistic flow — the internal runs that keep a picking wave fed are the ones worth automating first, as set out in our 3PL and ecommerce fulfilment guide — and the pilot results become a business case rather than a demo.
Traffic is a separate problem
One more boundary worth knowing before you scope the work. Once more than a handful of machines share a floor, the hard problem stops being the interface and becomes traffic and deadlock: two robots that each have a valid route and neither of which can move. That is a fleet-level design issue with its own solutions, and it is covered separately in our multi-AMR traffic and deadlock guide. Where a site is also automating floor cleaning, the routes and the cleaning plan have to be reconciled — the logic for that is in the warehouse floor cleaning guide.
And if the question you are actually trying to answer is whether guided or free-moving transport suits the building, that decision comes first: see AMR vs AGV.
How to start
Tell us which system will own the work — WMS, ERP or the fleet — what a transport task looks like in your operation, and which flow you want automated first. We will come back with the interface shape, the responsibilities on each side and a pilot scope built around the four failure scenarios above. Send the details here, or start from the machine overview if the hardware question is still open.