The demonstration videos for humanoid robots share a common feature: the robot operates alone, or nearly so. It picks up an object in a tidy workspace. It walks through an open hallway. It folds a shirt on a clean table. These are genuine technical achievements. They are also, deliberately or not, exercises in isolation — the robot doing something impressive in a context stripped of the surrounding systems, people, and organisational infrastructure that define any real workplace.

The harder question — and the one that will actually determine whether humanoid robots move from pilots to widespread deployment — is what happens when the robot needs to connect to everything else. The warehouse management system that tells it what to pick. The ERP platform that tracks inventory. The safety protocols written for human workers. The shift schedule. The maintenance ticketing system. The network that may or may not provide reliable connectivity. The IT department that has opinions about what gets connected to what.

This is the integration problem, and the industry is largely quiet about it.

What “Integration” Actually Means

Integration, in the context of deploying any kind of automation in a real facility, means two overlapping things. The first is technical: the robot’s systems need to communicate with the facility’s existing systems, exchange data in formats those systems understand, and operate within the constraints of the facility’s IT infrastructure. The second is operational: the robot needs to fit into the workflows, protocols, and organisational structures that govern how work gets done, who is responsible for what, and how problems get resolved when they arise.

Both dimensions are harder for humanoid robots than for most previous generations of automation, for a reason that is often overlooked: the humanoid form factor exists specifically to operate in human-centric environments. That’s its value proposition. But human-centric environments were designed for humans, not for robots — and the systems that run those environments were built with human operators in mind. Connecting a robot to those systems is not a plug-and-play exercise.

The Software Integration Layer

Start with the software. A warehouse running modern operations typically uses a warehouse management system (WMS) — software that tracks inventory locations, generates pick tasks, manages order fulfilment, and coordinates workers. Major WMS platforms include SAP Extended Warehouse Management, Manhattan Associates, Blue Yonder, and dozens of others. These systems are not standardised. They have different data models, different APIs (the interfaces through which external software communicates with them), different authentication requirements, and different update cadences.

For a humanoid robot to receive a task — “pick SKU 4821 from bin 7C-14 and bring it to packing station 3” — it needs to be able to receive that instruction in a format it can act on, and it needs to be able to report back when the task is complete, or when it encountered an error. That sounds straightforward. In practice it requires building and maintaining a software integration layer between the robot’s own control systems and the specific WMS version running in that specific facility.

This integration layer has to handle version changes on both sides. When the WMS vendor releases an update that changes its API, the integration may break. When the robot manufacturer updates the robot’s software, the integration may need to be tested and re-certified. In facilities running older WMS versions — which describes a substantial fraction of manufacturing and logistics operations — the integration layer may need to work around systems that have not been updated in years and whose original developers are long gone.

The robot companies building humanoid systems are aware of this. Several have described plans for “fleet management platforms” that sit between the robots and the facility’s existing software, handling the translation. Agility Robotics has described its Agility Arc software platform in these terms. Figure AI has talked about its fleet management layer. The specifics of how these platforms handle the diversity of real-world enterprise software environments remain largely unannounced — which is either because the details are commercially sensitive, or because the problem is harder than the high-level descriptions suggest, or both.

Network and IT Infrastructure

Humanoid robots operating autonomously in a facility need reliable network connectivity. A robot receiving tasks wirelessly, streaming sensor data, or checking in with a remote supervision system depends on the facility’s network infrastructure performing within the tolerances the robot’s software expects. In many facilities, that is not guaranteed.

Manufacturing plants and warehouses vary enormously in their wireless network coverage. Older facilities may have significant dead zones. Metal shelving and machinery interfere with Wi-Fi signals in ways that are hard to predict from a floor plan. Facilities running older wireless standards may not provide the bandwidth or latency that a robot’s real-time control requirements demand. Upgrading network infrastructure to support robotic deployment is possible but adds cost and complexity to what already looks like an expensive pilot.

Beyond connectivity, there is the IT security dimension. Enterprise IT departments have grown substantially more cautious about what gets connected to operational technology networks over the past decade. A humanoid robot is, among other things, a networked device with cameras, microphones, and sensors that can capture data about a facility’s operations, layout, and workforce. It runs software that will need to be updated remotely. It communicates with servers operated by the robot manufacturer, which means data flows outside the facility’s perimeter. IT and security teams at facilities considering humanoid deployment will want to understand what data leaves the building, under what conditions, encrypted how, retained for how long, and accessible by whom.

These are not unreasonable questions. They are the same questions that enterprise IT teams ask about any new connected system. But they add time and negotiation to deployment timelines that robot companies’ forward projections rarely account for explicitly.

Safety Protocols Written for Humans

Workplace safety in industrial environments is governed by a combination of regulatory requirements, site-specific protocols, and established practices developed over decades. These protocols were written with human workers in mind. They specify how workers signal that equipment is locked out for maintenance, how emergency stops function, how workers are supposed to behave around moving machinery, and what happens when an incident occurs.

Introducing a humanoid robot into this environment raises questions that existing protocols do not cleanly answer. What happens when a robot encounters an emergency stop signal designed for a human operator to activate? Does it recognise that signal? Does it respond correctly? Who is responsible for verifying that it does? If a human worker sees the robot behaving unexpectedly and needs to stop it, what is the correct action — and is every worker on the floor trained to take that action?

The robot manufacturers do not resolve these questions on their own. They can provide documentation, design physical emergency stop buttons on the robot itself, and specify protocols for their systems. But implementing those protocols in a way that integrates with the facility’s existing safety management system — and satisfying the relevant regulatory body that the combined system meets applicable standards — is work that falls to the operator of the facility. That work takes time, involves human resources and safety officers who have their own timelines and priorities, and may require third-party certification depending on jurisdiction and industry.

The safety certification gap — the absence of standards specifically designed for humanoid robots — makes this harder. When integrating a conventional industrial robot with a fixed installation point and a defined working envelope, there are established standards to follow. Humanoid robots that move through shared spaces, work alongside human colleagues, and operate across variable task types do not fit cleanly into those standards. Facilities are effectively developing their own integration protocols case by case, which is both slow and an obstacle to scaling deployment.

Organisational and Workforce Integration

Beyond the technical and safety dimensions, there is the question of how humanoid robots fit into the human organisations they join. This is probably the least-discussed aspect of the integration problem, and arguably the most consequential for whether pilot deployments succeed or stall.

A facility deploying a humanoid robot is not just deploying a machine. It is changing how work is allocated, how tasks flow through the operation, and what the humans working alongside the robot are expected to do when something goes wrong. Workers need to know what the robot is supposed to be doing, what they should do if it stops or behaves unexpectedly, who to call when there’s a problem, and whether their own job description has changed in ways that weren’t communicated clearly. Supervisors need to understand how the robot fits into their accountability structure — if the robot fails to complete a pick task, who is responsible for ensuring the task gets done?

These questions are solvable, but they require deliberate organisational work. The facilities that have reported the most successful early deployments of automation technology — including autonomous mobile robots, which are considerably simpler than humanoids but faced many of the same integration challenges — are typically those that invested in change management alongside the technical integration. They trained workers before deployment, created clear escalation paths for problems, and designated people within the facility who owned the relationship with the technology.

For humanoid robots, this organisational integration work is if anything more demanding than it was for previous automation generations, because the humanoid form factor operates in closer proximity to human workers, across more varied tasks, and in more ambiguous situations where clear protocols are harder to specify in advance.

What This Means for Deployment Timelines

The integration challenge has a practical implication for anyone reading announcements about humanoid deployment partnerships: the gap between “we have signed a deployment agreement” and “robots are running full autonomous shifts in production” is longer and harder than the announcement typically suggests, and integration work is a significant part of why.

Amazon and Agility Robotics have been running Digit in Amazon facilities since late 2023. As of mid-2026, the deployment remains in an evaluation and expansion phase rather than a full production rollout. BMW and Figure AI announced their partnership in January 2024; specific details about production deployment status have not been publicly confirmed. These timelines are not necessarily evidence of technical failure — they may reflect the unglamorous but real work of building integration layers, negotiating IT requirements, updating safety protocols, and training workers.

The integration problem is not a reason to be pessimistic about humanoid robotics. It is a reason to be accurate about it. The technology that enables a humanoid robot to walk, perceive, and manipulate is genuinely advancing. The ecosystem of software standards, enterprise integrations, safety frameworks, and organisational practices needed to deploy that technology at scale is earlier in its development. Both things are true, and the second one gets far less coverage than the first.

The companies that figure out integration — not just the robot hardware and software, but the full stack of enterprise connectivity, regulatory compliance, and organisational fit — will have an advantage that is harder to copy than a demonstration video. The hardware specs of any given humanoid system will be matched or exceeded by competitors within a few product cycles. A proven, repeatable integration playbook that works across the messy diversity of real industrial environments is a different kind of asset.