Learning a habit is notpermission to act 学到一个习惯不等于获得自动执行权

While tracing one learned habit through the product, we found a particularly bad kind of silence. The system had written the habit into a rule and marked it enabled. But if it could not interpret the target value, the habit simply vanished. No error, no card, no sign that seenzus had learned anything at all.

Fixing the silence was not enough. A second path reached the right time and then said, in effect, “Time to turn on the light.” It knew the device and the action, yet handed the job straight back to the resident. One step further and the questions got harder. If someone turns on a child’s bedroom light at roughly the same time for several nights, when can an agent start doing it for them? Should a generic “comfortable” range reject 29°C when that is what one home’s central air conditioning actually needs? If bedtime drifts from 10:00 to 10:40, should the system cling to the old schedule or ask permission every time life moves?

Our answer is simple to state: a learned habit is not permission to act. In seenzus, a habit moves through observation, ask at the relevant time, and automatic care. Evidence gets it through the first two stages. The last stage also requires a hard safety check for the exact action, a run of real successful approvals, and one explicit grant from the resident. Once granted, timing may keep adapting. The device, action, and parameters may not drift with it.

This is a product decision we are implementing, not a claim about a feature already in people’s homes. We are writing about it now because it changed what “proactive” means to us. The hard part is not predicting the next action. It is knowing when the agent has earned the right to ask, when it may act, and when it must stop.

Learning a behavior only proves that it happened

Operation History can tell seenzus that the child’s bedroom light has often turned on around ten. The Learning Agent can turn those scattered events into a stable habit. What it has learned is a claim about the space: this tends to happen.

It has not answered a different question: who may do it next time.

The easy way to collapse those questions is to give every habit a confidence score and automate once the score crosses a threshold. We rejected that. High confidence says the agent believes its observation. It says nothing about whether a resident handed over control. The events may also have come from a wall switch, an existing home automation, or an earlier action by seenzus itself. Count them all as desire and the system soon learns to cite its own behavior as proof that it was right.

A new habit therefore stops at “ask at the relevant time” by default. If the resident opens Home near the usual time, they may see one short card: “You usually turn on the child’s bedroom light around now. Want me to do it?” The main choices are “Run” and “Skip.” If the current Source is read only, the habit still appears, labeled “Observation only · current connection is read only,” with a path back to the Source.

Visibility matters here. If an agent only shows learning when it can act, a resident cannot tell whether it learned nothing, lacks control, or failed quietly in the background. Observation is not a lesser result. It is the first part of the trust path.

Risk belongs to an action, not a device label

Our first instinct was to classify devices. Lights, climate, and fans looked low risk; locks and security looked high risk. The model broke almost immediately.

Locking and unlocking the same door are not equivalent. Turning off an air conditioner, setting it to cool at 29°C, and restoring its previous mode do not have the same certainty either. The hardest category is a plain switch. A Source may only tell us that it is a switch, while the wire behind it could lead to a lamp, a water heater, an electric blanket, or something else entirely. Assigning one weight to “switch” is a way of pretending uncertainty has gone away.

We moved the safety decision to the combination of device capability, exact action, and parameters. The Source reports what can be read or controlled and whether it can confirm the outcome. Deterministic policy then decides whether that exact action is eligible for automatic care, must remain ask-only, or is prohibited from proactive execution. The Learning Agent cannot change this policy. Neither can the resident force an excluded action into the safe category.

The first release admits lights and climate controls only, and only with explicit target states. On, off, and 40 percent brightness remain the same if delivered twice. Toggle, “a little warmer,” and “restore the last setting” do not. Climate permission is tied to one device, one mode, and one temperature rather than a range the agent may explore.

This is why a generic 18 to 28°C comfort band would be the wrong guardrail. In our living room, 29°C can be the right setting for the central air conditioning. If the device supports it, the pattern is real, and the resident grants permission for “this unit, this mode, 29°C,” seenzus can do exactly that. It cannot infer that 28°C must also be fine, much less optimize the setting down to 26°C.

Three approvals earn an invitation, not an upgrade

Asking solves the permission problem but does little for long-term friction. If someone presses “Run” every night, an agent that always asks is not much better than a reminder.

We added a narrow way forward. After the resident chooses Run for the same habit three times in a row, and the device confirms all three executions, the third result asks one more question: “Should I take care of this automatically?” The choices are “Automatic care” and “Keep asking.” A skip, a correction, a failed execution, or an unknown result breaks the streak.

The streak does not grant permission. It only decides when the invitation is appropriate. The resident’s final choice changes the authorization. We also do not keep selling the feature. If they choose Keep asking, seenzus does not raise the invitation again. They can still enable it later from the habit details.

The authorization is deliberately small. It binds the rule, control, action, parameters, current capability version, and time context. Permission to turn on one bedroom light does not reach other lights. Permission for living-room cooling at 29°C does not become freedom to pick from a range. Replacing the device, changing the Source mapping, or changing the available actions invalidates the old grant.

This takes more words than “trust the agent,” and considerably more state. In return, the resident grants something they can actually name.

Automatic care has to know when not to act

Sending the command is the easy part of unattended execution. Most of the safety work is deciding not to send it.

If the light is already on, seenzus records “Already at the target” and sends nothing. It does not count that as work completed. If the resident made a conflicting change on the same control during the preceding 30 minutes, current intent wins and this occurrence is skipped. If the service or Source comes back within 15 minutes of the schedule, the action may still run. Later than that, the occurrence is missed. A light or air conditioner should not suddenly move long after its moment has passed.

Failure does not trigger an enthusiastic retry loop. The current occurrence stops. The next ordinary occurrence may try again, but two failures in a row pause automatic care and return the habit to ask-only. Three consecutive skips caused by recent resident actions do the same thing, because the old habit may no longer fit.

A loss of control capability has an even simpler result: pause immediately and fall back to observation. If capability returns, the habit comes back as ask-only rather than silently reviving old permission. Undo is short lived too. It lasts 30 minutes and only appears if the pre-action state is trustworthy, no later operation has superseded it, and restoration still passes the safety policy. “Undo” several hours later is just another control action that may overwrite newer intent.

These rules will suppress some actions that would probably have been fine. We prefer that miss to a cleaner success rate built out of retries and resurrected authorization.

Timing may adapt; the permission boundary may not

Our first version of the design froze the authorized time. Approve 10:00 p.m., then ask again when the habit moves to 10:40. It was safe and painfully close to the rule engines we were trying to leave behind. Every shift in daily life became configuration work.

A time shift is different from a temperature change. Time is the rhythm of the same habit. The control, action, and parameters define what permission was granted. We decided that timing may move silently when the evidence is strong enough.

The evidence cannot include actions performed by seenzus. Only independent resident operations count. We require at least three, clustered within 30 minutes, and move the schedule to their median time. A new time within two hours of the existing schedule can be applied quietly, with a note in the habit details: “Adjusted from 10:00 to 10:40 based on your recent routine.” A larger move may be a different habit and needs a new decision.

Weekdays and weekends learn separately. A household may turn on the light at ten on work nights and at 11:30 on weekends. Averaging those into 10:45 gives a schedule that fits neither routine. They remain two time contexts inside one habit, each with its own evidence.

The first release stops there. Weather, presence, and the state of other devices may explain changes in routine, but they bring new ways to be wrong. We are not letting them rewrite unattended execution yet. Adding more context is only useful when each condition has a clear source of evidence and a clear way out.

A smarter experience needs a heavier state machine

The resident-facing path is short: I learned this. Want me to do it? Should I take care of it next time? Behind it, the system has to remember whether the rule is observation-only, ask-only, automatic, or paused. It has to retain the capability at the moment of authorization, distinguish failure from recent-intent conflict and a missed window, and tell resident operations apart from seenzus actions and other home automation.

We accept that cost because removing any one of those states hands the complexity back to the resident. Without a read-only state, they see silence. Without action-level policy, they have to judge technical risk themselves. Without a downgrade path, their choices become fully automatic or fully off. Without timing adaptation, they become the rule maintainer again.

Several numbers here are still provisional. Three approvals may be too slow. The 30-minute conflict window may be too wide. A two-hour drift boundary may fit one household and fail another. A wall-switch event may not tell us which resident changed their mind, especially around shared devices. That is why the initial allowlist stops at lights and climate. Range hoods, curtains, lifting devices, water heaters, and locks remain ask-only until their actions have their own evidence and safety rules.

Back to the central air conditioning at 29°C. We do not want a timer frozen at ten, and we do not want an agent that takes over the home after spotting the pattern a few times. It should notice the real habit, ask at a useful moment, then request one narrow permission after a few reliable collaborations. If the household’s timing shifts, it may follow. If the temperature, mode, or device changes, it asks again.

That is what automatic care means for us now. It is not one fewer tap. It is permission that can grow gradually and retreat when the world changes.