Discover capabilities
Find a device and understand its inputs, outputs and available actions.
A physical interface
for your agent.
gadgets.bot is the working name for our agent-to-hardware SDK. Bring an existing agent, connect physical capabilities, and keep control of the setup.
Research complete. Implementation has not started. Scope and initial support are being defined.
The connection
we’re working on.
A device should expose what it can do in a way your agent can use. The SDK’s proposed job is to connect those two worlds.
Invoke and observe
Call a capability, inspect status and receive events back from the device.
Keep a local bridge
Connect agents and devices through a local service, with permissions and approvals designed into the flow.
Your agent→MCP interface→Local bridge→Device
Proposed architecture, not a shipping integration. Hardware support and local operation depend on the implementation and the agent/model you choose.
Start with
the useful layer.
The initial tooling direction is practical: help a builder get a device connected, inspect its behavior, and make it usable by an agent.
- Local service
- A bridge between device communication and agent-facing tools.
- Builder tooling
- Flashing, commissioning, monitoring and logs are research priorities, not released commands.
- Agent interface
- An MCP-facing surface, with an OpenAI-compatible endpoint also under consideration.
- Hardware candidates
- ESP32-family boards and Raspberry Pi. There is no tested compatibility matrix yet.
- Approval and visibility
- Make physical actions understandable and reviewable. Boundaries must be enforced by the implementation.
Agent-agnostic is the goal.
Tested support is the promise.
“Any agent, any board” describes an ambition. Initial support will be narrower and documented with tested combinations. We’ll distinguish what works, what is experimental, and what is still planned.
Where it goes.
First: agent-to-hardware tooling
Define the interfaces, choose the initial device and harness targets, implement the connection, and validate it with real builds. There is no release date or downloadable package to announce yet.
Then: a continuing build loop
The wider electrondreams direction brings composition, verification, telemetry and remixable projects together. A device can keep evolving after its first build.
On-device models are a separate track
An agent controlling a device does not mean its model runs on that device. On-device inference depends on compute, memory, power and model fit; it is a separate part of the longer-term direction.