A good Space Agent can actively uncoverwhat users need 好的 Space Agent 可以主动挖掘出用户的需求

A resident tells seenzus that the electricity bill has been running high. seenzus first checks which devices are drawing power, then takes the conversation one step further. “You can ask me to put together a daily energy report.” The resident never asked what features the product has. The Agent noticed a potentially useful next step on its own.

That step matters. Many conversational products understand natural language, yet users still have to know what the product can do before they can make the right request. They need to know scheduled tasks exist, that devices can be linked, and that a stated preference can be remembered. The buttons may have become a chat box, but the user still has to learn the product.

A good Space Agent should be bolder. It can understand what someone is trying to handle, consider the state of the space and that person’s own history, uncover a plausible need that has not been stated directly, then turn the relevant capability into a useful next step. A need in this sense is a contextual hypothesis worth offering to the user. Their response and later use still have to validate it. AI-native feature guidance happens while the interaction is being generated. People talk about their lives. The Agent looks one step further.

Static onboarding teaches product language first

Traditional onboarding works well when the path is fixed. On a first visit, a tooltip points to one button. Once the user completes that step, another card explains the next one. The product knows where the person is in the flow and can guarantee that every sentence appears in the order the team wrote it.

It has a harder time knowing why the person arrived there. Someone asking about an electricity bill and someone who just adjusted a bedroom temperature may be on the same conversation screen, but the useful next step is different. A static tutorial can react to the page, account age, or completed setup steps. It cannot hear the sentence that was just spoken.

The current product behavior described below is as of August 2026. seenzus gives this guidance better material. The current message contains intent. The state of the space shows what is happening now, while previous interactions show which capabilities this person has used. Adding a separate tooltip layer would set that context aside and make the product guess again with the tools of conventional software.

We keep the guidance inside the conversation. There is no fixed card or fully scripted line. As the Agent answers the current request, it decides whether one capability could move the situation forward. If so, it says so in its own voice. The resident can ask a follow-up question or act on it immediately.

Three kinds of live context generate the next step

Generative guidance needs to understand at least three things at once.

The first is the current conversation. Scheduled tasks or device linkages become relevant when someone complains about repeating the same device actions every day. Memory becomes relevant just after someone says they prefer 26 degrees while sleeping. The topic determines whether there is a next step and how the Agent should phrase it.

The second is personal usage history. One member of a household may create scheduled tasks all the time while another only controls devices. seenzus records whether each person has used each capability themselves. Another member’s experience does not teach the current person how the product works. This lets the Agent make the honest offer, “You can ask me to…” Historical use for existing accounts has to be checked first. Use that can be reconstructed from existing records is restored, while an old preference with an uncertain origin remains unknown. Unknown is never treated as unused and never triggers guidance.

The third is the state of the space. A person may never have built a linkage, while a similar linkage created by someone else is already running. The Agent checks the space before making a suggestion so feature discovery does not create duplicate automation. Personal history answers whether this person has encountered the capability. The state of the space answers whether the suggestion still makes sense now.

All three can change from one turn to the next. Once someone creates a scheduled task, it leaves the candidate set. Deleting the task later does not erase the usage fact. Cleaning up an old task does not turn someone back into a beginner. When the topic changes, any unused capability has to wait for another relevant moment.

A complete decision tree would struggle with this interaction. People describe repetition, worry, and preferences in too many ways to enumerate. The generative model can understand those expressions and connect a capability to the immediate problem. That is work the model should own inside the product.

People set the capability boundary, the Agent judges the moment

Generative guidance still needs product judgment. seenzus currently maintains four capabilities that are suitable for an active suggestion: scheduled tasks, device linkages, important-device offline monitoring, and remembered preferences. Each one states what counts as use and includes scenarios written by the product team.

Scheduled tasks can follow a discussion about daily device routines, energy reports, or a morning briefing. Device linkages fit repeated friction, such as manually operating one device every time another device changes. If a resident says a device is important or needs someone to watch the home while they are away, the Agent can offer to monitor whether that device goes offline.

Remembered preferences have a higher bar. When someone says, “I like the bedroom at 26 degrees when I sleep,” the Agent can ask whether it should remember that preference. It does not interview the resident about preferred temperatures just to introduce memory. The conversation has already supplied a clear preference, and the Agent only offers the next step.

People maintain the capability catalog because deciding what deserves an active suggestion is a product choice. A list of database objects cannot make that call. The model receives a curated set of candidates and scenario cues, then uses the current turn to decide which one to mention, how to phrase it, or whether to leave the conversation alone.

This division keeps the interaction generative while leaving the product team responsible for the Agent’s range. We decide where it may go. The Agent decides how to take the immediate step.

A bold Agent has to know what it is interrupting

A Space Agent is bold when it offers a next step the user has not thought to request. The user does not need the feature name or a complete command. The Agent can open a new possibility from a complaint, a repeated action, or a preference that was just stated.

Every active suggestion also takes up room in the conversation. seenzus handles the current request first and adds at most one capability in a turn. The suggestion must follow naturally from the topic, use the current state of the space, and stay in the Agent’s first-person voice. If none of the candidates fit, the Agent stops after addressing the user’s original request.

These rules support active interaction. Without them, the Agent could list all four capabilities at once or introduce itself again at the start of every conversation. That would be bold in the literal sense and exhausting in practice. An Agent that remains present in a space has to keep some distance between advancing the conversation and taking it over.

We do not add delivery receipts, cooldown timers, or rejection states for every suggestion. The candidate set is small, and a capability drops out after a person uses it once. The Agent judges each turn from live context, and a suggestion that did not fit the previous turn does not wait in a queue. The interaction stays tied to the moment instead of turning into content distribution.

Actual adoption is closer to the goal than suggestion receipts

The goal of feature guidance is for people to use a capability. The seenzus internal dashboard reports how many people have used each capability, cumulative uses, and first-use changes over the last seven days. The team can see how many people have created a scheduled task themselves, whether more people have started using device linkages, and which capabilities remain hard to discover.

The record contains the capability, first and most recent use times, and a cumulative count. The count covers successful creations, device markings, or preference writes from a conversation. Preferences inferred by background learning do not count, and neither does the number of times a task later runs. Conversation content and device details stay out of it. A task that was created and later deleted still counts because this measure concerns adoption. The number of tasks that remain active is a separate question.

We cannot tell whether a particular generated suggestion led to an action several days later. The system does not create an event for each suggestion or add a “saw guidance” state to the user. A seven-day trend shows whether adoption changed, but it cannot give one conversation credit.

These metrics can monitor capability adoption, but they cannot measure the incremental effect of feature guidance. We still avoid recording each suggestion for a direct reason. Deciding whether a generated reply contained guidance is itself a fuzzy judgment, and linking the suggestion to behavior several days later would add unnecessary conversation tracking. For now, we accept that the causal effect is unknown and watch whether more people use the capabilities.

After uncovering a need, the next step still has to help

The interaction is now implemented, but we do not yet have usage data showing that it improves adoption. The model may miss a good moment. It may also see relevance where the resident sees an unnecessary aside. Static onboarding is easier to predict. Generative guidance has to prove its judgment over many real conversations.

We are willing to carry that uncertainty. A Space Agent should understand and advance the situation on its own. It looks for the next step in what the user has already said instead of waiting for a complete command with the right feature name.

Return to the electricity bill. The resident only has to say that the bill is high. The Agent handles the immediate problem and can also notice the next step of a daily energy report. Once the resident adopts it, that guidance disappears. If they do not, the Agent waits until another conversation gives it a relevant place.

We have decided to let the Agent look one step further. Real use now has to tell us whether that extra step helps.