Humanoid Robots: The Invisible Wall Between Pilot and Series Production

The first half of 2026 was the moment when humanoid robots stopped being demonstrations and became industrial projects. Calvin, the robot from the French startup Wandercraft, tested since February at the Renault plant in Douai on tire handling, is meant to become fully operational on a production line. Since April, BMW has been testing the Aeon robot from Sweden's Hexagon in its Leipzig plant, with integration targeted for the summer. Siemens and Agile Robots put humanoids to work in the Erlangen plant on container transport tasks. At VivaTech, the Chinese Embodied AI demonstrations confirmed that Beijing now treats humanoid robotics as a strategic sector on par with semiconductors, and Agibot claims more than 5,000 robots delivered, with European production starting at the supplier Minth.
The assessment made by the European manufacturers present at VivaTech is clear-eyed: competition is no longer played out solely on the quality of the robots, but on the ability to produce at scale and to reduce costs quickly. Morgan Stanley projects annual demand of 1.5 million units by 2035.
So everyone is watching the same question: who will manage to move from pilot to series production? And almost everyone is watching it from the same angle: production cost, supply chain, mechanical reliability. These topics are real. But our experience with robot manufacturers has taught us that there is a less visible wall, one that robotics scale-ups crash into with remarkable regularity: the wall of configuration management.
The pilot forgives everything, series production forgives nothing
An industrial pilot, like those in Douai or Leipzig, is an environment of maximum tolerance. Three to five robots, a team of engineers from the manufacturer on site, software updates pushed by hand, hardware adjustments made case by case, a customer who accepts iteration because they are buying learning as much as performance. In this context, the question "what exactly is this robot's configuration?" has a simple answer: ask the engineer who takes care of it.
pilot to series · the configuration wall
The pilot forgives everything. Ask the engineer on site. The series forgives nothing.
5
Robots
1
Client sites
10
Versioned subsystems
1
Updates / yr
Deployed configuration space
50
robots x subsystems x versions
Series production changes everything, and not linearly. Take a manufacturer moving from 5 robots in pilot to 500 robots deployed across 40 customers. Each robot is now a unique combination: a hardware version (with the component evolutions that are inevitable over eighteen months of production), a software version of each subsystem (perception, locomotion, manipulation, safety), AI models in specific versions, settings specific to the customer site, options and accessories, and a maintenance history.
Multiply it out: 500 robots, around ten versioned subsystems, quarterly updates, customer variants. The space of configurations actually deployed explodes. And with it, three problems the pilot never posed.
First problem: support. When a robot behaves abnormally at a customer site, the first diagnostic question is its exact configuration. If the answer takes a day of reconstruction from logs, tickets and team memory, the support cost per robot makes the business model untenable.
Second problem: fix propagation. When a defect is identified on a version of a component or a piece of software, you have to answer within hours: which robots, at which customers, in which configurations are affected? This is a question of pure traceability. A slow or wrong answer turns a defect into a crisis.
Third problem: conformity. Every robot delivered in Europe is a machine in the regulatory sense, and from January 2027 a machine in the sense of the Machinery Regulation (EU) 2023/1230, with its reinforced requirements on software, cybersecurity and systems with evolving behavior. Conformity is assessed by configuration: this hardware-software-settings combination has been evaluated, that one has not. A manufacturer that does not have control over its deployed configurations does not know, in the strict sense, whether its robots are compliant.
Why the pilot's tools do not scale
Robotics scale-ups arrive at the threshold of series production with a typical tool set: a disciplined Git repository on the software side, a PLM or CAD tool on the mechanical side, a ticketing tool for anomalies, and spreadsheets for everything that connects these worlds. That last point is the crux of the problem.
Because the definition of a robot is neither in Git nor in the PLM: it is in the relationship between the two, plus the AI models, plus the settings, plus the requirements that all of this must satisfy. Yet this relationship is the object of none of the tools in place. It lives in compatibility matrices maintained by hand, in wiki pages, in the head of the VP Engineering.
As long as the company has thirty engineers, this implicit knowledge circulates. With one hundred and fifty engineers spread across mechanical, electronics, embedded software, AI and quality, it no longer circulates: each team optimizes its own part, and overall coherence becomes the full-time job of a few integration heroes, bottlenecks for the entire organization.
The symptom is always the same, and the leaders of robotics scale-ups will recognize it: integration reviews get longer, unexplained regressions multiply, deliveries require increasingly painful "configuration freezes", and no one can quickly produce the answer to a question that is nonetheless simple: "what changes between the config delivered to customer A and the one for customer B, and which tests cover that gap?"
What the players who get past the wall do
The manufacturers who succeed at industrialization share one architectural decision: they treat the definition of the robot as a first-class object, managed in a structured repository, and not as an emergent property of their business tools.
Concretely, this means a repository where the following exist as connected objects: the requirements (customer, regulatory, internal); the system architecture and its interfaces; the hardware elements with their versions and their bills of materials; the software components and AI models with their versions; the reference configurations and the deployed configurations, robot by robot; the verification and conformity evidence, attached to the versions it covers.
On this basis, the three problems of series production change in nature. Support queries the configuration of a serial number in seconds. Fix propagation is a graph traversal: from the defective version to all the configurations that embed it, to all the robots concerned, to the customers to be notified. Conformity becomes demonstrable by construction: each delivered configuration is linked to the evidence that covers it, and the gap between a new configuration and the last evaluated configuration is computable, which is exactly what the substantial modification regime of the Machinery Regulation requires.
This is the architecture that Koddex brings to robot manufacturers: a graph-based Engineering OS that connects requirements, hardware and software bills of materials, configurations and evidence, and that makes impact analysis instantaneous. Our conviction, forged alongside European robotics players in hypergrowth, is that this capability is as decisive for industrialization as a well-designed factory.
The competitive argument against the Chinese wave
Let us return to global competition, because it gives this subject a strategic dimension. Faced with Chinese players who already produce in the thousands and compress costs at a pace that Europe cannot match in the short term, what is the defensible advantage of a European manufacturer?
The answer taking shape among manufacturers and in the regulation is clear: demonstrable trust. European customers, themselves subject to growing obligations (the Machinery Regulation, sector requirements, deployer responsibility), will buy robots whose safety, cybersecurity and control of changes are documented and auditable. It is no accident that Agibot chooses to produce in Minth's European plants precisely to meet the continent's regulations on safety and quality.
For a European manufacturer, end-to-end traceability is therefore not a compliance constraint: it is the foundation of its positioning. Being able to tell a major carmaker "here, for every robot in your fleet, is its exact configuration, the conformity evidence that covers it, and our propagation time for a critical fix" is an argument that price alone does not beat, in the regulated markets that are precisely those where Europe is strong.
Conclusion: to industrialize is first to structure
The year 2026 proved that humanoids can work in factories. The question of the next three years is who will manage to deliver thousands of them without support, quality and conformity blowing up. This move to scale has a precise technical condition, less photogenic than a locomotion demo but just as decisive: configuration management, carried by a structured engineering repository.
The pilot in Douai or Leipzig is won with an excellent robot. Series production is won with an excellent robot and excellent data. The manufacturers who understand this before their first framework contract will approach the humanoid decade from a position of strength.
Sources
- Calvin, a new-generation robot is born (Renault Group, 2026)
- BMW Group: First humanoid robot introduced in Plant Leipzig (BMW Group, 2026)
- Siemens and Humanoid test HMND 01 Alpha for logistics tasks (The Robot Report, April 2026)
- AGIBOT Showcases Embodied AI Robots at VivaTech 2026 in Paris (Business Wire, June 22, 2026)
- China's Agibot to make robots for auto industry in Europe (Automotive News, March 2026)
- Regulation 2023/1230/EU - machinery (EU-OSHA, applies 20 January 2027)
Koddex helps robot manufacturers master requirements, hardware and software configurations and conformity evidence in a single repository. Let's talk about your move to series production.






