How Mytra uses Flow to build as fast as its hardware moves

Mytra builds some of the most complex hardware in robotics with a small team. Flow is the system that keeps their requirements, risks, and tests coordinated while giving them the leverage of a larger team

What Mytra is building

Mytra is building a software-defined universal material flow system. In simpler terms, it is a new way to move and store material inside a factory or warehouse. Rather than relying on fixed wracks, conveyors, and aisles, Mytra handles it with just three components: bots, software, and cells. Material moves from one point to another in three dimensions, and the robots have full kinematic freedom to get it there.

The technical ambition is reflected in the hardware itself. The robots can lift 3,000 pounds using Mytra's patented Helix design, achieve 99.999% uptime through redundant bots and pathways, navigate with 11 onboard cameras, and deliver 150 presentations per hour. All of it is being built by an intentionally small team.

The robots are only part of the system. Mytra builds the tall, three-dimensional grid of storage cells the robots move through, which can stretch in any direction and rise as high as a facility allows. It also builds the perception system each robot uses to understand its surroundings and avoid collisions (onboard cameras, an IMU, and a wireless connection), along with the software that plans the robots' routes, keeps them out of each other's way, and can rearrange the whole layout on demand. Capabilities like slotless inventory, dynamic parallelization, and self-healing redundancy are built into that software layer rather than the hardware. Each of these systems has its own set of requirements, and they all have to stay consistent with one another.

The challenge

This complexity is also deeply interconnected. Every robot, structure, and interface combines all of those disciplines at once, such that none of them can be designed in isolation. A single firmware iteration can generate a long list of new requirements, and a requirement owned by one team can quietly reshape what another team needs to build. For a small team moving quickly, this is where projects tend to break down: the plan and the testing fall out of sync, and no single tool gives a complete picture.

The conventional answer is a traditional requirements tool, but those were designed to document a design after it settles, not to keep pace while it is still changing. At Mytra, interfaces evolve from week to week, and a test that passed last sprint may no longer map cleanly to the requirement it was written against. Tracing the effect of a single change means digging through documents, spreadsheets, and conversations, which is time a small team would rather spend building. The more the design iterates, the worse that overhead becomes.

So Mytra's systems team set out to find a tool that could keep up, and that search led them to Flow.

How Mytra works in Flow

Mytra keeps its requirements, risks, and tests in Flow, all linked to one another. When a requirement changes for one team, the team can follow those links to see which other teams are affected, rather than discovering it weeks later. The tests that verify a requirement stay attached to that requirement, instead of living in a separate tracker that has to be kept in sync by hand.

Because all of this work lives in one connected place rather than in private documents and one-off spreadsheets, a change made by one engineer is visible to the others right away. There is no outdated snapshot to reconcile and no scramble to pull information together before a review, because everyone is already looking at the current state of the product.

Mytra also uses Flow to keep its plan and its testing aligned. By tracking what the plan is, testing against it, and continually confirming that the two still match, a small team can keep a clear picture of a project's full scope from start to finish.

Built for the speed of hardware

Most requirements tools were designed for a slower style of development, where a design is locked early, documented once, and verified at the end. Mytra does not work that way. Its firmware, mechanical, and software teams all iterate on their own timelines, and a change in one area can ripple through the others within a day. A system of record has to keep up with that pace, or it falls behind the product it is meant to describe.

Speed alone is not enough in hardware, where a single missed requirement can mean a failed test or a damaged machine. By keeping requirements, risks, and tests connected, the team can move quickly without sacrificing rigor: the plan and the tests are checked against each other continuously, rather than reconciled in a rush before each milestone. This is what allows a small team to manage all the moving parts across every robot, structure, and interface without losing track of any of them.

Agents on the team

There are limits to how much of this a team can manage by hand. As the number of requirements grows and the dependencies between teams multiply, keeping everything aligned becomes more work than a small team can reasonably take on. This is the gap Mytra expects agents to help fill: watching for the downstream effects of a change, flagging requirements that have fallen out of sync, and handling the connective work that would otherwise consume engineering time.

Agents can only do this well if the underlying data is reliable. An agent working from outdated documents or scattered spreadsheets will produce results that are just as unreliable. A live system of record, where requirements, risks, and tests are kept current and connected, is what makes agents useful in engineering. By establishing that foundation now, Mytra is preparing to put agents to work as the technology matures.

What changed

The most visible result has been speed. With requirements, risks, and tests finally moving together, Mytra’s engineers spend less time reconciling tools and more time building. Before a project begins, Mytra can see the full scope of work in one place, which makes it possible to commit to a plan and understand what finishing it will actually require. Fewer changes slip through unnoticed, which means fewer surprises when it is time to test.

None of this replaces engineering judgment. What it does is remove the friction that used to sit between having a plan and trusting it, so that a small, ambitious team does not have to trade away rigor to move quickly.

For a company setting out to rebuild how material moves through the world's factories and warehouses, the ability to move faster without losing control is exactly what the work demands.