Shared AI memory for enterprise teams

Most AI memory is personal. One person connects a tool, it learns their work, and the value leaves with them. Shared memory inverts the ownership: the company owns the memory, people are granted access to it, and access ends when employment does. That single change is what makes memory safe to buy at an organisational scale.

We build OctaMem, so read this with that in mind. What follows is how shared memory works in our product because that is the implementation we can describe precisely — but the questions it answers are the ones you should put to any vendor in this category. If a memory product cannot tell you who owns a memory after the person who created it resigns, you do not have an enterprise product.

Personal memory does not survive an org chart

An individual AI memory is a good product and a bad asset. It accumulates context that only one person can reach, bills to one person's card, and disappears from the business when that person moves on. For a solo developer that is exactly right. For a company it is a liability dressed as a feature: the more useful the memory becomes, the more damage its departure does.

Enterprises ask three questions that personal memory cannot answer. Who owns this? Who can read it? What happens when they leave? Shared memory exists to give each of those a structural answer rather than a policy one — enforced by the system, not by a rule somebody is trusted to follow.

Ownership is structural, and decided once

When a memory is created inside a funded organisation, it is stamped as the company's at that moment and permanently. It is not a setting that can be toggled later, and it is not inferred from who happens to be paying this month. The person who created it is recorded, but they are not the owner — the organisation is.

This matters more than it sounds. Ownership and billing are separate facts in a well-built system, and a product that conflates them will eventually tell you something untrue. A memory can be owned by the company and paid for through a gifted plan; a memory can be billed to a person while belonging to no organisation at all. Ask your vendor whether ownership is a column or a guess.

Note the last row. Both are decided at creation and neither can be converted afterwards. That is deliberate: a memory that could be moved from personal to company would be a route to quietly hand a business someone's private work, and a memory that could move the other way would be a route to walk out with the company's.

Access is granted, never assumed

The most common design mistake in this category is to let an organisational role imply access to content. It reads sensibly — an editor should be able to edit things — and it is wrong. An org role decides who administers the company. Whether a given person can open a given memory is a separate fact, recorded per memory.

• Admin — manages members, billing and every company memory.
• Editor — can create memories. Reaches others only where granted.
• Viewer — reaches only what is granted, read-only.
• Member — reaches only what is granted.

So being an admin does not silently open every colleague's work. An admin can grant themselves access to a company memory — that is their prerogative — but it is a recorded act with a timestamp and an actor, not an invisible capability. The difference between those two designs is the difference between an audit trail and an apology.

A private memory belonging to an employee is invisible to the company, including to its admins. That boundary is enforced at the access layer, not in the interface — hiding a button is not a security control.

What happens when someone leaves

Offboarding is where memory products are actually tested, and where most of them quietly fail. Removing someone from a company should end their reach into the company's memory completely and immediately, while leaving the company's data exactly where it is.

• Their sessions and tokens are revoked.
• Their grants are deleted — all access ends at once.
• The API key of every company memory they worked in is rotated, because a key they copied months ago is a bearer credential that a logout does not touch.
• The memory, its contents and its history stay with the company.
• Their personal memories and their account are untouched — those were never the company's.

That fourth point is the one to press a vendor on. If a memory still names the departed employee, does it still answer to them? In a correct implementation the pointer confers nothing once membership ends; access must come from a grant like anyone else's, and offboarding deleted theirs.

One plan, pooled across the team

Shared memory only works commercially if the capacity is shared too. A company subscribes once, and the memory operations and storage draw from one pool rather than per-seat allocations that strand capacity with whoever is not using it this month. Nothing counts seats — adding a colleague costs nothing until they actually do work.

The detail worth checking: the company is the customer, not the admin operating the account. The subscription, the card and the invoices belong to the organisation, so an admin leaving or handing over does not disturb billing. How pooled billing works goes through the mechanics.

Where to go next

Four companion pieces, each written for a different person in the room: how to actually share a memory for whoever runs the workspace, access control and offboarding for IT and security, pooled billing for finance, and audit logs for compliance.

Frequently asked questions