One memory, any model: switching models without losing your team’s context

Ask anyone who has switched AI models — traded one answer-writing engine for a newer one — what it cost them, and they will not talk about the subscription. They will talk about the months of context that stayed behind: the preferences taught, the project history explained, the corrections accumulated one exasperated reply at a time. Then multiply that by a team, where every member’s assistant has memorized a different partial picture of the same work. The industry calls this “memory.” It is more honestly described as vendor-shaped amnesia.

The old way: memory as lock-in

Today’s assistants remember per account, per vendor — and “vendor” here means whoever runs the assistant doing the remembering: usually the model provider’s own product, sometimes an AI workspace platform holding your memory for you. Either way, the design has three consequences, none accidental:

• Switching means starting over. The memory lives inside the vendor’s account structure, so the better model next quarter arrives ignorant of everything yours already knew. Inertia does the retention work pricing can’t.
• Teams fragment by design. Your assistant knows what you told it; your colleague’s knows what she told hers. Two AIs, one project, no shared state — and the merge happens in meetings, verbally, forever.
• The memory isn’t yours to govern. You cannot inspect it as a file, scope it to a project, or hand it to a successor. It is a behavior, not an asset.

The design CloudTop is building toward

CloudTop is the AI workspace you own, and the fix it is building toward is almost embarrassingly simple to state: make memory a place, not a vendor feature. A shared folder in the workspace holds the team’s working memory — project context, decisions, conventions, corrections — as readable, governable files. Every team member’s model reads the same folder and writes its updates back there. Because the memory belongs to the workspace:

• Any model can use it. Connect several models at once; point a new one at the folder and it is current in one read. Switching is a routing change, not a bereavement.
• The whole team’s AI stays level. When one member’s work updates the shared memory, everyone’s assistant knows it — the same mechanism that already keeps shared data live across the workspace keeps shared context live too.
• Memory is governed like everything else. It is a folder: scoped, versioned, auditable, and it stays when people leave — the same ownership logic as shared workflows.

What actually goes in the memory folder

“Shared memory” fails when it means “a folder someone dumped everything into,” so the design assumes curation with a shape. In practice a team’s memory folder converges on four small, deliberately readable artifacts: a decision log — what was decided, when, and why, one line each; a conventions file — the house style, the naming rules, the client’s non-negotiables; a corrections file — the mistakes the team never wants an assistant to repeat, written the day they happened; and a running state note that the assistants themselves maintain, summarizing where the work stands. Small matters more than complete: memory files are written to be read in one model call, which is also what keeps them legible to humans. And because memory is just a folder, it inherits every property the workspace already has — scoped access, version history, and an owner — so “what does the AI think it knows about this project?” has, for the first time, an answer you can open, read, and correct in place.

Where this stands today — the honest tense

Precision about timing is a habit here, so: the substrate for this — live, bi-directional data binding that keeps shared files current across every connected device, offline-first, with versioning — runs in CloudTop today; it is the same layer that makes every app collaborative. The multi-model connection on top of it, where several models read and update one shared team memory, is the part still ahead, arriving with the platform’s public release. We are describing a design we are shipping toward, not a feature you can click this afternoon — and when a vendor blurs that distinction, you should read the rest of their claims accordingly.

Why this decides more than convenience

Model-vendor memory is the deepest lock-in in the stack — deeper than price, deeper than integrations — because it compounds silently: every day of use makes leaving costlier. Workspace memory inverts the compounding: every day of use makes the workspace more valuable and every model more replaceable. If the workspace should be sovereign and the models interchangeable guests (the case for that), then memory is where that principle either holds or quietly dies. It holds when the memory is a folder you own.