Strands Robots: How a robot becomes an agent tool [plus a cheat sheet!]

By Brooke Jamieson (Senior Developer Advocate, AWS) | Last updated: 4 September 2026

Short answer: Strands Robots lets a Strands agent use a robot as a tool, in simulation or on supported real hardware. You can start on your laptop in MuJoCo with no robot and no GPU, and opt in to real hardware and multi-robot coordination later, when your task and your safeguards are ready for them.

I knew coding agents would change the way I worked, but one thing I didn't expect was how they'd change my relationship with hardware! Like I always knew I could build a cute little smart lamp, or do something hacky with a Rasberry Pi and receipt printer or eink display, but I never actually did this because I just knew it would be an annoying way to spend 3 weekends.

But, agentic coding agents have changed that and it's now super attainable to build with hardware in a way I would never have had the patience for before. Tinkering (and then bringing scale to what you're tinkering with) has never been so easy.

Strands Robots feels like the next step in that story, and it's the robotics library from Strands Agents (the beloved open source SDK for building production agents). I didn't really ever expect robotics to land anywhere near my job, but here we are, so LFG.

If you've seen my Agents Are Just Loops video, you know how I think about agents. Get an input, figure out whether a tool is needed, run it, look at the result, then decide what's next. So a calculator tool returns 67, and a weather tool returns a forecast. Strands Robots makes a robot another kind of tool in that exact same loop. The agent looks at what the robot reports, asks it to act, looks at what changed, and goes again.

Working on my first agentic robotics project reminds me of finishing my first todo app. It was, objectively, just a todo app, but when I got it working I felt like I could run through a brick wall. Here we go!

What is Strands Robots?

Strands Robots gives a Strands agent a robot as a tool. The tool says what the agent can look at, and what it's allowed to ask the robot to do.

The code is small:

from strands import Agent
from strands_robots import Robot

robot = Robot("so100")
agent = Agent(tools=[robot])
agent("Wave the arm using the mock policy for 200 steps, then render a top-down view")

And you don't need an irl robot for this. Robot("so100") just spins up a MuJoCo simulation on your laptop. In the library, simulation is actually the default opton, then if you want to use real hardware you can just opt in with mode="real". There's also a mode="auto" that checks whether there are servos plugged in over USB and then just falls back to simulation if there aren't.

The same loopy agent + tool model extends to teleoperation, policy-driven tasks, and coordinated multi-robot workflows. But simulation is where you work out what the agent actually needs to see and do before any of that. Once you switch to mode="real", the loop feels familiar, then the work can change to cover calibration, workspace conditions, and physical safeguards as part of your project.

How do I try Strands Robots without owning a robot?

Install the simulation extra and give the agent a little task in MuJoCo. To get started, you'll need Python 3.12 or newer and a configured Strands model provider. (The model still runs the agent loop; the mock policy you'll see below only drives the simulated arm.)

uv pip install "strands-robots[sim-mujoco]"

Then give it a small job:

from strands import Agent
from strands_robots import Robot

robot = Robot("so100")
agent = Agent(tools=[robot])
agent("Add a red cube and a front camera, run the mock policy for 60 steps, then render a top-down view")

Fair warning: the mock policy is for sure a mock policy - it's not super clever. It moves the arm through some scripted test motions, so it won't be able to gracefully pick up the cube, but that's A-OK! The point of this first session is to watch the loop run end to end, with the agent building the scene, calling actions, and reading the results back.

Also, Robot("so100") already creates the world and pops the robot in, so you don't need to call create_world() on it again. If you're getting a "World already exists" error at this point, this is probably why. The quick start has the current setup instructions and examples.

I'd start by rendering a view and looking at the robot state, then asking for one bounded task and checking the result. it's a nice way to start, and you'll learn a lot.

Here's a cheat sheet I made to help you out:

Strands Robots 101 Cheat Sheet: What can I try on my laptop?, What happens in the first experiment?, How does a robot become an agent tool? When do you need a mesh? Which transport fits your network? Does it work with the robot I have? When do you switch to real hardware?

What can a Strands agent actually do with a robot tool?

Only what the selected robot has been set up to show and do. A robot might expose a camera view, joint positions, and a set of actions, and then the agent uses those to figure out the next step it will take. In the Strands launch example, the agent reads camera and joint-state information while it works through a natural language task.

The catalogue is fun to scroll, so I recommend you take a look! There's 70+ simulated robots across eight categories, from the so100 arm you'll see in every example to Unitree's G1 humanoid, Spot, dexterous hands, even a Crazyflie drone. Real-hardware support is a shorter list (eleven robots so far), so check the supported-robot list before you plan a project around a particular machine.

Whatever you're working on, it needs observations the agent can actually use, a policy that can produce the right actions, and some way to check the result.

How does Strands Robots coordinate multiple robots?

When you just have one robot, there's no one to coordinate with, because the agent just holds the robot as a tool and everything is fine. But, when you add a second robot, this tool model stops being enough on its own because the robots need a way to find each other on the network, see what each other is doing, and pass work across.

Strands has an opt-in mesh which is a shared network for the robots and the coordinating agent to help with this. Discovery happens automatically, so an agent that joins late can still see who's already there and what they're doing. The robot_mesh tool is how the agent works with the group. This means it can inspect peers, send an instruction to one of them, subscribe to approved telemetry, or call a fleet-wide emergency stop. The launch post has a demo for this and shows one agent asking a robot to bring a bin of parts over to a cell, then having a robot arm load them into a fixture.

When should I use Zenoh or AWS IoT Core for a Strands Robots mesh?

Choose based on where the robots are. If they're on the same local network, use Zenoh (the default). If they're across networks, or you want cloud-connected fleet operations, then use AWS IoT Core. There's also a bridge transport for a local Zenoh fleet that needs selected data mirrored up to IoT Core. The important part is that your agent code stays the same whatever you pick.

How does the Model Hardware Standard fit into Strands Robots?

As another mesh backend. The Model Hardware Standard (MHS) is a new standard for AI agents operating physical equipment like microscopes, lasers or robots, co-developed by Anthropic and HHMI Janelia Research Campus. Strands Robots is participating in this research preview, and in the pre-release build, switching the mesh over to MHS looks like switching from Zenoh to IoT Core. Anthropic's research preview announcement goes over everything in more detail.

How safe is it to let an agent control a real robot?

I've been working with the Strands team on safety behind the scenes at some in-person events, and if you ask anyone on the eng team whether I'm annoying about it, they'll probably agree with you. I'm fine with that! Robots are cool, and I don't want anyone's first project to go wrong in a way that puts them off for good. Sort of like when people get bill shock the first time they make an AWS account because they didn't have billing alarms set up - I really do my best to help people avoid this!

Simulation lowers the risk of safety issues when you're experimenting, but it's not a way to fully prove that a calibrated physical robot will behave safely in your particular workspace.

The security docs describe the layers around mesh actions: there's explicit real-hardware mode, there's configurable out-of-band operator approval, command validation, audit records, and an emergency-stop lockout that stays latched until an operator resumes it. But none of that replaces the physical layer. Make sure you keep a hardware cutoff within reach and always validate new tasks in simulation first. Decide before the run what the operator does when the physical state is uncertain, because the mesh can report which peers acknowledged an emergency stop, and an acknowledgement is not the same thing as every machine actually being still.

Where should I start with Strands Robots?

The best place to start is with the Quickstart guide and pip install strands-robots. From there, just put a robot in a MuJoCo scene, then give the agent a tiny task.

Keep the mesh off until you know what success and failure look like for that task. After that, the docs and the GitHub repo are your next stops, and the Strands Discord will be super helpful for you too.

At the start of this post I told you about all the hardware ideas I never built because they'd be an annoying way to spend 3 weekends. Robots were the most extreme version of that for me - I love living in the future. See you in the sim!

---

About the Author:
Brooke Jamieson is a Senior Developer Advocate at AWS, focused on AI agents and developer tools. A former fashion model turned mathematician turned AI Engineer, Brooke moved from Australia to New York City for this role. They make byte-sized tech content about AI and AWS, and you can find them on LinkedIn, Instagram or X.