The idea
Coordinate helpful home-automation tasks through supervised specialised agents while retaining predictable control. V1 observes device state and proposes one low-risk lighting action for approval. It does not autonomously operate locks, heaters, mains machinery or other consequential equipment.
The connection
Specialised agents propose useful actions while a controlled execution layer protects predictability. The design question is how to combine flexible reasoning with dependable everyday behaviour.
How it could work
Separate perception, planning, policy and execution. Agents may propose structured actions, but only a deterministic executor with explicit permissions can call device services. Every proposal carries the target, requested action, reason, source state, expiry and expected outcome. Re-check current device state at execution time; an old observation is not authority to act now.
Use one local controller and a durable action journal before distributing agents. A Raspberry Pi 4 may host orchestration, but local model inference performance must be measured for the selected model. Keep the model backend replaceable and ensure ordinary home automation continues if it is unavailable.
What would prove it
Use a simulator or test lamp for 30 scenarios: stale observations, duplicated proposals, agent disagreement, network loss, manual override, expired approval and executor restart. Include adversarial text in device names and notes; it should be treated as data, not execution instructions.
Proposed gate: no unapproved action executes; duplicate requests cannot cause repeated side effects; manual changes are respected; expired approvals are rejected; every attempted action has an auditable outcome. Run the same scenarios with the model disconnected to confirm core automation and manual controls still work.
The path to a complete build
- Define the narrow action schema and a deny-by-default permission list.
- Implement deterministic policy/execution against a simulated device.
- Add the approval interface and durable journal, then run fault tests.
- Introduce one planner agent in read-only/proposal mode.
- Pilot one real lighting workflow and measure whether agent coordination improves it over an ordinary automation.
Open the engineering notebook
Components, interfaces and calculations
Pilot inputs: existing Pi/storage/power, a supported automation platform, one test lamp or simulated device, restricted service credentials and an approval interface. Keep manual control available. States include observed, proposed, approved, executing, verified, failed and expired, each with timestamps and an action ID.
Handle retries by action ID and known desired state rather than toggling blindly. “Set lamp off” is easier to reconcile than “toggle lamp” after a timeout. Verification reads actual device state and reports uncertainty if the platform cannot confirm it. Record human rejection and cancellation as normal outcomes.
Scope and development questions
Allow 6–10 sessions for the constrained pilot. Measure Pi memory/CPU load and storage reliability before adding services. Separate hosting or inference usage from hardware costs. Resolve the current automation platform, devices, privacy requirements and the actual problem needing multiple agents. If a simple rule solves it more reliably, retain that rule and restrict agents to explanation or planning.