Meta released Muse Gadgets as open source. ESP32 firmware, a Linux SDK, a GitHub repo, and developer docs. Per TechCrunch (Oct 2), the goal is Muse agents on cheap ESP32 boards or Raspberry Pi-class Linux boxes with screens, buttons, sensors, and audio attached.

One line sums it up. Agent tool surfaces are stretching from browsers, terminals, and SaaS APIs into physical devices and sensors.

What shipped: a 3-piece set

Item Detail
ESP32 Device SDK Screens, audio in and out, and sensors on off-the-shelf ESP32 boards
Linux Device SDK A spare Raspberry Pi or Linux box becomes a gadget, with custom commands for sysadmin chores or Home Assistant
Muse Home Link A USB-C gadget on home Wi-Fi (ESP32-C5) reaching owned devices and DIY HTTP APIs

The start path is public. Grab an SDK token (gadgets.muse.ai), open Developer mode under Devices in the Muse iOS or Android app, and look for "MuseGadget" units. Each directory ships a README plus an AGENTS.md for coding agents. License is Apache 2.0.

Meta's own example is Home Link. It joins the home network and drives anything with an HTTPS interface, like TVs and speakers. Meta built 5,000 units for free Muse-subscriber giveaways (US only, October shipping, first come first served). Community skills add lights-on, TV control, and print-to-printer flows.

Why it matters: wider borders mean stricter permissions

The Robostral post covered Physical AI. Gadgets are its popularized edition. Not LLMs driving robots, but spare boards becoming agent hands and feet.

Widening tool surface:
browser → terminal → SaaS APIs → sensors, displays, speakers, actuators

Growing alongside:
permissions and safety borders (physical actions resist undo)

The "AI that moves for you" from the Muse personal-agent post meets the "web devs build device apps" from the Ray-Ban WebMCP post. Past web and apps into physical devices, the maker circle widens.

One closed loop is the portfolio

Take the brief's action as is. Not an API call list but one loop makes the portfolio.

Bones of 1 portfolio loop:
sensor/input → judgment → physical or software action → verification
  (temp, button, voice)  (Muse)   (light, alert, TV)      (read state, log it)

3 samples, easiest first:
1. button → tell Muse → read aloud on speaker → log it
2. temp sensor → alert past threshold → fan on → check state
3. voice command → Home Assistant routine → TV and lights → speak results

Like WebMCP in the MCP comparison, exposing a DIY HTTP API lets Muse call it. Home Link is the official sample of that pattern.

CodeBridge Mini Lab: 1 weekend gadget

1. Pick 1 spare board (Raspberry Pi preferred, ESP32 otherwise)
2. Take an SDK token and link it with the Linux SDK
3. Close 1 loop:
   [ ] 1 input (a button, sensor, or voice)
   [ ] 1 judgment (the Muse agent)
   [ ] 1 action (an alert, light, or TV)
   [ ] 1 verification (read state back, log success)
4. Write 3 safety rules:
   - confirm before physical actions (heat and power especially)
   - home network only, nothing exposed outside
   - apply approval rules from [layer 2 security](/en/blog/ai-agent-security-sandbox-guide/)

Like the first public-data app, do not stop at "built it." Film the sensor, judgment, action, and verification loop running and it becomes a portfolio.

Conclusion: touch an agent with hands first

One line to close.

From agents that call APIs to agents that touch the world.

One ESP32 and one spare Raspberry Pi start it. Do not start expensive. Close a loop with 1 button and 1 alert. Once that loop runs, permission, verification, MCP, and WebMCP click all at once. Physical AI starts on desks, not in factories.

Further reading

References

Go deeper with a course

To practice making things and linking them with AI, the course that builds and ships websites through conversation continues exactly into the gadget loop here. Learn the making feel first.