I've been working on multi-agent path finding (MAPF) for warehouse robotics, so when Amazon published the DeepFleet paper (arXiv, Aug 2025), I spent
considerable time dissecting it.
Four things I found most interesting:
1. The 97M-parameter Robot-Centric model beat the 840M and 900M alternatives. Local interaction propagation matters more than global context — a finding that aligns with what we see in
classical MAPF (PIBT, LaCAM).
2. Image-based representations catastrophically failed (186% congestion delay error). You cannot represent a robot as a single pixel and expect to capture fleet interactions.
3. The 13M-parameter Graph-Floor model was surprisingly competitive. This suggests the warehouse's graph topology itself is the binding constraint on coordination quality.
4. The scaling laws section experimentally confirms power-law behavior over two orders of magnitude — giving substance to the "improves over time" claim.
I also tried to translate the technical findings into economic terms using Little's Law: a 10% travel time reduction in a 1,000-robot warehouse is equivalent to ~100 fewer robots
($1.3M/year).
I build Rovnou (https://rovnou.com), which does MAPF-based fleet coordination for non-Amazon warehouses. The DeepFleet paper validates many design choices we've made (event-driven, local
context, graph-first), while also showing where foundation models may eventually surpass classical solvers.
Happy to discuss the architecture tradeoffs, MAPF vs. learned approaches, or practical deployment challenges.
Great question! The current implementation is relatively straightforward:
Layout: The diagram generation uses fixed coordinate positioning (x, y values) calculated heuristically based on node indices and predefined
spacing. For example, flowcharts use a simple vertical layout with consistent spacing. There's no automatic layout engine - it's manual
coordinate calculation.
Arrow routing: Currently uses simple direct connections between source and target nodes. draw.io handles the actual path rendering, but we don't
leverage draw.io's advanced edge routing algorithms (orthogonal routing, etc.) - arrows just connect the specified entry/exit points.
CJK text sizing: This is actually an area that could use improvement. The current implementation doesn't dynamically calculate text width for
CJK characters. Node widths are set to fixed values (e.g., 120px for flowchart nodes), which works reasonably for short labels but may clip
longer CJK text. draw.io does handle CJK rendering internally, but we're not pre-measuring text to adjust geometry.
So to directly answer: it's mostly heuristic-based with fixed layouts, not leveraging draw.io's internal layout rules. The .drawio XML format
gives us the geometry, and draw.io renders it. Future improvements could include:
- Auto-layout algorithms (dagre.js style)
- Text measurement for proper sizing
- Smarter edge routing
Thanks for the interest!
Location: Tokyo/Japan
Remote: Yes
Willing to relocate: Depending on the case
Technologies: Rust, TypeScript, AWS
Résumé/CV: https://github.com/ekusiadadus
Email: ekusiadadus@gmail.com
I founded my company in Japan 3 years ago and sold it.
I'm seeking for a new opportunities. (When it comes to an exciting challenge, I'd love to hear)
I think it’s precisely because of the free sharing that we’ve been able to build such a huge market. The fact that so many engineers enjoy relatively higher salaries and strong demand compared to other professions is thanks to open-source contributions and knowledge sharing being offered for free.
I think modern websites tend to be especially overloaded with cards. Maybe tools like Claude Code just really love cards.
That said, I don’t believe card-free design is always better either. For example, subscription pricing pages often use cards effectively — they make the options much clearer.
Could you share more about the internal structure of LLM-Ex? Is it something like a fixed XML-style representation, or more of a free-form structure?
2.realized you don't need huge models to get reliable results
You wrote that
> by applying these two principles religiously, we realized you don’t need huge models to get reliable results.
Intuitively, it feels like these principles alone wouldn’t completely remove the need for larger models. Could you explain how you arrived at this conclusion, and what kind of validation or experience led you there?
Four things I found most interesting:
1. The 97M-parameter Robot-Centric model beat the 840M and 900M alternatives. Local interaction propagation matters more than global context — a finding that aligns with what we see in classical MAPF (PIBT, LaCAM).
2. Image-based representations catastrophically failed (186% congestion delay error). You cannot represent a robot as a single pixel and expect to capture fleet interactions.
3. The 13M-parameter Graph-Floor model was surprisingly competitive. This suggests the warehouse's graph topology itself is the binding constraint on coordination quality.
4. The scaling laws section experimentally confirms power-law behavior over two orders of magnitude — giving substance to the "improves over time" claim.
I also tried to translate the technical findings into economic terms using Little's Law: a 10% travel time reduction in a 1,000-robot warehouse is equivalent to ~100 fewer robots ($1.3M/year).
I build Rovnou (https://rovnou.com), which does MAPF-based fleet coordination for non-Amazon warehouses. The DeepFleet paper validates many design choices we've made (event-driven, local context, graph-first), while also showing where foundation models may eventually surpass classical solvers.
Happy to discuss the architecture tradeoffs, MAPF vs. learned approaches, or practical deployment challenges.
reply