DocumentationExtend Gadgets
User-created gadget agents
The proposed layer for persistent behavior built in natural language and hosted by the platform.
A gadget agent is a saved behavior bound to a person's gadgets. “When it gets shaken, play this sound” should become a trigger and a fixed action. “When I pick it up in the morning, read my first meeting” needs a bounded run with calendar access and speech.
This is Ring 1 in the four-ring architecture. The creation tools, saved definitions, event router and automation controls described here are not implemented. Ordinary Tasks and scheduled Tasks exist, but are not this feature.
The saved definition#
| Field | Purpose |
|---|---|
| Gadget bindings | Which owned devices the behavior may use. |
| Triggers and filters | Device events, schedules or explicit invocations; webhooks are a later extension. |
| Allowed commands and tools | The specific actions available to the run, subject to current grants. |
| Execution kind | rules for fixed actions or llm for judgement. |
| Instructions or actions | Natural-language behavior for a bounded agent, or validated deterministic actions. |
| State and budgets | Small owned state; limits on frequency, duration, tool calls and model use. |
| Revision and enabled state | Lifecycle controls that can fence already queued work. |
The SDK proposal starts with bounded JSON state and separate run records. A dedicated per-agent database is a later option. The JSON in the design record is illustrative; it is not a supported API payload.
Build, test, keep#
The personal agent discovers real gadget and platform capabilities, explains a plan and submits a definition through a proposed creation tool. The server validates ownership, command availability, arguments, permissions and budgets.
A dry run checks and describes actions without sending them to hardware. A requested live trial uses the same policy path. The user can then enable, disable or edit the behavior and inspect its runs from the gadget's automations view.
Once enabled, the saved trigger starts the work. The user does not need to keep the app open or repeat the instruction on every event.
Route and execute#
The proposed POST /api/v1/gadgets/events admits a structured, owned event. A router matches enabled definitions and queues runs. An unmatched event retains the current main-chat behavior. A matched run that fails or exceeds its budget must not bypass that limit through a main-chat fallback.
Rules run fixed actions through the shared dispatcher with no model call. LLM runs use a bounded Rebyte Agent session on the worker with an explicit tool allowlist. Both request device actions through Ring 0.
Shared policy#
The platform must enforce grants at execution, deduplicate triggers, fence disabled or revised definitions, arbitrate shared speakers and preserve state under overlapping runs. Physical movement needs explicit permission and bounded execution. Local hardware stop behavior remains in the firmware.
An uncertain side effect is not replayed automatically. Run logs distinguish accepted commands, completed actions, skipped work and failures.
Delivery stages#
- Rules: versioned contracts, owned storage, event admission, trigger matching, fixed actions, dry runs and user controls.
- LLM agents: bounded worker sessions, granted tools, resource arbitration and run inspection.
- Observation: consent, retention and limits for camera streams, plus a worker that produces semantic events.
- Sharing: reusable definitions with fresh per-user grants and no copied credentials or state.
The complete design and SDK proposal preserve the decisions and remaining contract questions.