Answers
A shared knowledge graph for all our agents feels like the wrong default — anything can write to it, and one project's facts end up in another's work. Is that avoidable?
It is, and the two halves of the objection need two different answers, because they are two different failures. Writability is answered by authority: writing something here does not make it a norm. What an assistant writes on its own initiative arrives as a proposal, or as context that is labelled as unsanctioned, and it stays that way until a person accepts it — at which point it becomes what the team stands behind, with their name on it. Leakage is answered by scope: the project is the boundary, it is chosen when the memory is written rather than filtered when it is read, and one project's material is not served into another. Neither answer is a property of the graph shape. A graph can carry both, or neither, which is why "shared graph" describes a storage choice and not a governance one.
Last updated September 21, 2026
Writable and authoritative are different words, and most designs use one for both
The sharpest half of the objection is that a shared writable store turns every participant into an editor of the team's truth. That is accurate, and it is what happens when the store holds exactly one class of thing. Here it holds two, and the line between them is a person's decision. What an assistant writes on its own initiative is a proposal, or — when it is verifiable, source-backed context — a finding: usable, visibly labelled, and never quotable as something the team adopted. What a person accepted is a norm: it is what gets served as being in force, and it carries who decided it. The practical consequence is the one the objection is asking for. Nothing an agent wrote can quietly become the thing another agent obeys.
The boundary is chosen when the thing is written, not filtered when it is read
The leak the objection describes — a fact true of one repository turning up in work on another — is a scoping failure, and scoping applied at read time is the version that fails. A filter over one shared pile has to be right every single time, and being wrong is asymmetric: nobody notices a fact that was correctly withheld, while a fact that escaped shows up as an assistant confidently asserting something about the wrong system. So the scope is a property of the record instead of a query parameter. A memory belongs to one project, a read is a read of that project, and "is this the right project for this" is answered by whoever writes it, at the moment they write it, when the answer is still obvious.
Currency is a third failure, and linking facts does not touch it
The word "stale" in the objection is doing separate work from the word "authority", and it survives even a graph with perfect scoping. Linking two statements about the same thing resolves identity: it tells you that the note about the payment service and the note about the billing service are about one system. It does not tell you which of the two is in force, because that is not a property of how they connect — it is a property of when each was decided and whether anything replaced it. Here each statement is written with the condition that ends it, a replacement names what it replaces, and two statements that genuinely contradict each other come back marked as a conflict rather than settled quietly by whichever one ranked higher.
What it looks like in practice
An agency runs agents across four client accounts and starts with one shared store, because the alternative looks like four sets of everything. In month two an assistant working on client A writes down that approvals go through a named person, that the cutoff is Tuesday, and that a particular tone rule applies. All of it is true, none of it was reviewed by anyone, and in a store with one class of thing it now sits beside the rules the agency itself set. In month three an assistant on client B is asked to schedule a piece of work and answers with client A's Tuesday cutoff. This is not a retrieval bug: the sentence is well formed, relevant, and about approvals, which is what was asked. Nothing in the record marks it as belonging to one account, and nothing marks it as something an assistant assumed rather than something a person set. Both marks are cheap to carry at the moment of writing and impossible to reconstruct afterwards, which is exactly why they are properties of the write and not of the query.
Questions people ask about this
- Isn't a shared graph still the right shape once you add permissions on top?
- Permissions answer who may read and write, which is a real question and not this one. Two questions remain afterwards. Whether a write becomes binding — a permitted write is still a write, and permission does not turn it into something the team decided. And whether a statement is still in force, which no access rule has an opinion about. A graph with permissions can carry both, but it has to carry them explicitly; neither arrives with the shape.
- How does an assistant know a fact belongs to another project if it never sees it?
- It does not, and that is the point. A read is a read of one project and returns that project's material; there is no cross-project ranking where the boundary sits one score away from being crossed. Where it matters, the read says plainly that the person belongs to other projects and that this is not the place to write about them — so the failure mode becomes a question asked out loud rather than a fact quietly reaching the wrong work.
- We keep facts per repository in files. Doesn't that isolate them already?
- It isolates them for as long as nothing has to be shared, and that holds until the second reader turns up — another team, another tool, the same person on a different machine. What a per-repository file does not carry is the part this objection is about: who decided that a line is binding, and whether it still is. Isolation and authority are separate properties, and a file gives you a strong version of the first and none of the second.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on why a graph that links facts does not decide which one is current, on shared memory for AI agencies and on human-sanctioned memory, and the project-scope, sanction, finding and conflict rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/a-shared-graph-with-no-authority-leaks-stale-facts