Most agent-memory systems are optimized around one question:
Can the system retrieve the right information?
That is necessary, but it is not enough for a shared assistant.
A hospital assistant may remember a medication change correctly and still fail by revealing it to a family member who only has access to appointment logistics. An office assistant may retrieve the right project note and still fail by giving it to a contractor outside the project. A school assistant may remember a student’s counselling record and still fail by exposing it to someone whose role does not include it.
The fact can be correct.
The answer can still be wrong.
GateMem, a benchmark published in June 2026, measures that distinction. Instead of treating memory as a private cache for one user, it evaluates shared-memory agents used by multiple people with different roles, relationships, and authority.
That is much closer to the systems companies are trying to deploy.
The Same Memory Has Different Answers
Most memory research assumes a person talking to their own assistant.
The person writes into memory. The same person asks for it later. Success means the system remembers enough to be useful.
Institutional memory does not work that way.
In a hospital, a patient, clinician, pharmacist, ward clerk, family member, and external specialist may all interact with the same assistant. They do not have the same rights. The boundary can depend on role, assignment, consent, purpose, and the current state of care.
In an office, an employee may be able to retrieve project milestones but not an HR investigation. A manager may see compensation information for their team but not for another department. A contractor may see the technical specification they are implementing but not the commercial negotiation behind it.
This is what GateMem calls the multi-principal setting.
Memory is no longer one person’s history. It is shared institutional state.
Once that shift happens, relevance is only one filter. The system also needs to ask:
Who is requesting this?
What role are they acting in now?
Which relationship gives them access?
Is the request within that scope?
Was access delegated, limited, or revoked?
Has the information been deleted?
A vector similarity score cannot answer those questions by itself.
GateMem Tests Three Things Together
GateMem contains 91 long-form episodes and 2,218 hidden checkpoints across medical, office, education, and household scenarios. It evaluates seven memory baselines with six backbone language models.
The benchmark tests three dimensions.
Utility: Can the assistant answer a legitimate request with the current information?
Access control: Does it withhold protected information from a requester who is unauthorized or asking beyond their scope?
Active forgetting: After a deletion request, does the system avoid recovering, confirming, or reconstructing the deleted fact in a later conversation?
The last one needs precision.
GateMem does not certify that every physical copy disappeared from a database, cache, vector index, summary, or model weight. It tests the behaviour visible through the assistant interface. After deletion, can the assistant still reveal the information directly, confirm a user’s guess, or reconstruct it indirectly?
That is a practical deployment test.
A system can claim that a memory was deleted while still leaking it through a later answer. From the user’s perspective, that is not forgetting.
Governance Is Not a Bonus Column
The most useful design choice in GateMem is how the main score is constructed.
Utility is multiplied by access safety and forgetting safety.
The dimensions are not simply averaged.
That matters. An agent with excellent recall and no working deletion should not receive a respectable overall score because good answers compensated for a privacy failure. A system that retrieves almost everything for almost everyone is not a strong institutional memory. It is a disclosure engine with good recall.
The multiplicative shape treats governance as a gate.
Anything close to zero pulls the result toward zero.
That is closer to how organizations experience the risk. A board does not average a serious data breach against a productive quarter and declare the system acceptable. A hospital does not offset an unauthorized disclosure with the number of correct appointment summaries generated elsewhere.
Capability does not compensate for missing authority.
Current Memory Systems Do Not Solve All Three
The GateMem authors report that no tested method simultaneously achieved strong utility, robust access control, and reliable forgetting.
That result should slow down the common assumption that adding a memory product turns an assistant into an institutional system.
The tested approaches included long-context prompting, retrieval methods, and external-memory systems such as A-Mem, Mem0, and ReMeM variants. Different designs failed differently.
Some retrieved useful information while leaking protected facts. Some improved safety by refusing too much, which made them less useful to authorized users. Some appeared to delete a fact but later confirmed or recovered it when asked another way.
This is the hard part of governance.
A system that refuses everything is safe but useless. A system that answers everything is useful but unsafe. The requirement is to answer the authorized person, with the current allowed information, while resisting overreach and honoring deletion over time.
That cannot be reduced to a retrieval setting.
Storing Nothing Can Beat Storing Badly
One of the more uncomfortable findings is that long-context prompting often produced the strongest governance tradeoff, although at substantial token cost.
The crude approach can be easier to reason about. Instead of maintaining a permanent external memory, the system receives the relevant interaction history again for the current request. There is less hidden state to update, synchronize, expire, and delete.
But full history is not automatically safe. GateMem also found that long context can expose protected or deleted information because the evidence is still present in the prompt. The approach performed well as a tradeoff, not as a complete solution.
And it is expensive.
Each interaction may require the model to read the history again. The organization pays repeatedly for context it already owns. As histories grow, cost and latency grow with them.
That creates an architectural tension.
External memory can reduce token use, but it introduces retrieval, authorization, deletion, and stale-state failure modes. Long context can simplify state management, but it can increase cost and still expose information that should be withheld.
The safest design may not be the cheapest.
The cheapest design may not be governable.
Forgetting Is an Operation, Not a Sentiment
Many systems talk about forgetting as if it were a model preference.
The user asks the assistant to forget a fact. The assistant acknowledges the request. The interface moves on.
A governed system needs more.
Which memory object was affected?
Which derived summary contains the same fact?
Which vector chunks or graph edges can reconstruct it?
Does an audit record need to remain even after the content is removed?
Does deletion apply to one user’s private context or to shared organizational state?
What happens when another person later asks a yes-or-no question that would confirm the deleted information?
These are data-lifecycle questions. Enterprises have spent decades building retention, lineage, legal hold, deletion, and access rules around databases and document systems. Agent memory often arrives beside those controls rather than inside them.
That is why memory should be designed as governed content, not as an invisible convenience feature.
The Memory Layer Needs Its Own Control Surface
A production memory system should make several things explicit.
Every memory object needs provenance: where it came from, who supplied it, and when.
It needs scope: personal, team, project, department, customer, or enterprise.
It needs authority: who may read it, update it, approve it, and delete it.
It needs status: current, superseded, disputed, expired, or removed.
It needs evidence: why this memory was retrieved and how it affected an answer.
And it needs tests that use different requester identities, not only different prompts.
This does not mean every stable procedure should become agentic. Deterministic policy enforcement still belongs in the control path where decisions must be precise and repeatable. The model can interpret the request and assemble context, but the authorization check, deletion state, and audit record should not depend on the model improvising the right policy each time.
AI should help navigate the memory.
It should not silently define who owns it.
Test What the Assistant Must Not Say
Teams often evaluate memory by asking whether the assistant remembers the right facts.
GateMem shows why that test is incomplete.
A shared assistant must also be tested with the wrong requester, a revoked relationship, an indirect question, a cross-customer confusion, and a request to recover something deleted earlier. Those cases reveal whether the system has memory governance or only retrieval.
The memory layer did not escape thirty years of database governance because language models are new.
It skipped that work and shipped anyway.
If your assistant is shared across a team, who on that team can it not talk about, which facts must it forget, and has anyone tested that the boundary holds after the wording changes?