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."

We built SquidHub around that observation. This is an honest account of what shared memory means here, how it works at a high level, where the security boundary actually sits, and why a tool that forgets between sessions quietly loses the people it was supposed to help.

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.

Where the brain comes from

Shared memory is orthogonal to which model you run. A squid's reasoning runs on Anthropic, OpenAI, xAI, or Google Gemini — on your own key, or on the managed SquidHub AI tier, metered in "ink" and free during the beta. The memory is yours and lives in your workspace regardless of which brain answers in a given room. If you want to mix models in one room, that is by design; we cover it in bring your own key.

Frequently asked questions

Is room memory shared with everyone in the room

Yes. Per-room memory is a shared object: every member can rely on it, and every squid in the room reads it on each turn. It is scoped to the room, not to one person's private history, and not to the whole workspace.

Can a guest change what the room remembers

No. Guests can post messages but cannot write room memory or accept a memory suggestion — those actions are refused at the server. In multi-party rooms a squid proposes; a non-guest member confirms. The human stays the trust gate.

Is shared memory end-to-end encrypted

No. It is encrypted at rest with AES-256-GCM, which protects against database dumps, stolen backups, and read-only browsing of storage. It is not E2EE, because a hosted service that runs the AI must process plaintext to answer. We do not train on your content, and our AI provider operates under a zero-retention agreement. Details are on the security page and in our privacy commitments.

Does a new teammate get the full context when they join a room

Yes. Joining a room means joining its accumulated memory and history, so a new hire can onboard by reading and questioning the room rather than waiting for a hand-written summary.

What happens to the memory if we delete a room

Room deletion removes the room's messages, members, and shared memory, and unlinks its files from the volume — the content is gone from disk, not just hidden. Account deletion is permanent and broader. See the trust center for the full deletion model.

The retention point, stated once more

Teams do not churn because a model gave a slightly worse answer. They churn because the tool forgot what they had built together, and starting over felt like work. Persistent shared memory is the unglamorous feature that removes that friction — the reason a room is still worth opening a month later.

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. Questions about the security boundary above are welcome at hello@squidhub.ai.

— SquidHub Team