Robotics Applied Research Lead
Here at Humanoid, we believe in a future where robots amplify human potential. That’s why we’ve set out on a mission to build the world’s most capable, commercially-scalable, and safe humanoid robots. We’re bringing that mission to life with HMND‑01 - our rapidly developed humanoid platform being deployed in real industrial environments - and we’re growing the team to take it even further.
About the Role
The Robotics Applied Research Lead establishes and leads Humanoid’s AI research and engineering function.
You decide which Physical AI data problems we work on, define how we test them, and stay directly involved in the most important technical work. You connect four areas that often sit apart:
Multimodal and embodied data
Transformer-based models and how data impacts robot policies
Rigorous offline and real-world evaluation of policies
Deployment of models in the data ecosystem
This is a player-coach role. In the first year, at least half of your time is direct technical work: designing models and experiments, reviewing or writing code, inspecting data, debugging training, examining failures, and reviewing robot rollouts.
You will also build a small research and engineering team. Add people only when the work requires them.
Mandate
Turn Humanoid data and technical access into measurable advances in Physical AI systems.
You own the answers, and the evidence, to questions such as:
Which model families should we train, adapt, or evaluate?
Which data produces meaningful gains in robot performance?
What coverage, sensors, annotations, and quality controls do the models require?
Which offline measurements predict real-world robot performance?
Where should we adapt existing open models rather than train from scratch?
What should Humanoid build itself, and what should it reuse or obtain through partners?
What You'll Do
Set the technical direction: Define a focused research and engineering roadmap. Select a small number of high-value bets with clear hypotheses, baselines, milestones, and stop criteria. Decide what we build, adapt, license, or access through partners. Drop work that no longer has a strong case. Likely scope includes vision-language-action models, multimodal Transformers, robot foundation models, action representation, imitation and reinforcement learning, world models, cross-embodiment transfer, data-efficient adaptation, and robot-policy evaluation.
Own Transformer research and engineering: Design, adapt, train, and evaluate Transformer-based systems for embodied tasks. Make the architecture and training decisions yourself. Start from strong existing models and baselines. Train from scratch only when evidence supports the cost. Build or review the critical code.
Connect models to data strategy: Define the data needed to train and evaluate the selected models. Specify sensors, modalities, annotations, mixtures, and quality controls. Measure the effect of data quality, diversity, and composition on model behavior. Distinguish data volume from data value. You set technical data requirements; you do not run annotation workforces or field collection.
Own evaluation: Establish offline and real-world evaluation systems, baselines, held-out conditions, and release gates. Guard against leakage, overfitting, and weak success definitions. Compare offline metrics with real-robot outcomes. A benchmark score alone is not a successful result. The evaluation must support a decision.
Move work onto physical systems: Take projects from problem definition through training, hardware integration, and real-world testing. Design safe test plans and staged deployment. Analyse failures across data, perception, model, control, hardware, and environment. Validate material claims on physical systems.
Build a small technical team: Recruit a few complementary researchers and engineers. Lead architecture, experiment, code, and failure reviews. Keep the team focused on validated results, not paper count, benchmark theatre, or headcount.
Represent the function and own responsible development: Explain the strategy to customers, partners, and investors. Convert customer needs into testable technical requirements. State uncertainty and limits clearly. Define safety constraints, supervision, and rollback paths for physical trials. Require reproducible evidence before making capability or safety claims.