While reorganizing the product model at seenzus, we ran into a concrete choice. A person may manage both a home and a studio and want the same Agent to remember how both places work. Their parents’ home is also a home, but it has different members, routines, and authority. Which of these places should belong together?
Building type gives the wrong answer. A model organized around Home would group the two homes and split off the studio. A login account does not settle the question either. It identifies the person using the product without telling the Agent which shared memory and rules apply where they are now.
We chose World for that boundary. Places belong to one World when they share an Agent, environmental memory, and Rules. A World tells the Agent which body of long-term understanding it is working within.
A building type cannot decide what an Agent should care for
seenzus uses Place for a physical location. A home, studio, office, or shop is a Place. Home is one Place type. One World may contain several Places, and Places of the same type may belong to different Worlds.
A person’s home and studio can share one World when the same Agent cares for them and uses the same environmental memory and Rules. Their parents’ home may need its own members and long-term understanding, so it belongs in another World. A name or distance between locations cannot make that decision for the owner.
Adding a Place and creating a World are separate actions. Adding a Place extends the same understanding to another location. Creating a World starts an independent Agent relationship with its own members and environmental memory. A new World may remain empty until its owner adds the first Place. The system does not prebuild a Home or guess which home matters most.
One World shares one body of environmental understanding
Each World has its own Agent and Membership boundary. Its place structure, environmental memory, and Rules belong there as well. When a person enters another World, the Agent reads a different scope of reality. A filter on the current device list would not account for that change.
The name must stay consistent inside and outside the product. We considered using World in the interface while keeping Account in the domain model. Every discussion about membership or memory ownership would then begin by translating one name into the other. Tool contracts would carry the same ambiguity into code.
seenzus now uses World as the only name. Product copy, the domain model, Agent prompts, and tool contracts all have to migrate, and old persistence identifiers need a safe transition. We accept that cost because an Agent that keeps memory and can reach physical devices needs an ownership boundary that does not depend on guessing from nearby context.
Entering the same World does not mean sharing everything
A World owns the environmental understanding built in common. Personal memory still follows the User. “This living room usually uses warm light at night” depends on a particular place and stays with its World. “I prefer 26°C” may remain useful when that person enters another authorized World, so it stays private to them.
Membership may also narrow what a person can see. It brings a User into a World and can limit visibility to selected Places. A location outside that scope cannot be read simply because the Agent finds it relevant. The World remains whole even when one member sees only part of it.
Memory helps the Agent choose an appropriate response. It does not grant authority. Remembering that someone prefers 26°C does not allow the Agent to control every air conditioner. An action still depends on the current request, the World’s Rules, and explicit authorization. This separation can add a confirmation step, which is a cost we accept once an Agent can change physical devices.
People can already create, enter, and switch among multiple Worlds. Agent collaboration between Worlds has not been implemented. We are also still learning when a personal preference should be brought into another World and how the person should control that transfer.
We call it a World because an Agent needs to know which Places, shared memory, and Rules belong to the part of reality it is currently understanding. Every new capability must identify its World first, then preserve information ownership and action authority. If those answers are unclear, the capability is not ready to reach a physical device.
我们整理 seenzus 的产品层级时，先碰到一个很具体的选择。自己的住处和工作室都由本人管理，也希望同一个 Agent 记得两边的习惯。父母家同样叫「家」，成员、生活规律和授权关系却是另一套。它们该怎样分在一起？
房屋类型给不出答案。按「家」来分，自己的住处会和父母家放在一起，工作室反而被拆出去。登录账号也不够。账号能确认谁进入产品，却没有说明这个人此刻进入了哪一套共同记忆与规则。
我们最后选了 World，中文写作「世界」。多个地点是否属于同一个世界，取决于它们是否共享 Agent、环境记忆和规则。它让 Agent 知道自己该读哪一套长期理解。
房屋类型决定不了 Agent 应该照看哪里
seenzus 用 Place 表示真实地点。住处、工作室、办公室和店铺都在这一层，Home 只是地点的一种类型。一个世界可以有多个地点，同一种地点也可以出现在不同世界里。
自己的住处和工作室若由同一个 Agent 照看，共享环境记忆与规则，它们可以放进同一个世界。父母家需要独立的成员关系和长期理解，就适合另建一个世界。地点叫什么、离得多远，都不会替拥有者作出这个选择。
增加地点和创建世界因而是两个动作。增加地点会把同一份理解带到新的地方。创建世界会开始一套独立的 Agent、成员关系和环境记忆。新的世界可以先是空的，系统不会预造一个 Home，也不会从几个住处里猜出哪个更重要。
一个世界共享一套环境理解
一个世界有自己的 Agent 和成员关系。地点结构、环境记忆与规则也归到这里。进入另一个世界，它会读到另一套现实范围。当前设备列表的筛选条件解释不了这种变化。
这条边界要在产品内外保持同一个名字。我们曾考虑只在界面上使用 World，内部继续叫 Account。这样做会让每次讨论都多一次翻译。成员加入哪个对象，环境记忆写到哪里，工具按什么范围读取数据，答案明明指向同一个东西，代码和界面却各叫各的。
seenzus 因此把 World 作为唯一名称。产品文案、领域模型、Agent 提示和工具合同都要迁移，旧的持久化标识也要安全过渡。我们愿意承担这笔成本，因为一个会长期记忆并接触现实设备的 Agent，需要一条不靠上下文猜测的归属边界。
进入同一个世界也不会共享一切
世界收纳共同形成的环境理解，个人记忆仍然跟着用户。「这个客厅晚上常用暖光」依赖具体地点，应该留在当前世界。「我喜欢 26°C」换到另一个获得授权的世界仍可能成立，应该留给这个人自己。
成员的可见范围也可以更小。成员关系让一个人进入世界，还可以把他能看到的内容限制在部分地点。看不到的地方不会因为 Agent 觉得相关就被读进来，世界本身也不会因此被拆成几个更小的世界。
记忆只帮助 Agent 判断怎样做。行动还要服从当前请求、规则与明确授权。它记住某个人喜欢 26°C，并不代表从此可以控制所有空调。现实设备已经接上以后，这些区分会让一些流程多一次确认，我们愿意保留这点摩擦。
今天，用户已经可以创建、进入和切换多个世界。不同世界的 Agent 还不能协作，个人偏好何时应该被带入另一个世界，也需要继续从真实使用里学习。
我们把它叫作「世界」，因为一个 Agent 需要知道哪些地点、共同记忆和规则属于自己正在理解的这一块现实。今后每增加一项能力，我们都会先确认它进入了哪个世界，再检查信息归属和行动授权。答不清这些问题，能力就还不该接进现实设备。
