A new workflow lets you record demonstrations, train policies, and deploy agents from a single interface, but the loop becomes expensive if you run it daily. Uploading recordings keeps expanding, training runs copy the entire dataset to GPUs before starting, and new checkpoints ship out while the next batch of recordings returns.
The earlier post in this series introduced Strands Robots, an open source SDK from AWS (Apache 2.0) that exposes robot abstractions, simulation, and the LeRobot stack as AgentTools you compose into a single Strands agent. It covered the Robot() factory, recording a demonstration in simulation, running a policy, and deploying the same agent code to a physical SO-101. That factory resolves a name against a registry of arms, humanoids, mobile bases, and hands, so the SO-100 used throughout this post is one of many supported embodiments. The robot catalog lists every robot the factory knows about. LeRobot’s dataset format is already used by over 90,000 datasets and models on the Hub from more than 8,000 publishers (LeRobot Project Pulse). A Strands Robots recording is one more of them, so anything built to read LeRobot data can read it without conversion. If you are new to Strands Robots, start there; this post assumes that setup.
The first post followed the agent loop in one direction, from a Hub dataset to a physical robot. This one follows the data the other way, from the first recorded frame back to the deployed policy, over Hugging Face Storage Buckets – a mutable, non-versioned, Xet-backed object-storage repository type announced in March 2026. A bucket sits beside your dataset repositories in the same hf:// namespace and uses the hf CLI you already have, so it becomes the working layer that holds your data between the day you record it and the day you train on it.
Someone has to decide which episodes to keep, when the scene has drifted far enough to re-record, whether today’s batch is enough to train on, and which checkpoint replaces the one on the arm. Each of those decisions comes up dozens of times over a collection campaign, and each one needs a look at what came back before the next command goes out. That is the work an agent is for. This post walks you through the data loop inside a single agent: record a demonstration into a Storage Bucket, store it so that each sync uploads only the bytes that changed, train by streaming the dataset straight from the Hub instead of downloading it, and deploy the checkpoint back to hardware with one keyword argument change. The runnable companion to this post lives at examples/notebooks/05_streaming_data_loop.ipynb.
What you’ll build
Where the first post recorded a dataset and pushed it to the Hub, the agent you build here records a LeRobotDataset from a natural-language prompt, syncs it into a Storage Bucket, and streams that same dataset back frame by frame, decoding camera video on the fly, with no local copy. You read it back in the same process that wrote it: the same Strands Robots Robot() that recorded the dataset streams it. Your trained checkpoint then deploys to that same Robot() with one keyword argument change, and the demonstrations it records on hardware return to the same bucket.
Figure 1. The four stages share one backend. Robot("so100") records a LeRobotDataset through the shared DatasetRecorder; sync_dataset_to_bucket(...) syncs it into a Storage Bucket; stream_dataset(...) reads it back over the Hub with no full download; and the trained checkpoint deploys to the same Robot with mode="real". The on-disk format stays exactly as LeRobot wrote it.
Because one Robot() both records a dataset and reads it back, collecting data and training on it are two methods on one object over one backend. The agent decides to run an episode and invokes one tool; the rollout then proceeds at the robot’s control frequency until the episode ends, with the trained policy producing every action. The whole loop, in a handful of lines:
from strands import Agent from strands_robots import Robot sim = Robot("so100") # mode="sim" (default - safe, no hardware) agent = Agent(tools=[sim]) # Record a demonstration and sync it to a bucket. agent("Record a pick-the-cube demo and sync it to my-org/robot-fave.") # Stream it back from the bucket to train, without downloading it first. for batch in sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket").dataloader(batch_size=64): ...What follows is what’s actually happening inside that loop, step by step.
Prerequisites
Minimal (default simulation path)
- Python 3.12+, on Linux or macOS (Apple Silicon supported for the MuJoCo backend).
- A Strands-compatible model provider for the agent’s reasoning. Amazon Bedrock with AWS credentials, the Anthropic API, OpenAI, or Ollama running locally.
- Strands Robots with the dataset extras:
uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1". Thelerobotextra pulls in LeRobot (>=0.6.1),datasets,av, andtorchcodec, so recording and video decode both work without further setup. Refer to installation guide.
That’s it. Every stage in this post runs on a laptop with these three. What runs is the loop, not a working policy: the default path uses a mock policy, which records a valid dataset but not a useful one.
Advanced (buckets, hardware, real policies)
- A Hugging Face account and a token with write permission, plus the
hfCLI for creating buckets and syncing datasets:pip install -U "huggingface-hub>=1.6.0,<2.0.0", thenhf auth login. - For the hardware path: an SO-101 follower and leader pair, or any other LeRobot-supported robot, with calibration files under
~/.cache/huggingface/lerobot/calibration/. - For local vision-language-action (VLA) inference: an NVIDIA GPU. For training at scale, a GPU cluster reading from the Hub.
- To run the training step:
uv pip install "lerobot[training]". Recording and streaming do not need it. If you skip it,trainer.train()returns an error result rather than a checkpoint. The troubleshooting guide names that error and the install that fixes it.
Step 1 – Record a demonstration into a bucket
You record new episodes through the day, each a continuous run of camera frames and joint state-action telemetry. LeRobot writes that as a small set of large files that grow as you record. Push them into a versioned dataset repository and every append becomes a commit, and every revision is retained. Collection wants the reverse: somewhere to write bytes and overwrite them in place. That is a Storage Bucket, which lives inside your Hugging Face workspace and uses the permissions you already have. There are no identity and access management (IAM) roles to configure, no cross-origin resource sharing (CORS) rules, and no upload service to maintain.
Your agent records a LeRobotDataset in the same format LeRobot writes on hardware. Record the episode, then sync the finished dataset into a bucket. The prompt asks for the mock policy, a stand-in that produces joint actions without a trained model, so you can run the whole loop before you have a checkpoint to run:
from strands import Agent from strands_robots import Robot, sync_dataset_to_bucket sim = Robot("so100") # mode="sim" by default agent = Agent(tools=[sim]) # One prompt drives scene setup, cameras, policy, and recording. agent( "Create a world with the so100 robot, add a red cube and a front camera, " "start recording (repo_id='local/cube_pick', root='/tmp/cube_pick', fps=30, " "overwrite=True, task='pick up the red cube'), run the mock policy for " "60 steps, then stop recording." ) # Sync the finished on-disk dataset into the bucket (no live recording session needed). sync_dataset_to_bucket("/tmp/cube_pick", "my-org/robot-fave") # -> {"status": "success", "bucket_uri": "hf://buckets/my-org/robot-fave/cube_pick"}The sync writes to
hf://buckets/{bucket}/{run_id}, whererun_iddefaults to the dataset directory name. The streaming read in Step 3 names the run too: the first two segments of the id are the bucket, and everything after them is the path inside it.
sync_dataset_to_bucket(root, bucket, run_id=...)validates the dataset and syncs it through thehfCLI, decoupled from the recording lifecycle. The same capability is onDatasetRecorder.sync_to_bucket(bucket, run_id=...)if you drive an open recorder directly, andstop_recording(bucket=...)syncs at the moment you stop an active recording. The bucket is the working layer you write to through the day; for the versioned, published artifact you still callpush_to_hub(). Both hold the same format.The episode is structurally complete, but the actions are placeholders, so it is not training data you would want. Swap in a real policy with
create_policy("<hf_repo>")for actual grasping; the prompt, the format, and the bucket sync stay identical.Recording on hardware
To record on a physical SO-101, LeRobot’s record CLI handles the leader-follower bring-up:
lerobot-record \ --robot.type=so101_follower --robot.id=my_follower \ --teleop.type=so101_leader --teleop.id=my_leader \ --dataset.repo_id=my_user/cube_picking \ --dataset.single_task='Pick up the red cube'The dataset lands on disk in the same format as the simulation recording, so the same sync call takes it to a bucket:
sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021Source Read original →
