We are looking for engineers to join the RLWRLD team in Tokyo. The roles are based in our office in Hongo, Bunkyo-ku, in the same neighborhood as the University of Tokyo's engineering campus. We are a small team, currently five people. These roles would bring us to eight, and each person would have a large footprint on the technical direction of what we build.
This post is longer than a typical job listing because we think the people we want to hire should understand in detail what the work looks like before they apply. People who join early-stage deep tech companies and thrive are typically the ones who thought carefully about what the actual day-to-day looked like rather than signing up for an abstract mission statement.
What We Are Building, in Technical Terms
RLWRLD builds a foundation model for robot manipulation in factory settings. The core technical claim: a single model, trained once on industrial parts data, can generate valid grasp and placement policies for part geometries it has never seen before, without the cell needing to be re-programmed for each new SKU.
The current architecture processes depth sensor point clouds through a patch tokenization front-end, encodes object-centric representations for each detected part in the scene, and passes those representations through a grasp policy head that outputs a distribution over candidate grasp poses. A contrastive training objective across shape-family groupings drives the generalization behavior. Sim-to-real transfer is handled through domain randomization calibrated against real sensor data from industrial hardware.
The hardware targets are standard industrial 6-DOF arms with depth cameras mounted at fixed or wrist positions. We have run evaluations on FANUC LR Mate hardware, and our next evaluation target is a Kawasaki Duaro 2 cell at a partner site. The model runs inference at the edge on a workstation-class GPU mounted in the cell control cabinet, not in the cloud. Latency and deployment constraints are real constraints, not afterthoughts.
Research Engineer
The Research Engineer role sits at the intersection of model development and evaluation infrastructure. What it involves: developing and running ablation studies on the patch tokenization and contrastive training components, maintaining and extending the simulation environment used for training data generation, designing and running evaluation protocols on real hardware, and contributing to the architecture decisions that determine what gets trained and how.
We are looking for someone who has done serious research-engineering work in 3D perception or robot learning and can operate independently on multi-week experiments. Experience with point cloud processing and familiarity with PyTorch3D or Open3D is the most relevant technical background. You do not need a PhD, but you should have done work at a level of depth that would be publishable, because that is the kind of rigorous thinking the role requires.
The honest challenge of this role: our evaluation cycles are slow because real-hardware testing is slow. If you are accustomed to running 50 experiments per day in a fast-feedback software environment, the rhythm of waiting for physical evaluations takes adjustment. We compensate by designing careful experiments and getting maximum signal from each hardware run. That design discipline is something we are looking for in candidates.
Robotics Software Engineer
The Robotics Software Engineer role owns the integration layer between our model and real robot hardware. What it involves: ROS2 node development for sensor data ingestion and robot command interfaces, calibration tooling for depth camera extrinsics in factory cell configurations, force-torque sensor integration for the compliance components of our model, and reliability engineering for the production deployment pipeline.
The most important background for this role is experience with real robot hardware deployment, specifically the frustrating parts: sensor calibration drift, communication timing issues between perception and control, handling hardware states that differ from what simulation predicted. We are not looking for someone who has written ROS examples in a research lab. We are looking for someone who has debugged a robot cell that was working yesterday and is not working today, and who finds that problem interesting rather than tedious.
This role will interface directly with automation engineers at manufacturing sites when we are doing evaluation deployments. Technical communication with people who are not model researchers, but who have deep practical knowledge of robot cell operation, is an important part of the work. Understanding what they know and incorporating it is how we validate and improve the model.
ML Engineer
The ML Engineer role owns the training pipeline: data management, training infrastructure, and the tooling that makes it fast and reliable to iterate on model changes. What it involves: maintaining the training data ingestion pipeline from simulation and real-sensor sources, managing training runs on our GPU cluster, developing evaluation dashboards that give the research team real-time visibility into model behavior across the part categories and augmentation settings, and handling the versioning and deployment of model checkpoints to evaluation hardware.
The most relevant background here is experience building training infrastructure for 3D learning models, particularly experience with the data volume and format diversity that comes from heterogeneous sources (simulation meshes, real point clouds, augmented data). Experience with distributed training and with the debugging patterns specific to 3D model training (which fails differently than 2D image model training) is valuable.
We run training on a small cluster, not on hundreds of GPUs. The engineering challenge is getting maximum utilization and iteration speed out of limited compute, which requires careful pipeline design and profiling. Someone who has only trained on very large-scale infrastructure where efficiency was someone else's problem will find this a different kind of challenge.
Working at RLWRLD
The office is in Hongo. We work in the office most of the time, partly because coordination on hardware experiments is easier in person and partly because the team is small enough that in-person interaction is how we share context quickly. We have no strong opinion about exactly which hours you are there, but presence matters for a team this size.
We work in Japanese and English. The founding team is Korean and Japanese, and we interact with manufacturing partners primarily in Japanese. You do not need to be fluent in Japanese to join, but you should be comfortable working in a multilingual environment and willing to develop some working Japanese over time.
We are not a company that has large-scale deployment yet. If you are looking for a role where you ship features used by many people immediately, this is probably not the right stage. We are a company where the work shapes what gets deployed, where being right about a technical decision has direct consequences for what the product becomes. If that tradeoff suits where you are in your career, we want to hear from you.
To apply or ask questions, send a note to [email protected] with a description of work you have done that is relevant to the role you are interested in. A link to code, papers, or any work product that shows what you build is more useful to us than a formatted resume.