Almost nobody buys a mobile robot fleet from a single vendor anymore. It starts with one supplier for picking, then a second is added for heavy pallet moves the first vendor's platform wasn't built for, then a third for tugging between zones — each addition justified on its own, and each one quietly changing what "maintaining the fleet" actually means.
That's not a fringe scenario. It's the default shape of a fleet three years into an automation programme, and it's exactly the setup the fleet-orchestration software industry has spent the last two years building for. What it hasn't solved is the maintenance layer sitting underneath the orchestration layer.
Why fleets are getting more mixed, not less
Robots from different vendors operating in silos — unable to share space or coordinate routing — is the operational problem the industry has rallied around solving. Kinexon's take is blunt: "for true interoperability and scalability, there is no alternative to VDA5050," the communication standard now treated as the baseline for multi-vendor fleets. Their own platform integrates robots from more than 20 manufacturers, and one facility that adopted a vendor-agnostic approach to combine heavy-load AGVs with rapid-picking AMRs saw a 25% increase in operational throughput as a direct result.
The system-integrator market backs the same trend from a different angle — STIQ's 2026 research puts the global SI market at $34bn this year on a 10% CAGR toward $49bn by 2030, and a growing share of that spend goes into multi-phase automation projects where the robot fleet is assembled vendor by vendor over several rollout stages, not procured whole from one supplier on day one.
What orchestration software doesn't solve
Fleet-management and orchestration platforms route jobs, resolve traffic conflicts and track battery and location in real time across every robot on the floor, regardless of manufacturer. None of that touches the maintenance layer. A unified dispatch queue doesn't know that the AMR it just routed to a charging dock has a six-monthly LIDAR recalibration due, buried on a different page of a different manual than the one for the AGV parked next to it.
Each robot model is, for maintenance purposes, a genuinely separate piece of equipment. The orchestration platform treats them as interchangeable capacity. The manual, the parts catalogue and the safety-critical checks do not.
What multiplies with every vendor you add
None of these individually is hard to manage. Multiplied across three or four vendors, with different manuals, different terminology and different revision cycles, they stop being something one person can track from memory:
- Service intervals per model — a picking AMR and a heavy-load AGV rarely share a maintenance cadence, even from the same vendor’s own product line.
- Spare parts catalogues — four vendors means four parts numbering systems and four supplier relationships to keep current, with no shared inventory logic between them.
- Safety-critical checks — e-stop function, bumper sensors and LIDAR calibration each carry their own verification interval and procedure, specific to that model.
- Firmware and software update cadences — updates from one vendor can land mid-shift and interact with a maintenance window scheduled around a completely different robot.
Where the gap actually shows up
It shows up mid-shift, not in the business case. A robot goes into an unfamiliar fault state, the technician on the floor has never opened that vendor's manual before, and the fix sits on a page nobody indexed while the robot sits idle and the rest of the fleet reroutes around it. Multiply that by four vendors' worth of annual firmware compliance checks, quarterly recalibrations and wear-part replacements, none of them tracked in the same place, and the maintenance overhead of "going multi-vendor" turns out to be real — it just never made it into the ROI spreadsheet that justified the third vendor.
How we approach it
This is what AI manual extraction was built to remove: every robot's OEM manual, regardless of vendor, gets read in full and turned into a PM schedule tied to that specific asset — service intervals, safety-critical checks and part numbers included, not just the sections a technician had time to skim. A five-vendor fleet ends up with one calendar instead of five, and one place a technician can look up an unfamiliar fault code instead of guessing at 2am.
IoT condition monitoring sits on top of that and doesn't care which vendor built the robot either — fault-code frequency, battery degradation rate and communication error rate all show the same pattern before a hard failure, whatever badge is on the chassis. It raises a work order while the fix is still scheduled maintenance, not an emergency call to a vendor whose manual nobody in the building has read closely.