Almost every manipulation demo you've seen is a single arm on a fixed base, reaching for something that isn't moving, on a table that isn't tilting. That's a reasonable place to start - it's also a much smaller problem than the one that actually matters. A body that has to lift with both arms while staying balanced on two legs, or reach with one hand while bracing with the other, is coordinating a much larger action space under much tighter timing than a stationary arm ever has to.
Why this breaks single-arm assumptions
The DuoCore-FS paper - the same asynchronous fast/slow architecture from our full-duplex post - is explicit about why it needed to solve async control in the first place: whole-body manipulation involves more joints, larger motion spaces, and dynamically changing views, and a single unified control frequency simply can't keep up once you're no longer just moving a wrist. Balance, locomotion, and manipulation stop being separate problems and start fighting for the same control bandwidth in real time.
A few recent papers deal with this collision directly, each picking a different point to split the problem:
AMO (Adaptive Motion Optimization for Hyper-Dexterous Humanoid Whole-Body Control) treats the arm-reach and the whole-body balance response as something that has to be optimized jointly rather than handed to two separate controllers that don't know about each other - the whole point being that a humanoid's effective reach depends on how its legs and torso are compensating underneath it, not just on arm length.
CWI (Composite Whole-Body Imitation) takes the opposite approach on purpose: it decouples motion-capture-driven upper-body manipulation from a separately-trained locomotion policy guided by an adversarial motion prior, then reconciles the two with a multi-critic architecture built specifically to reduce conflicts between locomotion, manipulation, and motion-style objectives - an explicit admission that training one policy to do everything at once creates competing objectives that fight each other during learning.
FALCON (force-adaptive humanoid loco-manipulation) pushes on a different axis entirely: most whole-body control work focuses on tracking motion, not on responding to contact force - but pushing a heavy door or leaning into a load requires the whole body to adapt to force feedback, not just follow a precomputed trajectory.
WholeBodyVLA, accepted to ICLR 2026, folds this into the vision-language-action lineage directly - learning unified latent actions from egocentric video and decoding them into dual-arm joint actions and locomotion commands together, rather than bolting a VLA arm-policy onto a separately-engineered walking controller.
The honest state of it
None of this is fully solved, and the papers say so plainly. Decoupled approaches like CWI sidestep the joint-optimization problem but need careful reconciliation to avoid the two halves working against each other. Joint approaches like AMO get tighter coordination but a much harder optimization problem. Force-adaptive control like FALCON is still a narrower slice - most whole-body systems still assume the world doesn't push back. There's no consensus yet on where the seam between “upper body” and “lower body” should go, or whether there should be a seam at all.
Where this sits for us
This is the direction our own roadmap points after a single-arm MVP - not because a humanoid is the interesting part, but because the coordination problem is. A system that's already built around asynchronous, non-blocking loops for a single arm (our full-duplex post) has a real head start here: whole-body control is the same “don't let one slow subsystem block a faster one” problem, just with balance and locomotion added as two more things running concurrently instead of one arm alone. It's a scaling test for the architecture, not a separate architecture.