Maria Vasquez spent six years implementing warehouse automation systems at a logistics integrator based out of Phoenix. Not designing the robots, not selling them: implementing them. Showing up at fulfillment centers, mapping the floors, connecting the APIs, training the operations teams, and being there when things went wrong at 2 AM during peak season.
She saw a lot of deployments succeed on paper and struggle in practice. The robots worked. The WMS worked. The individual pieces were competent. What failed was the layer in between: the coordination of many robots sharing a single floor, pulling from a single task queue, navigating through shared aisle infrastructure, without any shared awareness of each other.
By her count, twelve of the deployments she worked on between 2018 and 2023 hit the same wall at roughly the same point in the deployment timeline. The robots were live. The WMS was connected. The first few weeks went fine, because the fleet was small relative to the floor and congestion was rare. Then the customer added more robots, or won a new fulfillment contract that increased order volume, or both at once. And the floor stopped working like a system. It started working like a collection of machines that happened to share a space.
The Conversation That Kept Not Happening
Jonah Reyes was on the engineering side of several of the same types of deployments, working on the software integration layer that connected WMS task streams to robot fleet APIs. He and Maria met at an industry event in 2022 and discovered they had both been asking the same question to different groups of people, and getting the same non-answer.
The question was: who owns the cross-vendor coordination layer? Who is responsible for making sure that when Vendor A's AMRs and Vendor B's AGVs are both heading toward the same aisle approach at the same time, something intelligent happens before they create a traffic jam?
The robot vendors said: that is the WMS's job. The WMS vendors said: we manage task sequencing, not robot routing, that is the fleet management software's job. The systems integrators said: we wire the systems together, we do not write the coordination logic. Nobody owned it. And nobody in that chain had an incentive to own it, because owning it meant building software that had to work with every robot vendor's API, which was a maintenance burden with no revenue model attached to it.
The gap was not a secret. Everyone in warehouse automation knew it existed. The industry's response was to work around it: physical floor separation between vendor zones, conservative fleet sizing to keep density low enough that congestion was manageable, and a lot of operations supervisor judgment filling in where software fell short. These workarounds had real costs. Physical separation meant forfeiting routing flexibility. Conservative fleet sizing meant underutilizing expensive equipment. Supervisor judgment does not scale.
Why the Vendors Were Not Going to Solve This
By 2023, the major AMR vendors were all running fleet sizes large enough that their own customers were asking for better multi-vendor coordination. The vendors were aware of the problem. They chose not to solve it for structural reasons that are worth understanding.
First, building cross-vendor coordination software requires integrating with competitor APIs. That means keeping those integrations current as competitors update their protocols, which is ongoing engineering cost with no clear business upside. From a vendor's perspective, investing in making it easier for customers to mix your robots with a competitor's is not an obviously rational use of engineering resources.
Second, the customers asking for cross-vendor coordination were already multi-vendor customers: operations that had purchased from more than one robot vendor for the reasons we described in an earlier post about the vendor-lock problem. These customers had already exited the single-vendor ecosystem. Building the coordination layer for them would not bring them back to single-vendor purchasing.
Third, the robot vendors are primarily hardware companies with software organizations that exist to sell and support the hardware. Building a fleet-agnostic coordination platform would mean becoming a software company competing with WMS vendors and systems integrators, which is not a pivot most of them wanted to make.
The structural gap was real and stable. It was not going to close from the vendor side. That was the opening.
What We Decided to Build, and Why
Maria and Jonah co-founded Botpylon in 2024 with a specific thesis: the dispatch brain for a mixed-robot fulfillment floor should be an independent software product, not an add-on from any of the stakeholders who had a reason to avoid building it.
Independent meant fleet-agnostic by design, not by aspiration. The architecture had to work with whatever robot vendors the customer was running, which meant building adapter layers for each vendor's API rather than assuming any vendor would open their protocol to interoperability. The business model had to be software subscription, not hardware sales or professional services hours, so the revenue model would align with delivering ongoing dispatch quality rather than deployment completion.
We started with the two scenarios that caused the most operational pain in the deployments Maria had worked on: mixed-vendor aisle congestion and cross-vendor task assignment inefficiency. Those were the specific failure modes we had direct experience with, where we knew what the right behavior should be and why the existing tools failed to produce it.
We built a floor graph engine first, because you cannot do congestion-aware routing without a shared model of the floor that includes positions from all robot vendors. Then the dispatch layer that used the floor graph to make task assignments. Then the fleet adapter framework that made it practical to integrate new robot vendors without rebuilding the core engine each time.
What Botpylon Is Not
We want to be clear about scope, because there is a temptation in the warehouse software market to claim everything. Botpylon is not a WMS. We do not manage inventory, track order state, or run wave planning. Those are well-solved problems with established vendors. We read task queues from your WMS. We do not replace it.
Botpylon is not a robot vendor. We do not make hardware. We do not have a preferred hardware partner. Our business model works best when customers have more robot vendors, not fewer, because the coordination problem we solve gets harder and more valuable as fleet heterogeneity increases.
What we are is the orchestration layer that sits between your WMS and your robot fleet, sees every robot regardless of vendor, and makes dispatch decisions that treat the floor as one shared system rather than a collection of vendor-specific silos. That is the gap that existed. That is what we built Botpylon to close.
We are a small team in Phoenix, founded a year ago, still in early deployment with a handful of fulfillment operations. We have not run a $100 million deployment. We have run floors that look like the floors most 3PLs are operating today: 40-150 robots, two or three vendors, a WMS that predates the robot fleet, and an operations team trying to make it all work with tools that were not designed to work together. That experience is what we built from, and it is the experience we are designing for.