Who actually has team AI memory? A dated comparison

Ask one question and every vendor in this market sorts itself: can memory that one person accumulates be read by their colleague? Almost universally the answer is no, and — this is the part that changed recently — the vendors now say so in their own documentation rather than leaving us to infer it. Team AI memory is memory that one person accumulates and a colleague can read; as of August 2026 nearly every major vendor ships per-user memory instead, and says so in its own documentation.

This is a dated comparison, not an evaluation. Every row below cites a primary source as it stood in August 2026, because the honest answer to "who has team memory" changes and a post that does not date itself is useless six weeks later. If you want the "which of these should I actually pick" version, that is our comparison of AI memory tools, and it covers a different question.

The one question that sorts every vendor

Memory marketing conflates two products that behave nothing alike.

The first is per-user memory: the assistant notices you prefer pytest, that you are working in the payments service, that you asked it to stop suggesting classes. It carries that between your sessions. It makes you faster. Every serious vendor now ships this and most ship it well.

The second is team memory: the reasoning one engineer accumulates becomes readable by the next engineer. Not the chat history — the conclusions. Why this queue is at-least-once. Which auth path is deprecated. What was tried in March and abandoned.

Only the second one addresses convention drift, which is the failure that actually costs a team money: forty engineers' agents each working from a private, unreviewed notion of the house style, producing forty slightly different answers to the same question. Per-user memory does not reduce drift. It gives every developer a private, growing, unauditable store, which is drift with better ergonomics. We argued that separately in why personal AI memory is free and team memory is the hard part; this post is the evidence for it.

So the test for each vendor is deliberately narrow. Not "is the memory good". Just: can a named colleague read what my agent learned?

OpenAI: no, and they wrote it down

OpenAI's Memory FAQ for the Business plan answers the question directly. Asked whether memories can be shared with other members of a workspace, the documentation says no — memories are tied to each individual account and are not transferable to other users, even within the same Business workspace.

That sentence is worth more than any competitive analysis we could write. It is unambiguous, it is on a paid team plan, and it is the vendor's own words.

The release history corroborates it rather than contradicting it. The "Memory improvements" item in the ChatGPT Enterprise and Edu release notes dated 2026-06-25 is per-user personalisation, not pooling. Group chats — the feature people most often assumed would become the shared-context surface — were retired on 2026-07-09. And the widely rumoured "workspace memory v2" resolved negative; it did not ship.

Read those three together and the picture is not a company that has not got round to team memory. It is a company that has repeatedly shipped in the other direction, deliberately. Per-account memory is a cleaner privacy story, a cleaner support story, and a cleaner data-retention story. It is a reasonable product decision. It is also not the thing your exec was describing.

Anthropic: per-user and project-scoped

Anthropic's memory is per-user, with project scoping as the organising unit. Projects are genuinely useful here — a project bounds what a conversation draws on, which is closer to a team-shaped primitive than a global per-account blob.

But the scope that matters is still the account. Two engineers on the same project do not read each other's accumulated memory. What they can share is what somebody deliberately put in the project — files, instructions, uploaded documents. That is authored context, and it is a real answer to consistency. It is not accumulated context, and the distinction is the whole subject of this post. We break down the specific trade against a shared workspace in Contextium vs Claude Projects.

Microsoft Copilot: user-level by design

Copilot Memory holds user-level preferences. Copilot Studio gives each user a separate memory store. Both are per-user, and in Microsoft's case the design rationale is visible: Copilot already reaches tenant-wide content through Graph, so the memory layer is not being asked to carry organisational knowledge. The organisation's knowledge is supposed to be in SharePoint.

Which is fine, and also why it does not solve this. A document in SharePoint is not a convention an agent applies. The gap between "the tenant has a document about it" and "every agent on the team behaves accordingly" is exactly the gap a shared context layer exists to close.

Cursor Team Rules: shared, but authored

Cursor Team Rules, shipped 2025-10-31, are the closest thing to team context in a mainstream coding tool. They are shared across a team and admin-authored.

Authored is the operative word, and it cuts both ways. Authored means reviewed — somebody decided, and there is an owner. That is strictly better than agent-invented policy, and it is the property we argue hardest for. But authored also means the rule only exists if a human sat down and wrote it, which means Team Rules capture the standards a team already knew it had, not the ones it discovers at 2am during an incident.

The other constraint is reach: Team Rules apply inside Cursor. If your team also runs Claude Code and Copilot — which by our ICP definition it does — you are back to maintaining the same standards in three places. That is the multi-tool problem we walked through in The CLAUDE.md problem.

TencentDB Agent Memory: the closest thing to a yes

The most credible answer in this comparison is open source. TencentDB Agent Memory ships team-level sharing with four visibility scopes — private, team, restricted and agent — defaults to private, and is MIT-licensed. It has 15,000-plus GitHub stars.

We should be straight about this: private-by-default with explicit team visibility, under a permissive licence, is a better default than most commercial products in this table. Anyone claiming to be first to governed sharing of agent memory is wrong, and we are not going to make that claim.

Its limits are operational rather than conceptual, and they are the things that decide whether a platform team can actually run it. It is self-hosted only, so the operational burden is yours. It is repo and conversation centric, with no obvious path for context that is not a repo artefact — a runbook, a decision record, an architecture rationale that lives in nobody's git history. Injection is proxy-based, which means routing your agent traffic through their process. And there is no documented export path out, which by the lock-in rubric is the row that should worry a platform team most: a store you cannot export is a store you cannot leave.

If you are self-hosting, comfortable with a proxy in the path, and your context is genuinely repo-shaped, it is a real option and you should evaluate it. We would rather say that plainly than pretend the open-source answer is not good.

The scorecard

One column, one question: can memory one person accumulates be read by a named colleague? Scored as documented in August 2026.

Vendor	Accumulated memory shared across a team?	Documented as of
OpenAI (Business)	No — tied to each individual account, not transferable within a Business workspace	Memory FAQ, Business version
Anthropic	No — per-user; projects share authored context only	Project scoping
Copilot Memory	No — user-level preferences	Product docs
Copilot Studio	No — separate memory store per user	Product docs
Cursor Team Rules	Shared but authored, not accumulated; Cursor only	Changelog, 2025-10-31
TencentDB Agent Memory	Yes — private/team/restricted/agent, private by default, MIT	Repository
Contextium	Yes — workspace-scoped, versioned, read by every MCP-connected tool	This site

Two yeses, one of them free. That is the honest state of the market in August 2026, and it is a much smaller field than the marketing implies.

Why almost nobody ships this

It is tempting to read the table as an industry oversight. It is not. Per-user memory is the easier product in four distinct ways, and understanding why tells you what to demand.

Consent is simpler. If memory never leaves an account, you never have to ask whether a developer's half-formed reasoning should be visible to their manager. Pooling raises a question every vendor would rather not answer.

Deletion is simpler. Per-account memory has one owner and one delete path. The moment memory is shared, deletion has to propagate to derived copies and to every consumer — the hardest of the five tests in our lock-in rubric, and the one with a regulatory deadline attached.

Attribution is simpler. Shared context that nobody owns rots. Making it work requires authorship, review and versioning — which is governance machinery, not a memory feature. Vendors selling an assistant do not want to ship a review workflow.

And per-user memory demos better. "It remembered your preference" is a thirty-second demo. "Your colleague's agent now applies the convention you wrote on Tuesday" needs two accounts and a story.

None of that makes per-user memory wrong. It makes it a different product from the one a platform team is shopping for, and the confusion is largely linguistic: both get called memory.

What to ask a vendor before you buy

Four questions, in order of how quickly they end the conversation.

Can memory one person accumulates be read by a named colleague? If the answer needs a paragraph, it is no.

Who authored this item, and when? Context without an author is context nobody maintains. This is the question that separates a governed layer from a shared folder.

Can I export all of it in a form I can re-load somewhere else? Not a transcript — the working state, with references that still resolve.

Can I delete one item and have it disappear from every consumer without a re-sync step? This is where N tool-local copies fail and a single shared source does not: revoke once and the next retrieval simply does not return it.

We built Contextium around those four because we kept failing them ourselves with per-repo files. Our own standards live in one workspace, versioned, with an author on every change, and every agent an engineer opens — Claude Code, Cursor, whatever it is this week — reads them as shared AI context over MCP. When we changed our API error-handling rule it was one edit with a diff and an author, and the next session every agent picked it up. Under the old arrangement it was four pull requests against four files, two of which drifted for a month because nothing fails a build when a convention file goes stale.

One honest caveat on the whole exercise: none of this is a claim about accuracy. There is no evidence that shared context makes agents measurably better at their task, and we do not claim it. What governed shared context buys is that it is cheaper to run than the same standards re-sent by nine engineers on every turn, consistent across every tool on the team, and auditable. Those three are enough, and they are the three per-user memory cannot give you. The mechanics of how that workspace is structured are worth ten minutes if you are choosing between the two yeses in the table — and if you are weighing the managed option against a self-hosted memory store, Contextium vs mem0 covers the same ground for a closer competitor.

The table will change. Ask for the date on any answer you are given, including this one.