Persistent shared memory for AI teams

Nobody opens a procurement call asking for "persistent shared memory." It is not a line item, and it rarely shows up on a feature comparison grid. But it is the single thing that decides whether a team is still using an AI tool thirty days after they started. When the context survives, people come back. When it resets, they drift away and call it "we just didn't find a use for it."

Shared memory is also a loaded gun. A block of text that every squid reads on every turn is the single most leveraged thing in a room · which is why in SquidHub no squid gets to write it unsupervised. In a multi-party room a squid can only file a suggestion; a human member has to accept it before it becomes what the room knows. That trust gate is the design decision this post is really about.

The unit teams want is the working context

If you listen to how people describe their frustration, a pattern repeats. They say "I want to share the project, not the chats." The thing they are trying to hand to a teammate is not one conversation and not a read-only link. It is the working context: the instructions, the files, the decisions already argued through, and the accumulated understanding of what this effort is and where it stands.

Most AI products cannot share that unit, because they were never built to hold it as a shared object. A chat is private to the person who started it. "Memory," where it exists, is personal · it follows the individual, not the work. So the project lives in one head and one account, and everyone else gets a curated export at best.

That is the same gap we describe in multiplayer mode for AI: the 1:1 frame is the wrong shape for work that is fundamentally shared. Memory is where that abstract complaint becomes concrete and expensive.

How per-room memory works in SquidHub

In SquidHub the room is the unit of work. A room holds humans and their squids · AI agents with a name, a persona, and a job. Crucially, the room also holds its own memory: a persistent block of context that everyone in the room shares, and that every squid in the room reads on every turn.

The practical effect is simple. Decisions, constraints, and accumulated facts do not live in one person's chat history. They live in the room. When a teammate opens it tomorrow, the squids already know what was settled yesterday · the naming convention you agreed on, the customer you cannot name in public, the approach you already ruled out and why. Nobody re-explains. Nobody redoes the research someone else finished last week.

Two consequences fall out of this that teams feel immediately:

• A teammate picks up where another left off. The room is the handoff. There is no "let me forward you the thread" and no lossy summary · the working context is the shared object, and a squid in the room can answer from it directly.
• A new hire onboards through the room's history. Joining a room means joining its accumulated memory. Instead of reading a stale wiki, a new person reads · and asks the room's squids about · the actual reasoning that produced the current state.

This is also what makes multi-agent work coherent rather than chaotic. When several squids share one memory, they argue from the same facts instead of each maintaining a private, divergent picture. We go deeper on that in multi-agent collaboration.

The honest security boundary

Shared memory raises a fair question the moment you propose it: who sees whose data when a room has shared context? A team lead is right to ask, and the answer should be precise, not reassuring noise.

Here is the boundary, stated plainly.

Encrypted at rest, not end-to-end

Room memory, message text, squid personas, and uploaded files are encrypted at rest with AES-256-GCM before they reach the database or the file volume. A database dump, a stolen backup, or someone browsing the storage read-only sees ciphertext, not your context.

We are deliberate about what we do not claim. SquidHub is not end-to-end encrypted, and we will not market it as if it were. A hosted service that runs the AI for you must hold the key to do its job, and a squid cannot answer without the provider seeing the conversation in plaintext, transiently. We address that contractually · zero-retention, and no training on your content · not with a cryptographic promise we could not keep. The full threat model, including what at-rest encryption does and does not cover, is on our security page.

Who sees what, inside a workspace

Memory is scoped to the room, and rooms are scoped to a workspace. Membership is the boundary: a room's shared memory is visible to that room's members, and nothing about belonging to one room grants you the rest of the workspace · its other rooms, its squids, or its member roster.

Single-channel guests make this concrete. A guest is added to specific rooms and sees only those. There is no channel discovery, no member directory beyond the rooms they are in, and they cannot create rooms in the workspace. This is enforced on the server, not just hidden in the UI.

Guests can talk, but they can't quietly rewrite memory

Because room memory is read by every squid on every turn, it is also a place where a single planted line could do outsized damage if anyone could write it freely. So we gate writes. In a multi-party room a squid does not silently edit the shared memory · it files a suggestion that a non-guest member must accept before it enters any prompt. A guest can post messages, but cannot write room memory or accept a suggestion; that path returns a hard refusal at the server. The human is the trust gate, and the shared block is bounded and attributable, so an accepted-but-wrong fact is visible and editable rather than buried.

That is the difference between "shared context" as a marketing phrase and shared context built to survive a real, multi-party room.

Why ephemeral group chats lose the team

It is worth being specific and fair about the alternatives, because the contrast is the whole argument.

ChatGPT group chats let several people talk to a model together, which is genuinely useful. But personal memory is not shared into the group · the group conversation maintains its own boundary, and participants' individual memories stay individual. The collaboration is real-time; the accumulated, shared context is not the unit you can hand off.

Claude Projects and Claude Code give a project shelf and, increasingly, memory that accumulates as you work. But that memory is individual by default · your teammate's sessions and your debugging context do not transfer at the agent level, which is exactly why "shared team memory" is one of the most-requested gaps, with third-party tools springing up to bridge it. A shared instructions file helps, but a static file is not the same as living, accumulated context that everyone reads.

This is not a knock on those products. It is a statement about shape. A tool optimized for one person plus a model will treat memory as a personal convenience. A tool built for a room treats memory as a shared asset of the work itself. The first is more convenient on day one. The second is the one people are still using on day thirty, because the context they built together did not evaporate when they closed the tab.

If you want to see it hold context across a session and a teammate, book a demo or open a room. The longer argument for why work belongs in rooms at all is in the multiplayer thesis; which brain a squid runs on is a separate, orthogonal choice we cover in bring your own key.

- SquidHub Team