# Does a Trained VLA Actually Run on Your Robot?

The most important question in humanoid AI right now isn't whether a [Vision-Language-Action model](https://humanoidintel.ai/glossary/vision-language-action-model) can generalize — it's whether generalization is even the right metric. A paper published today on arXiv (2608.18433) by researchers including Yukiyasu Domae, Keisuke Shirai, Hanbit Oh, and colleagues formally names the problem the field has been dancing around: the **embodiment gap**, defined as "the gap between reusable models, representations, or data and their use in execution on the target robot."

The distinction matters enormously for anyone deploying humanoids commercially. A robot foundation model (RFM) can achieve strong benchmark performance while still requiring substantial engineering work before it executes reliably on a specific hardware platform — whether that's [Figure AI](https://humanoidintel.ai/companies/figure-ai)'s upper body kinematics, Unitree's actuator configuration, or any custom build with unique [degrees of freedom](https://humanoidintel.ai/glossary/degrees-of-freedom). That residual work is invisible in most published success-rate metrics, which is precisely the paper's critique. Success rate alone does not reveal what was actually implemented to make the system run on the target robot.

The authors propose a two-axis mapping framework and a reporting standard for adaptation work — tools that, if adopted, would force the field toward more honest cross-embodiment comparisons.

---

## What the Embodiment Gap Actually Means

The scaling narrative for RFMs is familiar: more data, larger models, broader benchmarks, better generalization. That narrative isn't wrong — but it's incomplete. Domae et al. argue that even a fully generalized model faces deployment friction specific to the target robot's body. Actuator interfaces differ. Sensor modalities differ. Joint configurations and [inverse kinematics](https://humanoidintel.ai/glossary/inverse-kinematics) solutions differ. A model trained on one embodiment's proprioceptive stream may need significant adaptation work before it can usefully drive a different robot's motor commands — work that existing papers rarely account for or disclose.

This is a direct challenge to the implicit promise of cross-embodiment learning: that a sufficiently capable RFM will transfer with minimal friction. The paper doesn't claim that promise is false, but it insists the field lacks the reporting infrastructure to know whether it's true.

The survey examines existing methods across three overlapping research directions:

1. **Sharing semantics and perception** — what visual and semantic representations transfer across embodiments without retraining
2. **Sharing robot data and interfaces** — how action representations, teleoperation data, and control interfaces can be made embodiment-agnostic
3. **Learning correspondence across embodiments** — methods that explicitly model the mapping between different robot morphologies

Each direction has distinct assumptions about what the "reusable" part actually is, and each leaves different residual work for the deployment engineer.

---

## The Two-Axis Map

The paper's core analytical contribution is a two-axis map that places existing methods along dimensions of (a) the **type of shared structure** (perception, representation, data, interface) and (b) the **stage at which adaptation is needed** for execution on the target robot. This is more informative than a simple zero-shot vs. few-shot vs. fine-tuned taxonomy, because it identifies *what* must be adapted, not just *how much*.

For humanoid developers, this framework has immediate practical value. A team evaluating whether to build on top of an existing RFM checkpoint needs to know not just the published success rate, but whether the adaptation required is a calibration step, a full fine-tuning run, or a hardware-level interface redesign. Those have wildly different cost profiles.

The authors also propose a **reporting framework** specifically designed to surface adaptation work that success rate alone obscures. This would require papers to disclose the engineering steps taken to deploy a model on each new robot — a standard that would make cross-embodiment claims far more auditable.

---

## Why This Lands Hard in 2026

The timing is pointed. The humanoid industry is mid-deployment, not mid-research. [Physical Intelligence (π)](https://humanoidintel.ai/companies/physical-intelligence), [Skild AI](https://humanoidintel.ai/companies/skild-ai), and a growing roster of RFM developers are actively pitching foundation models as platforms — the idea that one trained model can run across multiple hardware partners' robots. That pitch is commercially attractive and may even be directionally correct. But the embodiment gap framework suggests the fine print on that promise needs to be legible.

For hardware companies like [Agility Robotics](https://humanoidintel.ai/companies/agility-robotics), [Apptronik](https://humanoidintel.ai/companies/apptronik), and [Unitree Robotics](https://humanoidintel.ai/companies/unitree-robotics), the practical implication is this: the integration burden of adopting a third-party RFM is not zero, and it may not be small. The embodiment gap is where that cost lives — and currently, it's almost entirely unquantified in published literature.

The [sim-to-real transfer](https://humanoidintel.ai/glossary/sim-to-real-transfer) problem is the most familiar version of this issue, but the embodiment gap is broader. Sim-to-real concerns the gap between simulated physics and real-world dynamics. The embodiment gap concerns the gap between any trained model — including one trained on real robot data — and a specific target robot it wasn't trained on. The two problems compound when a model trained in sim on Robot A needs to run in the real world on Robot B.

---

## The Reporting Framework Proposal

The most actionable part of the paper for the industry is the proposed reporting framework. The authors argue that papers should identify and disclose:

- What components of the pipeline were adapted for the target robot
- At what stage of the deployment process adaptation occurred
- What engineering work would remain if another team tried to replicate the deployment on a different hardware platform

This isn't a call for more benchmarks. It's a call for structured transparency about deployment cost — which is precisely the information a robotics engineer or a corporate strategist needs when evaluating whether an RFM is actually production-ready for their hardware.

If this framework gains traction in the community, it would shift competitive pressure toward genuinely hardware-agnostic architectures, and away from models that achieve strong benchmark numbers through undisclosed embodiment-specific tuning.

---

## Industry Trajectory

The embodiment gap concept will sharpen a division that's already forming in the humanoid stack. On one side: vertically integrated companies building RFMs specifically for their own hardware, where the embodiment gap is managed internally and never needs to be disclosed. On the other: platform-model companies claiming broad cross-embodiment applicability, who will increasingly face pressure to prove that claim with the kind of transparency Domae et al. are calling for.

For [whole-body control](https://humanoidintel.ai/glossary/whole-body-control) researchers in particular, this paper provides useful vocabulary. The gap between a learned whole-body policy and execution on a new robot with different mass distribution, actuator bandwidth, and [backdrivability](https://humanoidintel.ai/glossary/backdrivability) characteristics is exactly the embodiment gap — and it's currently measured by none of the standard benchmarks.

---

## Key Takeaways

- **The embodiment gap** is formally defined as the work required to go from a reusable RFM to execution on a specific target robot — distinct from the question of whether the model "generalizes"
- **Success rate alone is not sufficient** to evaluate cross-embodiment claims; the paper proposes a reporting framework to surface hidden adaptation work
- **Three research directions** are analyzed: sharing semantics/perception, sharing data/interfaces, and learning cross-embodiment correspondence
- **A two-axis map** places existing methods by shared structure type and adaptation stage — more diagnostic than standard few-shot/zero-shot taxonomies
- **Commercial implications are direct**: platform-model companies claiming hardware-agnostic deployment will face harder scrutiny if this reporting standard is adopted
- The paper is authored by a team including Yukiyasu Domae, Keisuke Shirai, Hanbit Oh, Ryoichi Nakajo, Tomohiro Motoda, Koshi Makihara, Masaki Murooka, Takuma Yagi, Yoshiaki Bando, and Ryo Hanai

---

## Frequently Asked Questions

**What is the embodiment gap in robotics?**
The embodiment gap, as defined in arXiv:2608.18433, is the gap between a reusable robot foundation model (or its representations or training data) and the work still required to execute that model on a specific target robot. It is distinct from generalization performance — a model can generalize well while still requiring significant hardware-specific engineering before it runs on a new robot body.

**Why don't VLA models just transfer to any robot?**
Vision-language-action models are trained on data from specific embodiments with specific actuator interfaces, sensor configurations, and kinematic structures. A new robot body differs on some or all of these dimensions. The adaptation work required to bridge those differences is the embodiment gap, and it currently goes largely unreported in published research.

**What does the paper propose to fix the problem?**
The authors propose a two-axis mapping framework that places existing methods by shared structure type and adaptation stage, plus a reporting framework that would require papers to disclose the adaptation work performed when deploying a model on a new robot — information that success-rate metrics do not capture.

**How does the embodiment gap affect humanoid robot companies?**
For hardware companies evaluating third-party RFMs, the embodiment gap represents an integration cost that is currently invisible in published benchmarks. For platform-model companies, it represents a claim — hardware-agnostic deployment — that is difficult to verify without the kind of structured disclosure the paper advocates.

**Is the embodiment gap the same as the sim-to-real problem?**
No. Sim-to-real transfer concerns the gap between simulated physics and real-world dynamics. The embodiment gap is broader: it applies even to models trained on real robot data, whenever that model is deployed on a different robot hardware platform than it was trained on. The two problems can compound when sim-trained models are cross-embodiment deployed.