Strands Robots and LeRobot: Hub-to-hardware agent demo

Strands Robots and LeRobot now run end-to-end from the Hugging Face Hub to physical robot hardware in a single agent loop, demonstrated in a June 17, 2026 walkthrough. The example shows a five-step flow that records a LeRobotDataset in MuJoCo, pushes it to the Hub, runs a policy in simulation, and deploys the identical agent code to an SO-101 by changing one keyword argument.

What does the Strands-LeRobot example do?

The example composes LeRobot functionality into a single Strands agent that records demonstrations, pushes LeRobotDatasets to the Hugging Face Hub, runs policies against the same on-disk format, and deploys unchanged agent code to actual SO-101 hardware. The agent uses Robot("so100") in its default MuJoCo-backed simulation mode, switches to mode="real" for LeRobot-driven hardware, and can fan out commands across a fleet via a built-in peer mesh.

The post presents runnable examples at examples/lerobot/hub_to_hardware.py and hub_to_hardware.ipynb in the strands-labs/robots repository. The notebook runs in simulation and uses the Mock policy by default so the workflow requires no GPU, no hardware, and no Hugging Face credentials for the default path.

How does the sim-to-hardware dataset format work?

Strands shares the same DatasetRecorder class LeRobot uses, so simulated recordings and hardware recordings are identical on disk: a parquet schema for joint states and actions plus per-camera MP4 layouts. The Simulation tool's start_recording action writes LeRobotDatasets with the same column names and loader shape that LeRobot's dataset loader expects.

The post demonstrates loading a simulation push with LeRobot's loader: from lerobot.datasets.lerobot_dataset import LeRobotDataset; dataset = LeRobotDataset("my_user/cube_picking_sim") and shows the same features dict that hardware datasets provide. That parity means training scripts and LeRobot training CLIs can consume sim-recorded episodes without modification, and datasets pushed from simulation appear alongside hardware recordings on the Hub.

How do you run a policy and deploy the same agent to hardware?

Run-time policy providers plug into the agent through the same interface so you swap behavior via a string. The example shows gr00t_inference as an AgentTool to pull a GR00T container, download a checkpoint from the Hub, and start an inference service (the example uses port 5555). Alternatively, use a LerobotLocalPolicy loaded from a Hub repo for in-process inference.

The post details both paths: gr00t_inference(action="lifecycle", lifecycle="full",...) to start the container and a run_policy action on the simulated robot with policy_provider="groot"; or create_policy("lerobot/act_aloha_sim_transfer_cube_human") to load LerobotLocalPolicy. The same Agent code runs Robot("so100") in simulation and the identical code runs the physical SO-101 when Robot(..., mode="real") is used. For hardware recording, LeRobot's own CLI commands (lerobot-calibrate, lerobot-record) remain the recommended bring-up path; Strands does not rewrap the recording CLI.

Why it matters

This integration collapses what the post describes as five separate tools into a single agent loop for common tasks: recording, training data format parity, policy inference, and deployment. That parity—identical parquet+MP4 dataset layout and identical agent code across sim and real—reduces friction when moving datasets and policies between simulation, the Hub, and physical robots. Developers can run the full example on a laptop in simulation without a GPU or Hub credentials, then switch to hardware with one argument change.

What to watch

Watch for model provider choice and deployment constraints: running GR00T locally in the example requires an NVIDIA GPU with at least 16 GB of video memory and Docker, while LerobotLocalPolicy uses in-process model loading (the post flags STRANDS_TRUST_REMOTE_CODE=1 for trust_remote_code). The next concrete signals will be published checkpoints and example Hub repos cited in the strands-labs/robots examples folder.