The visible intelligence may be a robot choosing a path or handling a load. The less visible intelligence is the backend deciding what should happen, coordinating shared resources, detecting stale reality, and recovering when a physical action does not match the plan.
A warehouse backend should not steer wheels from a distant cloud request. Local controllers, perception, navigation, and safety systems need authority close to the machine. The backend owns a different layer: translate demand into missions, assign capable resources, coordinate traffic and infrastructure, preserve operational truth, and reconcile the result with the warehouse management system.
This separation matters because physical side effects are not database rows. A timeout does not reveal whether a pallet moved, a door opened, or a robot stopped halfway through a zone. Every command needs identity, state, evidence, a bounded authority window, and a recovery path.
Optimization may suggest that a robot enter a busy zone faster. Safety must still be able to refuse. ISO 3691-4 defines safety requirements and verification for driverless industrial trucks and their systems; a fleet scheduler or AI planner is not a substitute for that safety architecture.
Robotic work is long-running, interruptible, and observable. ROS 2 actions model this shape as a goal with feedback, cancellation, and a result. At the backend boundary, the same idea should become a durable state machine with command IDs, attempt IDs, leases, checkpoints, expected physical effects, and explicit terminal states.
Retries must be outcome-aware. Re-sending “pick pallet A” after a timeout can create a second physical action if the first actually succeeded. Before retrying, reconcile robot state, payload sensors, location, workstation signals, and WMS records. Idempotency in physical systems is built from verification and compensation, not only a database key.
| Backend concern | What can go wrong physically | Evidence required | Recovery pattern |
|---|---|---|---|
| Mission dispatch | Robot accepts a goal, but the acknowledgment is lost. | Goal ID, robot mission state, feedback timestamp, adapter record. | Query before retry; resume the same goal or issue a new attempt explicitly. |
| Traffic coordination | Pose or intended route becomes stale while other machines continue moving. | Map version, pose age, trajectory, liveliness, zone lease. | Expire authority, stop admission, replan, and escalate uncertain occupancy. |
| Payload transfer | Robot reaches station but load transfer is partial or unconfirmed. | Robot payload state, station sensor, conveyor or PLC signal, image or operator confirmation. | Hold inventory update, isolate work, verify, then complete or compensate. |
| Shared infrastructure | Door, lift, charger, or conveyor fails after reservation. | Reservation owner, device state, timeout, alternative route and capacity. | Release leases, requeue safely, reroute, or request intervention. |
| Connectivity loss | Cloud or site network disappears during an active mission. | Last accepted authority, local state, safety status, bounded offline policy. | Continue only approved local behavior; otherwise reach a safe stop and reconcile later. |
| Software rollout | A new adapter, map, or policy changes behavior across a live fleet. | Versioned config, simulation result, canary scope, mission and safety metrics. | Drain work, canary by zone or fleet, rollback, and preserve old protocol support. |
Mixed fleets expose a choice between one vendor-specific integration per fleet and common coordination interfaces. Open-RMF uses fleet adapters to connect fleet-specific APIs to traffic scheduling and smart infrastructure. MassRobotics focuses on shared status and operational information. VDA 5050 standardizes communication between a master control system and mobile robots; version 3.0, released in April 2026, adds concepts for highly autonomous robots including zones and path sharing.
These approaches solve different parts of the problem. A common schema does not eliminate vendor capabilities, safety responsibilities, map differences, or recovery semantics. Build adapters as explicit products with versioned contracts, conformance tests, observability, and a clear statement of what each integration can and cannot control.
CPU graphs are not enough when a delayed message can leave a robot blocking an aisle. Trace each mission across order, planner, adapter, robot, facility device, and WMS reconciliation. Metrics should include pose age, feedback delay, queue and zone wait, mission phase duration, battery trend, localization confidence, recovery frequency, human interventions, and work completed per constrained resource.
Simulation and digital twins belong in the delivery pipeline. Replay congestion, network loss, blocked aisles, depleted batteries, failed doors, mismatched maps, and partial payload transfers before changing live orchestration. The goal is not a beautiful simulation; it is evidence that plans remain bounded when reality diverges.
I would build an event-sourced mission control plane. Each mission would preserve the requested business outcome, capability constraints, assignment decisions, commands, feedback, physical evidence, exceptions, human actions, and final reconciliation. A live spatial operations view would join missions, robots, zones, shared infrastructure, and stale-state alerts.
The most important feature would be a recovery console that explains what the system believes, why it believes it, which physical facts remain uncertain, and which safe next actions are available.
Physical AI succeeds when local autonomy, independent safety, and backend coordination have clear boundaries. Treat every mission as a physical saga: issue bounded intent, observe continuously, assume acknowledgments can lie by omission, reconcile before retrying, and design recovery as a first-class workflow.
Article about backend systems behind physical AI in warehouses and robotics, including mission orchestration, mixed fleets, traffic, telemetry, safety, recovery, interoperability, and simulation.