Meta ’s Muse gadget project gives its personal AI agent an interface to physical devices. The October 2 account in The Verge introduces the release, while Meta’s public SDK repository supplies the implementation and setup details. Together, they reveal a practical design question: how much authority should a connected device give an agent?

A small screen that displays a briefing and a Linux computer that accepts shell commands can both be called AI gadgets. Their capabilities differ substantially. Choosing between them means deciding what information the device receives, what actions it exposes, and which existing permissions travel with those actions.

Three routes into the same agent

The project offers ESP32 firmware and a Linux device SDK. Raspberry Pi computers provide a familiar example of the Linux route. The ESP32 route supports boards ranging from a status light and button to devices with screens, microphones, and other controls.

Meta also presents Muse Home Link , a USB-C device based on an ESP32-C5. Its stated role is to connect Muse with compatible services on a home network, including local HTTP interfaces. The official page describes a US offer for active Muse subscribers, limited to one device per subscriber, with shipping beginning in October. That offer has a narrower scope than the downloadable SDK.

Home Link uses official firmware that the product page says cannot be reflashed. The public ESP32 SDK, by contrast, is intended for people who build and modify their own devices. Buying or claiming a finished device and developing firmware are therefore different paths, even when both eventually connect to Muse.

This is a useful way to read the announcement. The device is an endpoint for the agent. Its display, button, software, and network access determine which parts of the agent’s work become visible or actionable in a room.

A display does not establish local inference

The repository licenses the device SDK under Apache 2.0 , with stated exceptions for included components and avatar assets. That describes the published software. It does not establish that the Muse model runs on the board or that the hosted service is available under the same license.

Every gadget needs an SDK token. The setup instructions also require the Muse phone app and developer mode. Hardware, device software, pairing, and access to the agent are distinct parts of the system. A board with enough memory to drive a screen has not thereby acquired enough computing capacity to run the underlying model.

For someone planning a project, this distinction determines what remains useful when the network or service is unavailable. A locally programmed screen may continue to show its last image, but the project’s ability to obtain a new agent response depends on its connection. A practical design should make that state legible. An old briefing and a fresh answer can look identical unless the application provides a timestamp or connection indication.

The official device examples include the Seeed reTerminal E1001 e-paper display I may earn a commission. Its appeal is the placement of information where someone will encounter it. That is an interface choice rather than evidence of faster reasoning. A hallway display might make a reminder easier to notice without changing the model that composed it.

Board capabilities shape the interaction

The ESP32 instructions distinguish screen, image, and audio support by board. The simplest supported Espressif development board provides a light and button. More elaborate devices can show captions or images. Memory also affects whether a board supports the home-network tunnel.

A project that needs only an arrival indicator has different requirements from a spoken question interface. Selecting the hardware after defining the interaction prevents a common mismatch: buying an attractive display and discovering that its supported firmware lacks the desired input or network feature.

The instructions say push-to-talk sends a voice note for transcription and returns text. Spoken replies require an additional text-to-speech path. A microphone and speaker on the board do not automatically establish a complete spoken conversation experience.

Pairing requires a physical confirmation on supported ESP32 devices and creates an encrypted session. The documentation also states that community-device pairing lacks manufacturer verification. Physical presence, session encryption, and verified device identity answer separate questions. A button can demonstrate access to the hardware without certifying who manufactured its software.

Linux grants a different kind of authority

The Linux SDK exposes shell execution, file reading, file writing, and device-health information. Commands run as the account chosen during installation. If that account can use sudo, Muse can use that capability too.

That makes account selection part of the product design. A dedicated machine and a limited account can provide a defined workspace for an agent. An everyday account may carry access to unrelated files and administrative tools. The same natural-language request can reach very different resources depending on the account behind it.

Consider a request to report whether a backup completed. It needs access to the relevant status record and a way to return the result. It does not inherently require the authority to modify every file on the machine. Defining the required observation first makes the permission decision concrete.

The Linux route can also bridge an existing webhook or send a device message into a Muse chat. This lets a local event initiate an interaction. The useful boundary is between observing that event and authorizing a subsequent action. A temperature reading can support an alert without automatically authorizing the agent to reconfigure the computer.

Start with the action you want to expose

Muse’s new device project is most interesting as a set of interfaces to a hosted agent. A display, a home-service bridge, and a shell executor offer different forms of usefulness because they expose different authority.

A sensible first project has a clear input, a visible result, and a defined account or device capability behind it. That makes success observable and failure understandable. The choice of board then follows the interaction: information in a room, a bounded local service, or a computer task with an explicit permission scope. The SDK opens those routes. The device designer still decides how much of the surrounding world each route can reach.