Blog

Shared memory is not shared access: scopes, sources and the current answer

A shared memory layer is only useful if every answer is scoped to the person asking, traceable to a source, and current. Here is what to check before you trust one.

· 5 min read

Shared memory should not mean everyone sees everything. A useful team memory gives each agent the facts its teammate is allowed to see, shows where every fact came from, and returns the current answer instead of an old one. If a tool cannot do all three, it is a shared folder with a search box.

This guide covers each of the three, why they fail in practice, and how to test a tool before your team depends on it. For the basics, start with what shared memory for AI agents is.

Why "shared" is the risky word

The point of shared memory is that what one person learns helps everyone. The same property is the risk. A call with a customer, a private email about a hiring decision and a board update can all end up in one store. Once an agent can search that store, the question is not "can it find things" but "whose things can it find, and for whom".

Three problems show up again and again.

  1. Wrong audience. An agent answers with something its user was never meant to see.
  2. No receipts. An agent states a fact and nobody can check it.
  3. Stale answers. An agent states something that was true last month.

Scope: the agent sees what its person can see

The safest model is simple: every agent acts as a specific teammate, and it sees only what that teammate can see. Not what the team can see, and not what an admin can see.

Ask any tool these questions:

  • When my agent searches, whose permissions apply, mine or a shared service account?
  • If a teammate's private email is imported, can my agent read it, or only facts drawn from it?
  • If someone leaves a project, does their agent lose access too?

Nysa works this way. Every agent is signed in as its teammate over MCP, and each agent sees only what that teammate can see. Raw email stays private to its owner; the team gets only the facts drawn from it. On the Claude connection page, the promise is stated plainly: Claude sees only what your Nysa account can already see.

Sources: every fact needs a receipt

A fact without a source is a rumor. "The customer wants a Q4 start" might be a direct quote from a call, or an agent's guess from a vague email. You cannot tell unless the fact carries its evidence.

Look for three things on every fact:

  • The quote or the passage it came from.
  • The date, so you know how old it is.
  • The origin: which meeting, email or calendar event.

In Nysa, every fact carries its quote, date and source. That lets a person, or another agent, check a claim in seconds instead of trusting it. Sources also help with scope: if you know where a fact came from, you can reason about who should see it.

Teams that run self-hosted memory layers often report the opposite problem. Public issue trackers include reports of memory tools where compressed context drops the fact identifiers needed to inspect an answer, for example in a report on context packs.[1] Once provenance is lost, the agent still sounds confident, and you have no way to audit it.

The current answer: old facts should not win

People change their minds. Priorities change, owners change, a deal moves from "Q4" to "next year". A memory that keeps adding facts without ever retiring old ones will eventually hand an agent two answers that disagree.

Users of self-hosted memory tools commonly report variations of this. Deleted or superseded facts can linger in summaries, and contradictions can leave incompatible claims both looking current. A public example is a report where deleted facts stayed retrievable from summaries.[2] These are common problems with memory layers in general, not a verdict on any one project.

What to look for:

  • Dates on facts, so an agent can prefer the newer one.
  • A way to correct a fact, not only add another.
  • A visible source for the fact that is treated as current.

On Nysa, agents can both read and write, including adding or correcting facts. Because every fact keeps its source and date, a correction is visible instead of silent. We do not claim that memory can never be wrong. We claim you can always see why it says what it says.

A 10-minute test before you commit

Run this with any tool, including ours.

  1. Scope test. Have two teammates connect their agents. Give one a private email thread. Ask the other agent about it. It should see at most facts, never the raw email.
  2. Receipt test. Ask for a fact about a customer. Check that it shows a quote, a date and a source you can open.
  3. Change test. Correct one fact, then ask again from a second teammate's agent. The answer should reflect the correction, and the old version should not come back.
  4. Gap test. Ask about something that was never discussed. A good tool says it does not know.

If a tool fails the scope test, stop there. The other tests do not matter.

How this fits together

Scope decides who can ask. Sources decide whether the answer can be trusted. Dates and corrections decide whether it is still true. Skip any one and the memory becomes something people work around.

If you are choosing between approaches, see saved is not searchable for the retrieval side, and same company context for every agent for how one brain serves several agents. To try it, connect Claude.

FAQ

Is a shared brain a privacy risk for private email?

It does not have to be. The safe design keeps raw email visible only to its owner and shares only the facts drawn from it, each with a source. Nysa works this way. Check any tool for this before connecting a mailbox.

Who decides what an agent can see?

The person the agent acts for. In Nysa, each agent is signed in as its teammate and sees only what that teammate can see, so there is no separate permission list for agents to maintain.

Can an agent fix a wrong fact?

Yes. In Nysa, agents can write to the brain as well as read from it, including adding or correcting facts. Because facts keep their source and date, you can see what changed and why.

Sources

  1. GBrain GitHub issue 6146, https://github.com/garrytan/gbrain/issues/6146, checked Oct 6 2026. ↩
  2. Graphiti GitHub issue 1837, https://github.com/getzep/graphiti/issues/1837, checked Oct 6 2026. ↩

Give every agent the whole story.

We're onboarding a small group of teams.

Request early access