Every robotics team eventually writes the same function. It starts as `def move_all(robots, goals):` and it looks trivial. Then a second robot wants the same corridor, and the function starts to grow. By the time it actually works in the field, it is not a function anymore — it is a subsystem, and it is the one your team did not budget for.
This post is the honest parts list. If you are deciding whether to build coordination yourself or call something that already exists, you should know exactly what "coordination" contains before you sign up to own it.
The demo version is real, and it is a trap
You can get two simulated robots to avoid each other in an afternoon. Reactive collision avoidance, a little repulsion vector, a nav stack — it demos beautifully. This is the version that gets greenlit, because it makes the hard problem look solved.
It is not solved. It is postponed. The gap between "two robots dodge in a demo" and "twenty robots complete a mission in a warehouse, every time, with a record you can hand to a safety reviewer" is where the actual engineering lives — and none of it shows up in the demo.
The parts list nobody scopes
Here is what "coordinate the fleet" actually expands into once it leaves the demo:
- Global deconfliction, not local avoidance. Reactive dodging degrades exactly when it matters — dense space, many agents, tight timing. Two agents each make a locally sensible move and put themselves on a fresh collision course, then deadlock in a doorway. Guaranteeing no two paths ever cross requires reasoning about all agents at once, over space and time. That is a reservation system, not a repulsion vector.
- Determinism. If the same mission can produce a different plan on two runs, you cannot test it, you cannot certify it, and you cannot explain it after an incident. Making coordination reproducible is its own discipline — no hidden clocks, no unordered map iteration, no floating-point drift that changes a tie-break.
- Safety gates at dispatch. "Don't fly over the exclusion zone" has to be enforced at the moment a command is issued, not checked in a planner that a later step can override. That means a policy layer with veto power over motion, and a way to prove the veto fired.
- Evidence. When something goes wrong — or when a customer, an auditor, or a regulator asks what happened — "the logs say so" is not enough. You need a tamper-evident record: what was planned, what was reserved, which gates passed, signed so a third party can verify it was not edited after the fact.
- The long tail. Replanning when a robot drops out. Priority when two missions compete. Heterogeneous fleets where a ground robot and a drone have different footprints. Every one of these is a sprint you did not plan.
Each bullet is weeks. Together they are the difference between a coordination demo and a coordination product.
We measured the difference
We ran a controlled A/B: build a coordination integration from scratch against general-purpose tools, versus reach the same outcome through the Cascade coordination API. Same task, same scenario set, same success bar. Then we counted the code each path required to get there.
The 4.6× is the honest, conservative number: it is just lines of code to reach functional parity on the coordination task. It does not price in the parts of the list that do not show up as code you write once — the determinism you have to maintain, the evidence format you have to design and defend, the safety policy you have to keep correct as the product changes. Those are ongoing costs, and they are the ones that quietly consume a robotics team's roadmap.
When you should build it anyway
We are not going to pretend buying always wins. Build it yourself when:
- Coordination is your product — you are selling the deconfliction algorithm itself, and owning every millisecond is the moat.
- You have a genuinely novel constraint model that no general layer expresses, and you have measured that off-the-shelf coordination cannot fit it. (Be honest here: most "novel" constraints are variations on priority, exclusion, and capacity that a good layer already handles.)
- You have a team that wants to own this subsystem for years, with the test infrastructure and the safety-review muscle to keep it correct.
If two of those three are true, build it. You will do it well.
When you should not
Buy it when coordination is infrastructure for you, not the product — when what you are actually selling is inspection, or delivery, or public-safety response, and the fleet is how you deliver it. In that world, every week your team spends re-deriving a reservation table is a week not spent on the thing customers pay for. The coordination layer is undifferentiated heavy lifting, and undifferentiated heavy lifting is precisely what you outsource.
That is the case Cascade Dynamics is built for. You type the mission in plain language; the platform compiles it, deconflicts the fleet deterministically, enforces safety gates at dispatch, and hands back a signed evidence bundle you can verify. The 4.6× you did not write is the smaller half of what you did not have to own.
The open beta lets you run the coordination layer against simulated fleets with no card, and the claims ledger documents exactly how the parity benchmark was measured.