CASE 01 / COMPLIANCE
Ownership review
Knowledge: accepted entities and obligations. Memory: previous claims and analyst decisions. Context: the evidence permitted for this review.
A beginner-friendly explainer
You probably don’t need three graph databases.
Knowledge graphs, memory graphs and context graphs are usually three architectural jobs, not three procurement decisions.
Knowledge · experience · runtime context
The useful questionWhat should be trusted, what should be remembered, and what should the agent use right now?
01 / TL;DR
Three names. Three jobs.
Think of the system as an organisation that knows things, remembers what happened, then prepares a small brief for the decision in front of it.
The knowledge graph holds accepted meaning. The memory graph holds experience. The context graph holds the evidence selected for this task.
- Less accidental promotion of an AI guess into an official fact.
- Better retrieval when identity, relationships, time or provenance matter.
- A clearer path from one assistant’s memory to a governed enterprise capability.
02 / The mental model
Same connected world. Different authority.
| Role | Represents | Question |
|---|---|---|
| Knowledge graph | Governed meaning the organisation has accepted for reuse. | What do we treat as true or applicable? |
| Memory graph | Retained experience from interactions, claims, actions and outcomes. | What happened before, and what did we learn? |
| Context graph | Information selected for one task, actor, purpose and point in time. | What should this agent use right now? |
Connected doesn’t mean equivalent.
03 / The trust boundary
A graph is not automatically a source of truth.
Nodes and relationships tell us how information connects. They don’t tell us whether the organisation accepts it, whether it is current, or whether an agent may use it.
01ObservationWhat a source presented
02ClaimWhat a model extracted or inferred
03DecisionWhat a reviewer or process accepted
04Governed assertionWhat is safe to reuse
AI proposes. Systems validate. The graph records what happened.
Knowledge graphThe organisation’s accepted meaning
Institutional memory, with rules around it.
A knowledge graph can hold canonical entities, accepted definitions, approved relationships, domain rules and obligations that multiple workflows are allowed to reuse.
(:LegalEntity)-[:REGISTERED_IN]->(:Jurisdiction) (:LegalEntity)-[:HAS_BENEFICIAL_OWNER]->(:Person) (:EntityType)-[:SUBJECT_TO]->(:ComplianceObligation)
The value is not “we turned a document into a node”. The value is connecting identity, relationships, evidence and rules in a reusable form.
Memory graphExperience, not truth
Remember what happened without pretending every memory is a fact.
Memory connects episodes, observations, claims, retrievals, tool calls, decisions, actions, outcomes and feedback. It gives an agent continuity, but it must preserve uncertainty and rejection too.
Source eventWhat the agent received, what a tool returned, and what action was requested.
Derived memoryClaims, decisions and outcomes linked to canonical identities.
Negative knowledgeClaims rejected, sources superseded, or actions prohibited for a purpose.
Repeated retrieval does not turn uncertainty into truth. It just gives the uncertainty better distribution.
Context graphWhat the agent is allowed to see now
The runtime brief, not another permanent source of truth.
CURRENT CONTEXT / 01
Start with accepted meaning.
Select the canonical entity, relationship and rule that anchor the task. Don’t begin with the entire enterprise graph.
canonical identityaccepted relationshipapplicable rule
06 / How they work together
It’s a lifecycle, not a hierarchy.
Governed knowledgeAccepted meaning and rules.
Retained experienceClaims, actions and outcomes.
Context assemblyThe evidence selected for one decision.
→
→
→
task / policy / time
Most experience stays memory. Repeated, validated patterns may eventually change governed knowledge.
07 / Where this becomes useful
Use the pattern when relationships change the answer.
CASE 02 / LAB NOTEBOOK
Experiment continuity
Knowledge: approved methods and instrument definitions. Memory: prior runs, anomalies and corrections. Context: the evidence relevant to today’s experiment.
CASE 03 / SERVICE AGENT
Product support
Knowledge: product facts and safe procedures. Memory: previous troubleshooting attempts. Context: the customer’s device, symptoms and current policy.
08 / Architecture decision
Don’t graph a problem just because an agent is involved.
A profile record, transaction table, versioned document, event stream, lexical index or vector store may be the right answer.
THE ECONOMIC QUESTION
Does the improvement justify identity resolution, modelling, governance, security and reprocessing cost?
09 / Implementation guide
Build the smallest trustworthy version first.
Use the six steps below as a design review. Select a step to see its done condition.
STEP 01 / BOUNDARIES
Frame the three roles.
Write down what counts as governed knowledge, what counts as experience, and what is assembled only for the current task. Put authority and lifecycle next to every category.
Done whenA reviewer can classify any new record without guessing where it belongs.
10 / Implementation guide
Give every durable memory a reliable identity.
Link memory to canonical entities instead of creating a second, competing version of the business world.
01Stable IDWhich entity, case or run?
02SourceWhere did this come from?
03TimeWhen was it valid and recorded?
04ScopeWho, which tenant or purpose?
05LifecycleCurrent, rejected or superseded?
Keep the original source event available so derived graphs can be rebuilt when your extraction logic changes.
11 / Implementation guide
Make the write path harder than the read path.
An agent should be able to suggest a claim quickly. It should not be able to silently promote that claim into governed knowledge.
Separate:
observation → claim → evidence → review → accepted assertion
observation → claim → evidence → review → accepted assertion
- Authenticate who or what wrote the memory.
- Quarantine unreviewed claims.
- Record rejected claims and why they were rejected.
- Keep access control separate from domain rules and runtime policy.
12 / Implementation guide
Assemble a brief for the task, not the whole graph.
Select what is relevant, valid for the date, applicable to the entity and permitted for the stated purpose.
CONTEXT SNAPSHOT / REQUIRED FOR REPLAY
Capture the decision environment.
Record the selected source versions, graph assertions, times, policy versions, access decisions, retrieval parameters, actor and task.
evidencetimepolicyactorpurpose
A list of mutable node IDs is not enough to reconstruct historical context.
13 / Implementation guide
Evaluate retrieval and memory together.
A memory system can preserve history perfectly and still make the agent worse if retrieval keeps serving stale or rejected experience.
01Golden casesKnown answers and evidence
02Failure modesWrong doc, stale claim, missing provenance
03Policy testsWhat must not be retrieved or used
04Replay testsCan the decision be reconstructed?
The graph should help explain the decision, not just decorate the architecture diagram.
14 / Implementation guide
Choose one database or several based on operating needs.
Shared identity matters either way. Physical separation is justified by security, workload, retention, availability or ownership differences.
One graph databaseUseful when identity, access, availability and lifecycle requirements are compatible.
Separate storesUseful when memory has higher write volume, shorter retention, stronger isolation or quarantine needs.
No graph databaseRight when a profile record, table, document, event stream or vector index solves the actual problem.
15 / The practical version
Make the distinction before you make the diagram.
Knowledge is what the organisation accepts.
Memory is what the system experienced.
Context is what this task is allowed to use.
Most organisations don’t need three new graph platforms. They need a context assembly process that understands the difference between “this happened”, “this may be true”, and “this is safe to use right now”.
16 / Keep exploring
That distinction is the architecture.
This deck is a visual adaptation of Sergey Vasiliev’s article on knowledge graphs, memory graphs and context graphs. The article contains the full bibliography and deeper technical discussion.
Read the original article ↗Use ← → or the buttons below to move through the deck. Press Home or End to jump.