Why shared context keeps getting reinvented
Most multi-agent systems that need to share context start with a vector store. It is the path of least resistance: embed what each agent knows, retrieve by similarity, and let the model sort out the rest. This works until two agents need to act on the same fact.
A vector store shares recall, not state. Retrieval returns a ranked list of chunks that look relevant to a query; it does not return a set of propositions that the system has committed to. Two agents can retrieve overlapping context and still hold incompatible beliefs indefinitely, because nothing in the store represents the contradiction. One agent asserts that a deployment target is staging; another asserts it is production. Both assertions sit in the index. Neither is marked as superseded. The next retrieval may surface either, or both, depending on embedding distance and chunk boundaries.
The failure mode is not that retrieval is imprecise. It is that retrieval has no notion of agreement. There is no object in the store that says this is what the system currently holds to be true, and no operation that says this new claim conflicts with that one.
Graphs address exactly this gap. A knowledge graph makes relations explicit: nodes for entities, edges for claims, and a schema that constrains which relations are meaningful. An edge is a proposition that can be owned, versioned, contradicted, and retired. That is what a multi-agent system needs in order to reason about agreement rather than merely retrieve similar text.
The proposal is sound. The operational questions are not resolved, and they are the ones that determine whether a shared graph is useful or a liability. Recent coverage of graph-based agent memory tends to focus on the storage layer — which database, which embedding model, which traversal. The harder questions are about authority and conflict: which agent may write which edge, and what happens when two agents write edges that cannot both be true.
Write authority: every edge needs an owner
An unattributed write is how a shared graph becomes a rumour mill. If any agent can assert any edge, the graph accumulates claims with no provenance, and downstream agents have no basis for deciding which to trust. The failure is quiet: the graph stays syntactically valid while becoming semantically unreliable.
The fix is to make write authority explicit. Every edge type in the schema should carry a policy that states which agent, acting under which task, may assert it. A schema fragment might look like this:
edge_types:
- name: service_owns_database
subject: service
object: database
writers:
- agent: inventory-agent
task: reconcile-service-topology
cardinality: many-to-many
conflict_policy: quarantine
- name: deployment_target
subject: service
object: environment
writers:
- agent: release-agent
task: promote-release
cardinality: one-to-one
conflict_policy: last-write-wins-with-timestamp
The important design choice is that authority lives in the schema, not in an agent's prompt. Prompt-level rules are advisory. A model that has been asked to only write edges it is confident about will still write an edge when the context suggests it should, and there is no mechanism to reject the write. Schema-level policy is enforced by the write path: an assertion that does not match a declared writer for that edge type is rejected before it reaches the graph.
This does not require a central authority for every write. It requires that authority be declared and checkable. An agent can be granted a broad write scope for a task, but the grant is a record, not an instruction in a system prompt.
Conflict resolution: contradictory edges are normal
Two agents asserting contradictory edges is a normal event, not an error. Agents operate on partial views, at different times, with different evidence. A graph that treats contradiction as an exception will either halt or silently overwrite, and both are wrong.
Precedence has to be decided in advance, per edge type. Three workable options:
- Last-write-wins with timestamps. Simple and predictable, but it privileges recency over evidence. An agent that writes a stale belief later than a better-informed one wins by accident.
- Confidence-weighted merge. Each assertion carries a confidence and a source. The merge rule combines them. This is more expressive, but it requires that confidence be calibrated, and an uncalibrated confidence score is just a number that makes the merge look principled.
- Quarantine until a resolver runs. The conflicting edges are held out of the readable graph and a resolution step — a dedicated agent, a human review, or a deterministic rule — decides which survives.
For facts that other agents will act on, quarantine is usually correct. The cost is latency: the graph is temporarily incomplete for that edge, and any agent that needs the fact must wait or proceed with an explicit unknown. That is a real trade-off. Last-write-wins keeps the graph continuously readable at the cost of occasionally propagating a wrong belief. Quarantine keeps the graph trustworthy at the cost of availability. The choice should follow the consequence of acting on a wrong edge, 
a/server-rack-closeup-5ed2bb-8c3175.jpg)
Quarantine also needs an exit condition. A conflict that is never resolved is a permanent hole. The resolver should be a defined step with a defined trigger — a scheduled reconciliation, a threshold on how many downstream reads are blocked, or an escalation when the conflict persists across a run boundary.
Read consistency for downstream steps
An agent that reads the graph mid-run needs a snapshot, not a live view. If the graph changes between two reads within the same agent trajectory, the trajectory is not reproducible: the agent's decisions depend on a state that no longer exists and cannot be reconstructed.
The mechanism is graph versioning. Each write advances a version counter, and a read is served against a specific version. The run records the version it read from in its trajectory, alongside the tool calls and the model outputs. Replaying the run against the same version yields the same inputs, which is the minimum requirement for debugging a multi-agent failure.
This interacts with quarantine. A quarantined edge is absent from the snapshot, so an agent reading that version sees the fact as unknown rather than as contested. Whether that is acceptable depends on whether the agent can proceed with an unknown. If it cannot, the run should block on resolution rather than read a version that omits a fact it needs.
Versioning also makes retention tractable. Stale edges are a retention policy question with the same shape as memory retention: how long does an edge remain readable, and what triggers its retirement? An edge that has been superseded is not deleted immediately — it may be needed to explain a past run. The practical rule is to retire edges from the current readable version while keeping them addressable by version for audit. Garbage collection then operates on versions, not on individual edges, which keeps the audit trail coherent.
What this implies for design
A shared knowledge graph for a multi-agent system is not a storage choice. It is a set of policies about authority, conflict, and consistency that happen to be expressed in a graph. The storage layer is the easy part.
The design work is in the schema: which edge types exist, who may write them, what happens when two writers disagree, and which version a reader sees. Those decisions determine whether the graph is a shared state that agents can reason about or a shared rumour mill that agents retrieve from.
The honest trade-off is that a policy-governed graph is slower to write to and slower to read from than a vector store. Writes are checked against authority, conflicts may quarantine, and reads are pinned to versions. That overhead buys reproducibility and a defensible notion of agreement. For systems where agents act on shared facts, it is usually the right trade. For systems where agents only need to recall similar text, it is unnecessary.