Agents have reached hardware

Flow v3 is the first agentic platform for systems engineering. Built with leading hardware companies and AI research labs, it enables AI agents to perform real engineering work inside hardware development workflows, helping teams manage complexity at a scale humans alone cannot.

Agents have reached hardware.

Today we are launching Flow v3.

The era of adding more engineers to manage complexity has ended.

Modern hardware programs generate more requirements, interfaces, tests, and dependencies than any human team can continuously review. Until now, there was no alternative.

Flow v3 is the agentic platform for systems engineering, allowing AI agents to perform real engineering work directly inside hardware development workflows.

We built it with leading hardware companies and AI research labs. The rest of this post is about what became possible, and why we think it changes how hardware gets built.

Hardware engineering is entering a third era.

Systems engineering has been through two eras and is now entering a third.

The first was analog. Requirements, designs, and test results lived on paper, and hardware programs were managed through waterfall processes. Complexity was controlled through documentation, reviews, and handoffs.

The second was digital. CAD, simulation, software, and requirements databases transformed how products were built. Iterative development replaced long sequential cycles and dramatically accelerated engineering velocity.

But today's products are far more complex than the systems those tools were built for. Hardware, software, autonomy, AI, manufacturing, and certification all evolve together. The number of dependencies grows faster than engineering teams.

This is where context scaling laws matter. The more connected engineering context an intelligence can access, the more capable it becomes. Modern programs contain millions of interconnected requirements, interfaces, tests, and design artifacts. Far more than any human team can continuously reason across.

Agents change that. An agent can read the current state of a design, works out what a change would do, and then does something about it. Unlike the automation engineers are used to, it does not need a person to script every step. The work of reasoning about a design, which until now only an engineer could do, can happen continuously and across a whole program.

The hardest part of systems engineering is keeping a design consistent.

Most of the work in a large program is not the individual calculations, which are usually well understood. It is keeping the design consistent while it changes. Requirements do not stand on their own. A limit on operating temperature ties into material choice, thermal design, the mass budget, the verification plan, and the interfaces between subsystems. Change that limit and everything connected to it may have to change too. Miss one of those connections and you have a defect that often does not surface until integration or test, when it is far more expensive to fix.

The problem grows harder faster than the team grows, because what you have to track is the relationships between the parts, not the parts themselves, and relationships multiply much faster than parts do. Every engineer, tool, and agent you add creates more links that have to stay in agreement. The Airbus A380 is the clearest example. Two design groups worked in different systems, their wiring models did not match, and sorting it out added more than two years and billions of dollars to the program. Nobody lacked engineering skill. The design fell out of alignment and stayed that way too long.

Bolting AI onto today’s tools does not fix this, and can make it worse. An agent that designs quickly also produces a lot of output, and if that output sits in disconnected documents, you now have more to keep in sync, not less. An agent is only useful in engineering if it can see the whole system, including how each part depends on the others.

Flow v3 is built on a connected model of the whole system.

Flow v3 is built around the systems graph. Instead of spreading engineering information across documents and files, Flow holds the entire program as one connected model. Requirements, design decisions, interfaces, budgets, tests, and compliance evidence all live in it, and the dependencies between them are real links you can follow, not knowledge stuck in one engineer’s head. The graph is the system of record. Every engineer and every agent reads from it and writes to it.

This is what makes everything else work. Once the dependencies are written down as links, people and agents can both follow them, so the effect of a change can be calculated instead of remembered.

A change to one requirement runs through the whole model.

Because the dependencies are explicit, any change can be traced to everything it touches. Change a requirement and Flow carries the change through the rest of the model. Dependent requirements are re-flagged for review, budgets recompute, affected tests reopen, interface control documents are marked for revision, the right owners are notified, and compliance re-runs against the new state. In a document based workflow, someone does all of that by hand, and it can take days or weeks. In Flow it takes seconds, because the links needed to do it are already there.

Every artifact links back to the requirement that created it.

Everything Flow produces, including CAD geometry, interface control documents, test plans, and compliance evidence, is connected in the graph to the requirement or requirements behind it. The link goes both ways. From any artifact you can jump to the requirements that drove it, and from any requirement you can see everything it produced. In aerospace, automotive, and nuclear work, you have to be able to show why every part of a design exists, and that record is usually stitched together after the fact. In Flow it is built into the model, so it is always there.

We are at the start of a longer shift

A lot of engineering time today goes to execution rather than design: updating requirements, maintaining models, rerunning analysis after a change, and tracking down what that change broke. As agents take on more of that work, the role of the systems engineer shifts up the stack.

The engineer becomes the architect of the program itself: defining standards, encoding intent, and making the tradeoffs that shape the design. Agents operate within the harness they create, continuously tracing impact, maintaining consistency, and surfacing the decisions that require human judgment. The quality of the program increasingly depends on the quality of that harness.

The highest-leverage engineering work increasingly becomes harness engineering: building the standards, constraints, and systems that allow agents to operate effectively. The better the harness, the more the agents can do.

We built Flow v3 to be the foundation for that way of working.