SkyHaven GROUP AIM→
AI

The House Is Becoming a Room Full of Agents

A home-energy prototype shows the path from a read-only report to an approved action, with device limits, stale evidence, and the homeowner’s decision kept visible.

Modern kitchen with a refrigerator, toaster, coffee maker, thermostat, and home energy display connected by subtle blue and gold signal lines.

Field note · AI systems

A compatible thermostat, energy meter, and charger can expose enough state for a useful first report. Start by checking the interfaces your devices actually provide.

Illustrative prototype: the device states, messages, approvals, and results below are sample data, not a report from an installed home. All code snippets are pseudocode showing an interface contract, not a working device SDK.

Read-only first Existing endpoints 1 report 1 approval Check compatibility

The test: Can a harness explain what happened, show its evidence, ask for approval, and record the result?

An illustrative afternoon

The thermostat sees an empty house. The electric vehicle remains plugged in at 38 percent. The home battery holds 52 percent. The utility feed shows a higher rate at 4:00 PM. The washing machine waits for a cycle.

Each system holds one part of the situation. The systems cannot make the decision together because they do not share a contract or a room.

Reports no occupancy. Temperature: 70°F.

Reports peak pricing from 16:00 to 20:00.

Reports the vehicle at 38 percent and connected to the charger.

Compares the readings and recommends charging before peak pricing.

Shows the proposal and requests homeowner approval.

Returns “charging started.” The harness records the result.

Illustrative energy decision recordSample data

Observed

House empty since 14:31. Vehicle connected at 38%. Peak rate begins at 16:00.

Recommendation

Charge before 16:00. Keep a 20% reserve in the home battery. Ask the homeowner before sending the command.

Decision record

Approved at 15:16. Charger accepted the command. Result stored in the home room.

Load profilekW / 24h
00:0012:0020:00

Illustrative load profile, not a measured household result. The initial report is read-only. The later charging command is a separate action requiring explicit homeowner approval.

Charging before peak pricing is a candidate plan, not an optimum established by these four readings. Check the departure time, target charge, charging rate, household load limit, tariff, and home-battery policy before asking for approval.

The room shows the handoff

The room gives people a place to inspect the same work that agents exchange through APIs. A2A-style messages can carry structured context between agents. The room can show a readable version of each observation, proposal, approval, and result.

Home / agent roomIllustrative afternoon
Home energy · current conversation
Thermostat · observation

Occupancy sensor reports no one home. Temperature: 70°F.

Utility meter · context

Peak rate begins at 16:00 and lasts four hours.

Vehicle agent · observation

Vehicle is plugged in. Battery: 38 percent.

Energy agent · proposal

Charge before 16:00. Keep a 20 percent reserve in the home battery. Request homeowner approval.

Kitchen · current conversation
Refrigerator · observation

A household inventory entry lists milk below the threshold and records that the bread was opened yesterday. A refrigerator can supply this only if a compatible inventory interface exists.

Calendar · context

Two guests arrive for breakfast tomorrow.

Kitchen agent · proposal

Add milk and bread to the next grocery order.

Maintenance · current conversation
Sink sensor · observation

Moisture appears beneath the utility sink. Confidence: 0.94.

Maintenance agent · proposal

Close the main valve and notify the homeowner. Approval required.

Use the endpoints you already have

The first implementation can wrap a local home hub, a Matter or Thread controller, an MQTT topic, a manufacturer endpoint, a utility tariff feed, an EV charger protocol, or a simple sensor gateway. These examples show the shape of the adapter; they do not recommend a device vendor.

ObserveRead state with a source and timestamp.
ProposeName the action and cite the evidence.
ActCall only the control that policy allows.
RecordStore the command result and failure state.

Illustrative thermostat adapter

const thermostat = {
  observe: () => hub.get("/devices/thermostat/state"),

  propose: (target, evidence) => ({
    device: "thermostat",
    action: "set_temperature",
    target,
    evidence,
    requires: "homeowner.approval"
  }),

  act: (proposal) => policy.allows(proposal)
    ? hub.post("/devices/thermostat/commands", proposal)
    : { status: "blocked" }
};

Illustrative energy adapter

const homeEnergy = {
  context: async () => ({
    rate: await utility.get("/tariff/current"),
    battery: await battery.get("/state"),
    vehicle: await charger.get("/vehicle/state")
  }),

  propose: (plan) => policy.check({
    kind: "charge_vehicle",
    plan,
    reserveHomeBatteryFraction: 0.20
  })
};

The adapter hides endpoint details. The harness sees named capabilities with policy boundaries.

Give the operator harness a real job

Codex or Claude Code can read the adapters, run a report, compare today with last week, calculate a trend, and identify an anomaly. The harness can return the result to a person before it touches a control.

const report = await harness.run({
  task: "produce the 24-hour home energy report",
  sources: [
    "thermostat.readings",
    "meter.intervals",
    "battery.state",
    "vehicle.state"
  ],
  outputs: ["summary", "anomalies", "next_actions"],
  policy: "read_only"
});

One run can produce three outputs: a source-backed explanation for a person, structured metrics for a dashboard, and a proposal for another agent.

One message, two views

A typed event carries evidence and approval requirements to the adapter. The room gives the homeowner a readable view of the same proposed decision. The A2A-style envelope below is pseudocode; an implementation needs the contract its chosen transport actually supports.

await a2a.send({
  from: "energy-agent",
  to: "vehicle-agent",
  type: "proposal",
  intent: "charge_before_peak",
  context: report.anomalies,
  requires: ["homeowner.approval"],
  expiresAt: "2026-08-14T16:00:00-07:00"
});
15:12 Operator harness: report complete
15:12 Energy agent: peak load likely at 17:30
15:13 Vehicle agent: proposal received
15:13 Home room: approval requested
15:16 Homeowner: approved charging plan
15:16 Vehicle agent: command accepted; result recorded
What happens when the agents disagree?

The utility feed returns a stale rate. The thermostat reports an empty house, but the occupancy sensor reports movement. The charger rejects the command. The harness should stop the action, show the conflicting observations, mark the report incomplete, and ask a person to resolve the conflict.

The failure record matters as much as the success record. A home should never hide uncertainty behind a confident sentence.

Build the first loop

  1. Choose one sensor, one controllable device, and one source of context.
  2. Wrap each endpoint with observe, propose, act, and record.
  3. Connect the adapters to Codex, Claude Code, or a small service. Keep the first run read-only.
  4. Ask the harness for one report. Store the sources, timestamps, assumptions, and calculations.
  5. Post the report and proposal to a shared room. Use A2A or a typed event bus for the agent exchange.
  6. Allow one low-risk action after the room shows the evidence, policy, approval, and result.

Acceptance checks

EvidenceEvery observation names its source and timestamp.
PolicyEvery control names the permission that allows it.
ApprovalEvery consequential action records who approved it.
ResultEvery command records success, rejection, timeout, or retry.
What the harness should show

Show the source data, the calculation, the assumption, the recommendation, and the result. Keep private chain-of-thought private; expose the evidence and decision record a person needs to audit the work.

The refrigerator can remain a refrigerator. The thermostat can remain a thermostat. Give each endpoint a small role, give each agent a small set of tools, and give people a report, a room, and a clear approval path. Then let the harness run one safe action and show exactly what happened.