Head of Robot Learning

You'll be Anvil's first robot learning hire — the person who takes the papers everyone is retweeting, gets them running on our hardware in weeks, and ships them as demos and guides polished enough that the whole field notices.

Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. In our first 12 months we built and shipped 200+ robots (OpenARM and OpenYAM manipulators, Linux Devboxes, teleop kits, and a UMI-style handheld data-collection device) to customers in 60+ countries, doing over $2.1M in revenue on our own Taipei manufacturing line.

And here's what makes this seat unusual: not how much data we have — how much leverage you'd have over what gets collected. Most robot learning engineers work with whatever data someone else decided to collect, on rigs they can't change. Here, the entire collection system bends to your judgment — and there's a factory behind it. We design and build our own UMI-style handheld collector in-house, on our own Taipei manufacturing line, sitting inside the Asia supply chain: if the data would be better with a different camera, a different mount, a new sync scheme, or a custom fixture that doesn't exist yet, you prescribe it and it gets built — in weeks, not procurement quarters. We have factory access most teams can't get — our own facility and our investors' and partners' plants — meaning differentiated, real-industrial-task data rather than the same recycled public datasets. And we have people who can do the collection work if you write the protocol: you prescribe what good data looks like, they collect it. Let's be honest about scale, because it matters: this is not a foundation-model data operation, and we're not pretending it is. It's the setup to reach LeRobot-shirt-folding scale — hundreds of high-quality demonstrations of the right task, on tooling shaped to your spec — with more control and less friction than almost anyone in the field gets.

The situation you're walking into:

• We have 200+ robots in the field and zero dedicated ML function. Model training happens in the gaps between the founders' and controls engineers' actual jobs. You are hire #1 for the entire robot learning function, and for the foreseeable future the team is you.

• We ship a UMI-style handheld data-collection device — and nobody has yet closed the loop of training a policy purely from its data and running it on our arms. Validating that pipeline end to end is a product decision waiting on you, and it's one of your first deliverables.

• Robot learning is compounding weekly — VLAs, diffusion policies, ACT, world models. At our stage the highest-leverage move is not novel research; it's replicating the best public work on our hardware fast, and publishing it. Think the LeRobot shirt-folding project — data to deployment, in the open — running on Anvil arms, with our name on the guide.

• Demos are not vanity here. A flagship replication is simultaneously marketing to the exact community that buys us and the enablement guide our customers follow. Which means the last 10% — the clean repo, the honest success rates, the written guide, the good video — is where most of the value lives. We need a builder with a real knack for polish before calling a project done.

• The collection system above is built but undirected. The UMI exists and can be revised to your spec, the operators exist, the factory access exists — but nobody with ML judgment decides what to collect, how, and what "good" looks like. The leverage is sitting there; the person who prescribes it doesn't exist yet.

What you'll own:

• Training pipelines, end to end: teleop and UMI data ingestion, dataset formats and quality triage, training jobs, and an eval harness with honest success-rate protocols — built so that eventually someone who isn't you can train a model.

• Paper replication → published demos: picking the highest-leverage public work (folding-class manipulation, VLA fine-tunes, diffusion policies), getting it running on Anvil hardware in weeks, and shipping it as a public demo video + reproducible guide.

• UMI pipeline validation: being the person who proves — or fixes — the path from our handheld data collector to a working policy on an OpenARM. The UMI is built in-house, so your findings don't end as feedback — they become hardware revisions you prescribe.

• The data flywheel: DAgger / human-in-the-loop correction workflows on our teleop stack, so policies improve from intervention data instead of plateauing after the first training run — and, as your protocols mature, scaling collection beyond yourself: designing what dedicated data-collection operators record in our factory and, over time, in partner facilities.

• The polish bar: nothing you ship stops at "works on my machine." Every project ends with the video, the guide, and the repo someone else can run.

What the first 100 days look like:

• By day 30: your rig is set up, and a first policy (ACT or Diffusion Policy class) trained on Anvil-collected data is running on real hardware. You have a written map of where our stack fights you.

• By day 60: the UMI pipeline is validated end to end — a policy trained purely from handheld-collected data, running on an OpenARM — with a clear-eyed writeup of what's broken in the pipeline and what to fix.

• By day 100: your first flagship replication (folding-class) is live on Anvil hardware and published — demo video, honest success rates, reproducible guide.

Who you are:

• You've personally trained and deployed imitation-learning policies — ACT, Diffusion Policy, VLA fine-tunes — on real robot arms. Not cloud benchmarks: real motors, real cameras, real failures.

• You're fluent in the layer under the model, because that's where deployments die: action chunking and temporal ensembling, inference latency versus control-loop frequency, camera synchronization and timestamp alignment, joint-space versus cartesian command interfaces.

• You replicate papers in weeks. Given a paper and a repo, you know what will transfer, what won't, and where the unreported gotchas hide.

• You have data instincts: you can scrub through teleop demonstrations and see what's wrong — inconsistent grasps, occlusions, timing skew — before wasting a training run on it.

• You're a finisher. Your projects end with a guide, a video, and a repo with a README — and you know the difference between a demo that worked once on camera and one with a measured success rate you'd defend.

• You're honest about results. You report n, the eval protocol, and the failure modes — especially in public.

• You're comfortable being the only ML person in a fast, lean, founder-led company, setting your own agenda and shipping on a weeks-not-quarters cadence.

• Bonus: LeRobot or similar open-source contributions; DAgger / interactive imitation learning experience; public demos that got real reach; RL fine-tuning on real hardware.

• Based in or willing to relocate to San Francisco, Hong Kong, or Taipei. This role needs to sit with robots, cameras, and a GPU box, wherever that is — Taipei puts you next to the hardware team, SF next to the demo room and customers. Flexible hours for cross-timezone collaboration either way.

Education & experience:

• Master's or Bachelor's in CS, robotics, or a related field — a PhD is explicitly not required or expected, and a publication record is not the bar. Your portfolio is: policies you personally trained running on real hardware, with the repos and videos to prove it.

• Years matter less to us than trajectory. A typical req for a "Head of Robot Learning" would ask for a PhD plus 5–8 years; we're looking for 2–4 unusually fast-growing years — or 1–2 on a steep curve — spent as the research engineer beside a strong robot learning lead: the person who made the lab's or team's work actually run on hardware, closed a growing share of the hard problems personally, but never owned the direction because someone above them did. This role is the first time the wheel is yours.

What this role is not:

• Not a research role. No publication mandate, no novel architectures for their own sake. You're making the frontier run on our hardware, not extending it.

• Not a cloud ML role. If your experience is training and eval with no physical robot in the loop, this isn't the seat.

• Not a management seat. "Head of" means you own the function; the team is you, possibly for a year or more.

• Not a solutions-architect role. The deliverable is never a plan or a memo — it's a policy running on an arm and the published artifact around it.

• Not a role for 90%-done builders. If your projects historically end at "it worked, moving on" — before the writeup, the video, the reproducible repo — our polish bar will chafe daily.