The robotics ML workflow is still Frankensteined together. You record demonstrations with one tool, train with another, test in sim with a third, write custom glue code to deploy on hardware, and bolt on yet another system when you need to coordinate multiple robots. AWS just open-sourced Strands Robots, an Apache 2.0 SDK that stitches the entire LeRobot stack into a single agent loop. Same dataset format from sim to real hardware. Same policy interface whether you're running GR00T, a local checkpoint, or MolmoAct2. One agent that composes recording, inference, and deployment as swappable tools.
This is the kind of infrastructure work that doesn't make headlines but quietly fixes a thousand paper cuts. Let's walk through what it actually does.
The Five-Tool Problem
Here's the current state: you have a robot, a folder of demonstrations on the Hugging Face Hub, and a new task to learn. The pieces exist but don't talk to each other. LeRobot handles hardware recording and calibration through its CLIs (lerobot-record, lerobot-calibrate). You write custom code to deploy trained policies. Simulation uses a different data format than hardware. Coordinating multiple robots requires standing up separate infrastructure.
Strands Robots doesn't replace LeRobot—it wraps it. The integration is deliberately thin. LeRobot's own scripts handle the hardware bring-up. Strands exposes robot abstractions, simulation, and the LeRobot stack as AgentTools that you compose into a single agent. The dataset format stays exactly as LeRobot writes it. The agent loop is the glue.
The workflow in five lines of Python:
from strands_robots import Robot
from strands import Agent
arm = Robot("so100") # mode="sim" by default
agent = Agent(tools=[arm])
agent("Pick up the red cube")
That's it. Default mode is simulation—no hardware, no risk. Swap mode="real" and the same agent code runs on physical hardware.
Same Dataset Format, Sim to Real
The core design choice: Robot("so100") returns a MuJoCo-backed simulation by default, and mode="real" returns a hardware robot driven by LeRobot. Both modes share the same DatasetRecorder and the same policy providers.
This means a dataset captured in MuJoCo and one captured from a physical SO-101 arm use the same on-disk LeRobotDataset format. Same parquet schema for joint states and actions, same per-camera MP4 layout. The simulation tool records through the same class that LeRobot uses on hardware.
You can record a demonstration in sim, push it to the Hub, then add hardware demonstrations in the same dataset without conversion:
agent(
"Record a demonstration of 'pick the red cube' "
"using the Mock policy provider at 30 FPS. "
"Write to my_user/cube_picking_sim and push to Hub."
)
The Mock policy generates placeholder joint actions so the workflow runs end-to-end without a trained checkpoint. The robot moves through random motions, but the recording is structurally complete—valid joint states, valid camera frames, a well-formed LeRobotDataset. Swap Mock for LerobotLocal or GR00T and you get real policy inference.
Policy Providers Behind a Common Interface
Strands exposes three policy providers: Mock, LerobotLocal, and GR00T. All three implement the same interface. The agent swaps them with a string.
LerobotLocal serves local checkpoints through LeRobot's own inference path. MolmoAct2 checkpoints run through this provider. GR00T wraps NVIDIA's Isaac GR00T in a Docker container, downloads a checkpoint, and starts inference. The gr00t_inference tool's lifecycle="full" action pulls the image, downloads the model, and spins up the container in one call.
Switching from a local ACT checkpoint to GR00T is a keyword argument change:
# Local checkpoint
agent("Run pick_cube_v1 policy from my_user/cube_policies")
# GR00T
agent("Run GR00T inference for pick_cube task")
Both policies consume the same LeRobotDataset format. Both drive the same robot interface. The agent decides which provider to route to based on the prompt.
Hardware Deployment: One Keyword Argument
The simulation-first default makes the workflow safe. No hardware required to test the full loop. But when you're ready to deploy, the agent code is identical. Change mode="sim" to mode="real":
robot = Robot("so100", mode="real")
agent = Agent(tools=[robot])
agent("Execute pick_cube policy on hardware")
The hardware path assumes you've already run LeRobot's calibration and have configs under ~/.cache/huggingface/lerobot/calibration/. Strands doesn't reinvent that—it uses LeRobot's hardware drivers directly. The agent orchestrates what happens after calibration: recording, policy execution, multi-robot coordination.
For hardware recording, you still use lerobot-record to capture demonstrations. Strands picks up from there, handling dataset management and Hub pushes through the same DatasetRecorder that writes simulation data.
Multi-Robot Coordination Over Zenoh Mesh
When you have more than one robot, the agent can broadcast commands across a fleet. Strands includes a built-in peer mesh over Zenoh that fans the agent out to remote robots.
The mesh tools (Mesh.broadcast, Mesh.subscribe) let one agent coordinate multiple physical devices. You write the orchestration logic once—"robot A picks, robot B places"—and the mesh handles message routing.
This isn't multi-agent RL or swarm coordination. It's infrastructure: a lightweight pub/sub layer so one Strands agent can talk to many robots without writing custom networking code.
Prerequisites and Gotchas
Minimal path (simulation only):
- Python 3.12+, Linux or macOS (Apple Silicon supported for MuJoCo)
- A Strands-compatible model provider: Bedrock, Anthropic API, OpenAI, or Ollama
- Install with extras:
uv pip install "strands-robots[sim-mujoco,lerobot,mesh]"
That's it for the default workflow. The example runs end-to-end on a laptop with no GPU, no hardware, no Hugging Face credentials.
Advanced path (hardware, real policies, Hub push):
- Hugging Face token with write permission
- SO-101 follower and leader pair (or any LeRobot-supported robot) with calibration files
- For GR00T: NVIDIA GPU with 16+ GB VRAM and Docker
The runnable example lives at examples/lerobot/hub_to_hardware.py and hub_to_hardware.ipynb in the strands-labs/robots repository. The notebook is the recommended starting point—open it in JupyterLab and run cells top-to-bottom in sim mode.
What This Actually Solves
Strands Robots doesn't introduce new robot learning algorithms. It doesn't claim to make policies generalize better or speed up training. What it does is eliminate the integration tax between demonstration recording, policy training, simulation testing, and hardware deployment.
Before: five tools, custom glue code, format conversions, separate coordination infrastructure.
After: one agent, one dataset format, policy providers you swap with a string, built-in mesh for multi-robot.
The LeRobot integration is intentionally thin because LeRobot already handles the hard parts (hardware drivers, calibration, dataset schemas). Strands wraps those pieces into an agent loop so you can compose them without writing custom orchestration every time.
This is infrastructure. It's not sexy. But it's the kind of plumbing that lets you spend less time wrangling tools and more time iterating on the actual robot learning.
Where This Fits in the Stack
LeRobot has become the de facto open-source stack for robot learning—good dataset tooling, clean hardware abstractions, growing model zoo. But it's still a collection of scripts and libraries. You compose them yourself.
Strands takes that stack and wraps it in an agent interface. The agent reasons about which tool to call when. Record a demo, push to Hub, run a policy, deploy to hardware—all dispatched by the same agent that interprets your high-level prompt.
The design choice to default to simulation is smart. Most robotics code breaks in ways you only discover on hardware. Starting in sim means you can iterate fast, verify the dataset format, test policy swapping, and debug the agent loop before risking a physical robot.
And because the dataset format is identical between sim and real, you can mix synthetic and real demonstrations in the same Hub dataset without conversion. That's the kind of workflow detail that saves hours.
Try It
The companion code is open-source (Apache 2.0) at strands-labs/robots on GitHub. Clone the repo, install with uv pip install "strands-robots[sim-mujoco,lerobot,mesh]", and open examples/lerobot/hub_to_hardware.ipynb. The notebook runs end-to-end in simulation with the Mock policy—no hardware, no GPU, no credentials required.
If you have an SO-101 or other LeRobot-supported robot, swap mode="real" and the same agent code deploys to hardware. If you have an NVIDIA GPU, point it at a GR00T checkpoint and watch the policy provider swap in Docker.
This is early infrastructure. The integration is thin by design. But it's solving a real problem: the robotics ML workflow is still too Frankensteined together, and Strands is one attempt to stitch the pieces into a coherent loop.