Each memory entry gains an explicit scope — personal, project, team, tenant. Recall respects the scope of who's asking. A teammate searching your shared project namespace sees what's shared; your personal notes stay personal. The platform enforces the boundary, the customer doesn't.
Next patch
Today, every memory entry lives in a single tenant namespace — and that's the whole boundary. You can use the platform alone, or you can use it with your team, but mixing personal notes into a shared project means trusting that nothing accidentally gets pulled into the wrong answer. Most customers solve this with a habit: keep personal stuff out of the shared workspace.
The next 5.0.x patch turns that habit into a property of the data. Every entry written to memory carries one of four scopes:
Recall fan-out — whether triggered by a user query, an agentic step, or the dream engine harvesting completed sessions — filters by the scope of the requester. A teammate's query never reaches your personal layer; a project member's query reaches the project layer but not other projects.
The change is small in the UI — a scope selector on the memory pin, a badge in the retention preview, a filter on the knowledge-base browser. But the consequence is larger: shared workspaces stop requiring careful self-policing.
The same property extends to the dream engine. When the platform's background process distils completed sessions into long-term memory, the resulting entries inherit the scope of the originating session. A personal conversation produces personal-scope dream entries. A project conversation produces project-scope entries. The scope boundary doesn't leak through the distillation step.
This page updates as each piece lands. The release notes are the formal cut.
For the rest of the memory work landing in 5.0.x, see continuous learning loop and per-token memory recall. For the full 5.0.x roadmap, see what's next in 5.0.x. For how the broader platform handles your data today, see your data.