“The longer it serves you, the better it understands you” is a product promise.
At first, the promise sounds simple. Users should not have to explain the same thing every time. An agent can remember stable preferences, use them when a request leaves something unspecified, and draw on confirmed context from the space instead of asking unnecessary questions.
While designing long-term memory, we ran into the other half of the promise: people change.
We use a simple design case to test it. A user once says they feel cold easily, so the agent treats 25°C as a default. Months later, the user says, “Set it to 22°C.” If the agent keeps insisting on the old preference, the problem is not that it remembers too much. It has put an earlier inference ahead of the user’s current words. A memory meant to reduce repetition now asks the user to prove that they have changed.
A long-running agent therefore needs clear rules for using history. It must know when an old preference is useful, when to stop using it, and when the current instruction takes priority. For a product, forgetting is how it acknowledges that a user can change. It is not simply a data-deletion feature.
Understanding you better cannot mean saving more of your past
The easiest version of “getting to know you” is an ever-growing record. The system observes what someone does, summarizes what they usually do, and reuses that conclusion whenever a similar situation comes up.
It has real value. It can reduce repeated setup and make an underspecified request more useful. The problem is that “usually” can quietly become “always.”
Someone may dim the lights because they are about to sleep. They may lower the temperature because the weather changed, or because someone else is in the room. One action does not establish a stable preference, and a short run of repeated actions does not necessarily describe a lasting change. If an agent treats every pattern as part of a person’s identity, it can start giving historical inferences more weight than they deserve.
We want seenzus to remember background that helps with the current interaction, rather than build a fixed model of who a user is. Past information may inform a judgment, but it cannot decide what the user wants now. A current request can override a default. A suggestion can disappear when its context no longer applies. The agent cannot reject a clear new request by saying, “But you always do it this way.”
A habit is a reference, not an identity
A preference stated by the user and a pattern inferred from behavior do not have the same level of certainty.
“This space often uses warm light at night” is an observation about the space. “I prefer warm light” is something the user has said about themselves. Either may help in the right situation, but they should not be updated or overridden in the same way.
Personal preferences and space habits also need to remain distinct. A person may prefer the same temperature in different places, while the lighting, devices, and routines of one space may not apply anywhere else. Turning a repeated environmental behavior into a personal identity can affect the wrong place and make other members live with a preference that is not theirs.
Memory should fill in context that a current request leaves open. It is not an identity system that makes decisions on the user’s behalf. If the user says, “Set this space to 22°C,” an earlier temperature preference cannot block the request. The request also does not have to rewrite every future situation. A current intention and a long-term preference answer different questions.
Forgetting first means stopping the use of an old inference
In the product, forgetting first means stopping the use of an old inference. Whether the underlying record is deleted is a separate question. An inference that no longer fits the current situation should stop affecting defaults, suggestions, and action judgments.
Suppose an agent inferred that a user wants a reminder every night at ten. The user’s routine later changes. The user should not have to find a setting before the agent can stop relying on that inference. Without enough current evidence, it should not treat the old routine as today’s fact.
That does not mean every historical fact should be erased. Past events and the inferences drawn from them are different things. The old inference should stop affecting current service; the product does not need to deny that the past happened.
The same rule applies to proactive behavior. When an old routine no longer fits, the agent should make fewer suggestions based on it. If the new information is not enough to support a replacement judgment, silence is better than repeating the old one. A user should not keep receiving the same interpretation simply because they once accepted it.
The current statement must come before the old inference
When new and old information conflict, a clear current statement should take priority over an inference from past behavior.
If the user says, “Set the air conditioner to 22°C today,” that is a complete current request. The agent should not keep 25°C because it remembers that the user used to feel cold. Nor should it demand an explanation for the change. Executing the current request and updating a long-term understanding are separate decisions. The first can happen immediately; the second needs stronger evidence or another explicit statement.
If the user says, “You remembered that wrong,” the product should not treat it as ordinary feedback and leave it for a later pass. It is a direct correction to the current understanding. The agent should stop relying on that mistaken statement and use the conversation to establish a better one when needed.
Several changed actions, by contrast, may not be enough to overturn something the user explicitly said. The cause could be weather, visitors, health, or a change in how the space is being used. The agent can notice the conflict and ask one concrete question when it matters to the current decision. It should not decide, without the user, which preference is currently valid.
This is the cost. Automatic rewriting makes the product feel faster, but it also makes short-term behavior easier to mistake for long-term change. Preserving the conflict and asking a question adds a turn, while leaving the user in control of changing their own preferences.
In a conflict, less confidence is often better than more explanation
An agent needs to make judgments. It does not need to present every judgment as a settled fact.
When an old understanding conflicts with new behavior, the interface should not use a precise-looking confidence score to decide for the user. “There is an 87% chance you prefer 23°C” does not resolve the conflict. It still leaves the user to decide whether the number is high enough, and it hides why a temporary action became a preference.
A better product behavior is to narrow the claim. The agent could say, “You previously said you feel cold easily, but you have set the temperature to 23°C several times recently. Which should I use going forward?” If the conflict does not matter to the current request, it can leave the question alone and follow the explicit instruction. Not every change deserves a conversation.
This is a specific limit on what “understanding” means for seenzus. The agent may retain background, but it cannot present an uncertain inference as a confirmed fact. When the information is insufficient, it can leave the old inference out of the current decision. That reduces incorrect suggestions, even when the result feels less proactive.
Deleting a record does not prevent future understanding
If a user says, “Forget what time I went to sleep last week,” the product should stop using that record in later service. This removes one specific understanding.
Removal should not automatically become a lasting prohibition against understanding similar information in the future. If the user later says, “I have started going to bed at eleven again,” the agent should be able to learn from that explicit statement. Otherwise, forgetting would become another kind of unchangeable memory.
“Do not record my sleep schedule” is a different request. It is not a fact about last week. It is a preference about how the product should serve the user in the future. The product should respect that preference and allow the user to change it later.
The user should not need to understand the storage model to get these outcomes. Saying “forget this” should stop the old understanding from affecting service. Saying “do not learn this kind of information” should make later judgments about that category more restrained. The product needs to make the difference clear rather than hide both outcomes behind an ambiguous delete control.
We accept that the agent will sometimes be less certain
If old inferences cannot override the present, some automation is lost.
The agent may ask one more question, and some changes may need to be stated rather than inferred from behavior. An old understanding may remain temporarily when there is not enough evidence against it. That is less impressive than always guessing correctly, but it avoids a more serious product failure: using history to deny the user’s current request.
“Allow forgetting” cannot be reduced to one switch. Different kinds of information have different stability, and personal preferences do not change in the same way as space habits. We still need to learn when the product should quietly stop using an old inference, when it should ask, and when it should tell the user that its understanding has changed.
We do not yet have enough long-term user data to answer those questions. This article therefore does not present “understanding you” as a finished capability. It does state the product boundary we can defend now: history is a reference, the current statement comes first, and an inference must remain open to correction. An old understanding cannot override current information indefinitely.
The value of long-term service is not that an agent permanently remembers who a user used to be. It is that, when the user changes, they do not have to repeatedly correct the agent’s interpretation of the past.
For seenzus, understanding someone better over time includes knowing when a memory should no longer affect the current request.
“住得越久越懂你”是一个产品承诺。
它首先意味着，用户不必每次重新解释同一件事。Agent 可以记得一些稳定的偏好，在请求不完整时提供合适的帮助，也可以利用空间中已经确认的背景减少不必要的询问。
我们在设计长期记忆时，很快遇到这个承诺的另一面：用户会改变。
我们用一个设计场景来检查这条承诺。用户曾经说自己怕冷，Agent 因此把 25°C 当成默认；几个月后，用户明确说“调到 22°C”。如果 Agent 仍然坚持旧偏好，问题不在于它记得太多，而在于它把过去的推断放到了当前表达之前。过去的认识本来是为了减少沟通，最后却要求用户先证明自己已经改变。
因此，长期服务用户的 Agent 必须知道历史何时有用、何时应停用；用户一旦明确表达，当前表达优先。遗忘是产品对用户改变的承认，不是简单删除数据。
更懂你不能等于保存更多过去
最容易实现的“越来越懂你”，是把过去不断累积起来。系统记录用户做过什么，归纳出用户通常怎么做，再在下一次相似情境出现时沿用这个结论。
它确实有用：可以减少重复设置，也能让模糊请求得到更贴近当前空间的回应。问题出在“通常”很容易被写成“永远”。
用户晚上把灯调暗，可能只是当天需要休息；把空调调低，可能是天气突然变热，也可能是房间里多了一个人。一次行为不能说明稳定偏好，短期重复也不一定代表长期变化。如果 Agent 把每个模式都当成用户身份的一部分，系统就可能把历史推断当成比当前信息更高优先级的依据。
我们希望 seenzus 记住的是对当前服务有帮助的背景，而不是为用户建立一个固定用户模型。过去的信息可以参与判断，但不能替用户决定他现在想要什么。默认值可以被当前请求覆盖，建议也可以因为新的上下文而不再出现。Agent 不能用一句“你以前一直这样”拒绝一个清楚的新要求。
习惯是参考，不是身份
从行为中归纳出的习惯，和用户明确说过的偏好，可信程度不同。
“这个空间晚上经常使用暖光”是一条关于空间使用的观察；“我喜欢暖光”是用户对自己的明确表达。前者可以帮助 Agent 在信息不足时提供一个合理起点，后者才更接近用户愿意长期保留的偏好。两者都可能有用，但不能用同一种方式覆盖和更新。
个人偏好和空间习惯也要分开。一个人在不同地点可能仍然喜欢同样的温度，但某个空间的照明方式、设备安排和使用时间未必适合搬到另一个空间。把环境里的重复行为直接当成个人身份，可能影响错误的地方，也可能让其他成员承担并不属于自己的偏好。
记忆的作用是补充当前请求缺少的背景。它不是一个替用户做决定的身份系统。用户说“把这里调到 22°C”，过去的温度偏好不能阻止这次请求；这次请求也不必自动改写所有未来场景。当前意图和长期偏好各自解决不同的问题。
遗忘首先意味着停止使用旧认识
在产品里，遗忘首先意味着停用一条旧推断。是否删除存储记录，是另一件事。旧推断不再适合当前情境时，也不应继续参与默认值、建议和行动判断。
例如，Agent 过去根据几次对话认为用户每天晚上十点需要提醒。后来用户的作息变化了。用户不应该先找到一项设置，才能让 Agent 停止引用这条旧认识。只要当前没有足够依据，Agent 就不应把它当成今天的事实。
这并不等于所有历史都应该被抹掉。过去发生过的事实，和从事实得出的旧推断，需要分别处理。需要停止的是旧推断对当前服务的持续影响，而不是让系统否认过去发生过什么。
这条边界也适用于主动服务。一个旧习惯不再适合时，Agent 应该减少以它为依据的主动建议。新的信息还不足以形成稳定判断时，保持安静比继续重复旧建议更合适。用户不应该因为过去曾经接受过一次帮助，就持续接收同一种判断。
当前表达必须优先于过去推断
在新旧信息发生冲突时，当前明确表达应当优先于过去的行为推断。
如果用户说“今天把空调调到 22°C”，这是一条完整的当前请求。Agent 不应该因为记得用户以前怕冷，就继续使用 25°C；也不应该要求用户先解释为什么改变了偏好。执行当前请求和更新长期理解是两件事。前者可以立即完成，后者需要更充分的依据，或者用户再次明确说明。
如果用户直接说“你记错了”，产品也不应该把这句话当作普通反馈，等以后再处理。它是对当前认知的明确纠正。Agent 应该在之后不再继续引用那条错误认识，并在需要时用对话确认新的表述。
相反，几次行为变化并不一定足以推翻用户亲口说过的话。用户可能因为天气、来客、身体状态或空间用途暂时改变操作。Agent 可以发现矛盾，并在这个矛盾真正影响当前判断时提出一个具体问题；它不能在用户没有参与的情况下，替用户决定哪一种偏好才是当前有效的偏好。
这就是产品上的取舍。自动改写会让系统看起来反应更快，但也更容易把短期行为误认成长期变化。保留冲突并询问，会多一次沟通，却把修改自己偏好的权利留给用户。
冲突时，减少自信比增加解释更重要
Agent 需要表达判断，但不需要把所有判断包装成确定事实。
当旧认识和新行为不一致时，界面不应该用一个看似精确的把握度替用户做决定。“87% 的可能性是你喜欢 23°C”并没有解决冲突。用户仍然不知道这个数字是否足以改变今天的动作，也不知道系统为什么把一次临时行为算进了偏好。
更合适的产品行为是缩小结论的范围。Agent 可以说“你之前提过怕冷，但最近几次调到了 23°C。以后按哪个来？”如果这个问题与当前请求无关，它也可以暂时不提，继续按照明确指令服务。不是每一个变化都值得一次对话。
seenzus 对“理解”的要求很具体：Agent 可以保留背景，但不能把不确定的推断伪装成用户已经确认的事实。信息不足时，它可以暂时不使用这条旧认识。这会减少错误建议，即使结果没有那么主动。
删除一条记录，不等于禁止未来重新理解
如果用户说“忘掉我上周几点睡”，产品需要让这条记录不再影响之后的服务。这是删除一条不再需要的认识。
但删除不应该自动变成一条持久的禁止规则，阻止系统以后再次理解同类信息。如果用户过了一段时间主动说“我最近又开始固定十一点睡了”，Agent 仍然应该能够根据这次明确表达重新建立理解。否则，遗忘只是另一种不可修改的记忆。
“不要记录我的作息”则是另一种请求。它不是关于上周几点睡的事实，而是用户对未来服务方式的要求。产品应当尊重这条要求，并让它成为用户可以继续修改的偏好。
这两个请求的区别不需要用户理解存储结构。用户只需要知道：他说“忘掉”时，旧认识会停止影响服务；他说“不要再学习这一类信息”时，之后的相关判断会更加克制。产品需要把这两种结果说清楚，而不是把它们都隐藏在一个模糊的删除按钮后面。
我们接受 Agent 有时不够确定
不让旧认识继续影响当前判断，会牺牲一部分自动化效果。
Agent 可能会多问一次，也可能要求用户明确说明某个变化。没有足够反证时，一些过去的认识还会暂时保留。这样做不如“每次都猜中”看起来聪明，但它避免了另一种更严重的产品失败：系统用历史判断否定当前用户。
我们也不能把“允许遗忘”写成一个简单的开关。不同类型的信息有不同的稳定性，个人偏好和空间习惯的更新方式也不同。真正需要验证的是：用户希望系统在什么情况下自动停止引用旧认识，什么情况下应该询问，什么情况下即使没有新请求也应该主动说明自己已经修正。
目前我们还没有足够的长期用户数据回答这些问题。因此，这篇文章不把“懂你”描述成一个已经完成的能力。我们能先确定产品边界：历史是参考，当前表达优先，推断必须允许被纠正，旧认识不能无限期覆盖当前信息。
长期服务的价值，不是让 Agent 永远记得用户曾经怎样，而是让用户改变之后，不必先反复纠正 Agent 对过去的理解。
对 seenzus 来说，住得越久越懂你，首先意味着它知道什么时候该使用记忆，也知道什么时候不该再使用。