The dispatch brain your WMS never shipped
Botpylon sits between your WMS and your robot fleet, ingesting task streams and position telemetry in real time, building a live floor graph, and dispatching congestion-aware assignments in under 300ms. No proprietary hardware. No rip-and-replace.
Four layers. One floor graph.
From WMS task stream to dispatched robot assignment, every decision passes through four purpose-built layers designed for low latency and high fleet density.
Four modules. One dispatch decision.
Floor Graph Engine
Builds and maintains a real-time directed graph of the warehouse floor. Nodes represent aisle segments, zone intersections, and pick stations. Edges carry dynamic congestion weights updated every cycle from observed robot density and velocity data. The graph is the decision substrate for every routing choice Botpylon makes.
Congestion Predictor
A trained model that forecasts zone congestion before it happens, not after. It learns shift-level patterns: which aisles spike at 10:15am when the inbound dock receives, which intersections bottleneck when more than 12 robots converge on Zone C. Path weights are pre-adjusted to route around predicted congestion, not just observed congestion.
Task Assignment Optimizer
Takes the pending task queue from your WMS and the current floor state, then produces an optimal assignment batch: which robot handles which pick task, in which sequence, via which path. Considers robot position, battery state, lift capability, and current zone load simultaneously. Handles batch grouping to reduce robot travel per order line.
Dispatch API
Stateless push API that delivers optimized task assignments to each robot's fleet controller in under 300ms from task intake. Each robot client receives only its own assignment, no shared state, no single point of failure. On robot fault or task failure, the assignment re-enters the optimizer within one cycle without human intervention.
Why we built it this way
Three intentional architecture choices that reflect what goes wrong when you try to scale orchestration to 150+ robots or multi-vendor fleets with standard approaches.
Stateless robot clients
Robot fleet controllers receive tasks via push, maintain no local Botpylon state, and can restart without breaking dispatch continuity. If a robot goes offline mid-task, the assignment is recovered on the next optimizer cycle, not held in a queue waiting for reconnect. This means you can update or restart the Botpylon service without coordinating robot downtime.
Low-latency pub-sub dispatch
Task assignments are delivered via a lightweight pub-sub channel per robot, not polled REST endpoints. At 200-robot scale, polling would create request storms on task completion. Pub-sub keeps dispatch latency stable regardless of fleet size. The 300ms target holds at 500 active robots the same as at 30.
No video or camera dependency
Botpylon uses only telemetry data: robot ID, position coordinates, velocity vector, task state, battery level. No cameras, no video processing, no image storage. This was a deliberate choice: vision pipelines add latency, storage costs, and privacy surface area. Position telemetry from robot fleet APIs gives us everything needed for congestion modeling and dispatch decisions.
Talk to the team about your fleet topology.
We'll model your floor, identify congestion zones, and walk you through what Botpylon dispatch would look like on your actual layout.
Request Demo