docs: blog post on Strands Robots networking and the Model Hardware Standard

[arronbailiss]

Description

Adds a new blog post, site/src/content/blog/robots-working-together-model-hardware-standard-strands-robots.mdx, on connecting Strands agents to many robots and devices at once through Strands Robots.

It walks from a single Robot() in simulation to a coordinated fleet: the mesh (auto-discovery, the robot_mesh orchestration tool), the Zenoh and AWS IoT Core transports and switching between them via STRANDS_MESH_BACKEND, and Strands Robots participating in the Model Hardware Standard (MHS) research preview as another mesh backend.

Authored by Cagatay Cali and Arron Bailiss.

Related Issues

None.

Documentation PR

Docs-only change under site/src/content/blog/.

Type of Change

Documentation update

Testing

• Validated the content collection and MDX with npx astro sync (exit 0, "Synced content").
• Verified every code snippet against the strands-robots source: Robot() kwargs (mode, mesh), the top-level robot_mesh tool, the so101/lekiwi registry names, and transport selection via the STRANDS_MESH_BACKEND env var (zenoh/iot).
• I ran hatch run prepare — N/A, content-only change (no Python/TypeScript touched).

Checklist

• I have read the CONTRIBUTING document
• I have reviewed and understand every line of code in this PR, including any generated by AI tools, and I can explain why it works
• My change is focused and reasonably small; I have split unrelated work into separate PRs
• I have added any necessary tests that prove my fix is effective or my feature works — N/A for a blog post
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

[github-actions]

Documentation Preview Ready

Your documentation preview has been successfully deployed!

Preview URL: https://d3ehv1nix5p99z.cloudfront.net/pr-cms-4024/docs/user-guide/quickstart/overview/

Updated at: 2026-08-28T14:18:58.194Z

[github-actions]

Assessment: Comment (non-blocking)

Well-written, on-brand post with a clear one-robot → fleet → MHS arc; frontmatter is valid (both authors exist in authors.yaml, tags match existing usage, date is today, draft: false), scope is appropriately small, and all internal and external links resolve. My only substantive concern is snippet accuracy against the shipped strands-robots API — the post itself promises "the code you prototype is the code you take to production," so the examples should run as copied.

Review details

• Code accuracy (2 inline, Important): The robot_mesh import path and the STRANDS_MESH_BACKEND env var don't match the published Strands Robots docs (which import robot_mesh from strands_robots.tools and select the AWS IoT transport via the [mesh-iot] extra rather than an env var). Please verify both against the shipped/pre-release build.
• Verified accurate: Robot("so101"), mode="real", mesh=True (mesh off by default), the lekiwi registry name, Zenoh as the default transport, the SO-101 → SO-ARM100 link, and all links returning 200.
• Minor (non-blocking): "AWS is a participant in the research preview" is stated in both the intro and the MHS section — you could drop one for tightness.

Nice work threading MHS into the existing transport-abstraction story — it reads naturally as "just another backend."

[github-actions]

Updated assessment: Approve ✅

Following up on my earlier review: I re-verified the two snippet concerns against the actual strands-labs/robots source (rather than the published docs, which lag), and both snippets are correct — thanks @arronbailiss for the pointers.

Verification against source

• robot_mesh top-level import — confirmed. It's registered in _LAZY_IMPORTS and __all__ with the PEP 562 __getattr__ lazy loader in strands_robots/__init__.py, so from strands_robots import Robot, robot_mesh resolves.
• STRANDS_MESH_BACKEND — confirmed. Owned by strands_robots/mesh/_backend_select.py (BACKENDS = ("zenoh", "iot", "bridge"), default zenoh), with coverage in tests/mesh/test_session_backend_select.py. The "iot" snippet is accurate; the "mhs" snippet is correctly scoped to the pre-release build.
• Registry names — ur10e and tiago_dual are both valid keys in registry/robots.json.

Both threads were false positives on my end (I trusted the published API reference / docs, which don't yet document these). The underlying gap is in the robots repo's docs, not this post.

The post is accurate, well-structured, and on-brand. Only remaining item is the optional nit already noted (the "AWS is a participant" line appears in both the intro and MHS section). Nice work.

[github-actions]

Re-reviewed the latest commit — all good, Approve stands. ✅

• IoT snippet now carries the # (needs pip install "strands-robots[mesh-iot]") note, which closes the one actionable item from thread ci: update mypy requirement from <1.0.0,>=0.981 to >=0.981,<2.0.0 #2. 👍
• Changed links verified (all 200): universal-robots.com/products/ur-series/, github.com/strands-agents/harness-sdk, and github.com/strands-agents/evals (confirmed a real public repo).

No outstanding issues. The only remaining item is the optional, non-blocking nit (the "AWS is a participant in the research preview" line appears in both the intro and the MHS section) — take it or leave it. Nice work.

[github-actions]

Re-reviewed after the latest commit — the edits cleanly address this round of feedback from @pgrayy and @opieter-aws, and Approve stands. ✅

• The three opening use cases now read as parallel, concrete real-world scenarios; the "everything above it stays the same" phrasing is clarified; the stray "AWS is one of the participants" line is gone (which also closes the earlier repetition nit); and the application URL is now linked inline.
• Code snippets are unchanged, so the previously verified robot_mesh import and STRANDS_MESH_BACKEND usage still hold; no new links introduced beyond modelhardwarestandard.com, which resolves.
• The constructor-arg suggestion is reasonably deferred until the robots package supports it — nothing blocking here.

No outstanding issues from my side. Nice iteration.