---
title: Gadgets and the four rings
description: Bring the personal agent into the physical world through a stable capability contract.
---

A gadget gives Impo a physical interface: a display, microphone, speaker, camera, button, sensor or actuator. ESP32 firmware and the Linux Device SDK connect to the gateway, register what they can do and receive commands for their paired account.

The hardware SDK lives in [impo-gadget-sdk](https://github.com/impoai/impo-gadget-sdk). The API, worker and gateway live in [impo](https://github.com/impoai/impo). A board port belongs in the SDK; account policy belongs in the application platform.

## The four rings

![Ring 0 is the platform kernel, Ring 1 contains user-created gadget agents, Ring 2 contains devices, and Ring 3 contains ecosystem integrations. Gadget agents request actions through the kernel.](/assets/gadget-rings.svg)

| Ring | Responsibility | Extension owner |
| --- | --- | --- |
| **0 — Kernel** | Personal agent, API, worker, dispatcher and gateway. Identity, permissions, routing and execution policy. | Platform maintainers. |
| **1 — Gadget agents** | Persistent user behavior: triggers, allowed actions, instructions and state. **Proposed.** | Users with their personal agent, through validated creation tools. |
| **2 — Devices** | Firmware, board adapters and exported commands, capabilities and events. | Makers and SDK maintainers. |
| **3 — Ecosystem** | Product-specific skills and integrations for other devices. Impo's home-network tunnel is **not implemented**. | Integration authors. |

These are responsibility boundaries, not CPU protection levels. The four numbered layers are Impo's adaptation of the kernel/user-space idea discussed in the [Dreamer interview](https://www.latent.space/p/dreamer), especially 21:55–23:23. They are not a claim about Dreamer's hardware architecture.

## One rule for authority

Ring 1 asks Ring 0 to act. It does not receive device administration credentials or bypass account policy. The same applies to a Ring 3 integration: a skill can explain an operation, but cannot grant permission to perform it.

Kernel mediation means server-enforced policy. It does not require a fresh main-chat model turn for every fixed action. The planned rules runtime can execute a validated action without calling a model.

## What exists today

Gadgets pair to an account, register `commands_v2` and a capability summary, and exchange `link.invoke`, `link.result` and `link.event` messages. Main Chat discovers registered commands through `impo_list_gadgets` and calls `impo_gadget_command`.

Events currently enter main Chat as `[Gadget event]` messages. The gateway sends the resulting spoken reply back to the originating gadget. A separate subscription router and user-created gadget-agent definitions do not exist yet.

## Pick your path

- Have hardware to support? Start with [add a board or Linux device](/docs/gadgets/add-a-board/).
- Need a new operation or sensor event? Read [commands and events](/docs/gadgets/commands-and-events/).
- Want reusable, user-created behavior? Read the [gadget-agent design](/docs/gadgets/gadget-agents/).
- Connecting another product? Check [ecosystem integrations](/docs/gadgets/integrations/) and the current transport limits.

The complete [Gadgets design record](/docs/source/gadgets-design.md) includes policy requirements, implementation gaps and delivery stages. The SDK's [capability vocabulary](https://github.com/impoai/impo-gadget-sdk/blob/main/CAPABILITIES.md) owns command names, parameters and results.