Your AI agent answers a question correctly in one session, then asks for the same background next week. You can keep enlarging the prompt or retrieving similar documents, but neither method by itself gives the agent a durable model of what changed, which facts are still valid, or how one decision relates to another.

A knowledge graph becomes useful when the memory problem is relational. It can connect notes, conversations, and project history so an agent can retrieve, update, and reason across them. The hard part is not choosing a graph database. It is deciding what deserves to become memory, how that memory changes, and when the agent is allowed to trust it.

Use a graph when memory depends on relationships

Start with the questions your agent must answer. A graph is a strong fit when those questions repeatedly cross people, projects, decisions, dependencies, and time:

• Which active commitments depend on a requirement that just changed?
• Why was this roadmap decision made, and which assumption supported it?
• Who owns the blocked work, and which customer promises could it affect?
• What is the current policy, and which earlier decision did it replace?
• Where have the same risk, objection, or dependency appeared before?

These are not simple document-retrieval questions. The answer may be distributed across a meeting, a project record, a decision log, and a later correction. Similarity search can locate candidate passages, but the agent still needs stable entities and explicit relationships to join them.

A graph is usually unnecessary when the job is to summarize one document, search a mostly static knowledge base, calculate over structured records, or preserve short-lived task state. Use the simplest store that matches the question. A relational database remains better for many transactional queries, an immutable artifact store is better for original evidence, and vector retrieval is useful for finding semantically related text.

The practical architecture is therefore hybrid. Keep original artifacts in their authoritative systems. Use semantic retrieval to find possible evidence. Use the graph to maintain canonical identities, relationships, events, and provenance. Read live operational facts from the system that owns them rather than copying everything into agent memory.

Key takeaways

• Choose a knowledge graph when recurring questions depend on relationships, history, and changing state.
• Store explicit assertions with provenance and lifecycle data, not untraceable summaries of entire documents.
• Separate candidate memories from committed memories so extraction errors do not silently become durable facts.
• Make retrieval question-specific and tightly bounded; a larger subgraph is not automatically better context.
• Test corrections, contradictions, permissions, and deletion before allowing autonomous memory writes.

Model the decisions your agent must support

Do not begin with an enterprise-wide ontology workshop. Begin with a small inventory of decisions and questions. For each one, work backward: what entities must the agent identify, what relationships must it traverse, and what evidence must it show before a person can rely on the answer?

A product organization might need entities such as Person, Team, Account, Product, Project, Requirement, Decision, Risk, Event, and Artifact. Useful relationships are verbs with operational meaning: OWNS, DEPENDS_ON, REQUESTED, APPROVED, BLOCKED_BY, AFFECTS, SUPERSEDES, and RECORDED_IN. Names should be specific enough that a product manager and an engineer interpret them the same way.

Avoid the common shortcut of turning each document into a node and connecting documents that mention similar words. That produces a document map, not dependable memory. The graph should represent the claims inside the artifacts while preserving links back to the original evidence.

Give every durable assertion an evidence envelope

A useful memory record needs more than a subject, relationship, and object. Capture enough metadata to answer four questions: what is being asserted, where it came from, when it was valid, and who is allowed to use it.

• Stable identity: canonical identifiers for the subject and object, separate from their display names and aliases.
• Typed assertion: a defined predicate and an object whose type is valid for that predicate.
• Evidence status: whether the assertion was observed in an authoritative record, confirmed by a person, or inferred by the agent.
• Provenance: a pointer to the artifact, record, or event that supports the assertion.
• Lifecycle: when the assertion was recorded, when it applies, whether it is current, and what superseded it.
• Governance: access scope, retention treatment, and the owner responsible for corrections.

Do not hide evidence status inside an opaque confidence score. An assertion taken from an approved decision record is categorically different from a plausible inference generated from a conversation. Your agent should be able to explain that difference, and downstream policies should be able to act on it.

Treat identity, time, and contradiction as core schema concerns

Entity resolution is where a polished demonstration often becomes an unreliable product. The same account, feature, or person may appear under aliases, while unrelated entities may share a display name. Keep canonical identifiers separate from labels. Record aliases with their namespace and origin. If a match is ambiguous, preserve separate entities until an authoritative identifier or a person resolves it. A false merge can contaminate every relationship attached to both entities.

Time needs similar care. Recorded time tells you when the memory entered the graph; valid time tells you when the fact applied in the real workflow. Those are not interchangeable. A policy can be recorded after it took effect, and a meeting note can describe a decision that was later reversed.

When information changes, append a new assertion and connect it to the old one with an explicit supersession or invalidation relationship. Do not silently overwrite history. The agent can then answer both questions that matter: “What is true now?” and “Why did the answer change?”

Contradictions should remain visible until a defined authority resolves them. If a customer record and a meeting note disagree, the graph should retain both claims, their provenance, and their status. A last-write-wins rule is convenient, but it can turn the newest statement into the truth without establishing that its author had the authority to change anything.

Design retrieval as a product behavior

Having the right facts in a graph does not mean the agent will use them well. Retrieval must be designed around the user’s intent, the permitted relationships, and the amount of evidence the model can evaluate without losing the question.

A dependable retrieval path looks like this:

1. Classify the request. Decide whether the user is asking for current state, historical explanation, impact analysis, ownership, precedent, or a recommendation.
2. Resolve seed entities. Map names and references in the request to canonical graph entities. Preserve ambiguity instead of guessing when multiple matches remain plausible.
3. Select an allowed traversal. Choose relationship types and directions that fit the question, while enforcing the user’s permissions.
4. Rank the evidence. Consider semantic relevance, validity, provenance, authority, and recency rather than graph distance alone.
5. Build a compact context package. Include the relevant assertions, supporting evidence, unresolved conflicts, and enough neighboring context to explain the relationship.
6. Generate an answer with boundaries. Distinguish stored facts, conclusions derived from explicit graph paths, and model-generated hypotheses.

Traversal should be bounded by the question, not by whatever the database can return. If someone asks why a project is delayed, the useful subgraph may connect the project to a dependency, a blocked requirement, a decision, and an owner. Pulling every meeting attended by that owner adds context-window pressure without necessarily adding evidence.

Create retrieval templates for recurring workflows. A current-state query should prefer assertions that are valid now and suppress superseded ones while retaining an explanation link. A historical query should preserve the sequence of decisions. An impact query should traverse only relationship types that represent real dependency or effect, not every form of association.

The inference boundary must also be visible. Suppose the graph establishes that an account depends on a feature and that the feature is blocked. “The account’s renewal is at risk” may be a reasonable hypothesis, but it is not automatically a stored fact. Present it as an inference unless an authorized source has recorded that risk. Do not let the agent convert its own plausible prose into durable organizational memory.

Every answer based on persistent memory should be able to expose its evidence path. That does not require showing raw graph syntax to the user. It does require naming the relevant entities and relationships, pointing to supporting artifacts, and stating when a conflict or missing link prevents a firm answer.

Put an auditable gate in front of every memory write

Reading from a graph and writing to it carry different risks. A retrieval mistake can produce a bad answer once. An incorrect write can influence every later answer that touches the corrupted entity. Treat memory creation as a controlled data operation, not a side effect of generating text.

Use a proposal-and-commit workflow:

1. Extract candidates. Convert an authorized input into proposed entities, assertions, events, and provenance links.
2. Resolve identities. Attach candidates to canonical entities or flag them for review when the match is ambiguous.
3. Validate the schema. Reject invalid entity types, relationships, missing evidence, and malformed lifecycle data.
4. Check authority and access. Confirm that the input can establish this kind of fact and that the target memory will not broaden access.
5. Detect duplicates and conflicts. Link a correction to the assertion it supersedes instead of creating an unexplained competing fact.
6. Commit accepted changes. Record who or what approved the operation and retain an audit trail that supports rollback.

Human review does not need to cover every memory forever. It should concentrate where errors have high downstream impact: identity merges, permissions, policy changes, financial commitments, customer obligations, and facts that will trigger automated actions. Lower-risk writes can become more autonomous only after their validators and rollback paths have proved dependable.

Carry source permissions into the graph

Copying a restricted fact into a broadly searchable graph can bypass the permissions on its original system. Preserve access metadata on assertions and evidence links, enforce it during traversal, and design caches so they cannot return facts a user is no longer permitted to see. If the system cannot propagate source permissions reliably, keep the restricted content out of shared agent memory.

Deletion and retention also need graph-aware behavior. Removing an artifact may leave extracted assertions, derived summaries, cached context, and relationships behind. Maintain lineage from each memory to its evidence so a deletion request or retention event can identify what must be removed, invalidated, or re-evaluated. Test this path before the graph contains sensitive organizational knowledge.

Assume durable memory can preserve bad input

An untrusted message, manipulated document, or mistaken extraction becomes more dangerous when it persists. Assign trust and authority by source type. Quarantine claims from untrusted inputs. Require provenance for durable assertions. Prevent retrieved instructions inside evidence from changing system policy or authorizing new writes.

Ownership must be explicit as well. Someone needs authority to change the schema, define which systems are authoritative for each domain, review disputed identities, and approve new autonomous write classes. Without that operating model, the graph accumulates facts faster than the organization can correct them.

Prove that memory improves the work before expanding it

Do not evaluate persistent memory with a handful of fluent demonstrations. Build an evaluation set from recurring work: questions users ask repeatedly, decisions that depend on earlier context, facts that change, entities with similar names, conflicting assertions, and information whose access is later removed.

Run each task against a no-memory baseline and the graph-enabled agent. Judge the result at several layers:

• Retrieval success: did the context package contain the facts and relationships required to answer the task?
• Provenance coverage: how many memory-dependent claims in the answer point to valid supporting evidence?
• Temporal correctness: did the agent use the fact that applied to the requested time instead of an obsolete assertion?
• Conflict handling: did it expose unresolved disagreement rather than silently choosing a convenient claim?
• Identity quality: did it connect aliases that refer to the same entity without merging different entities?
• Write quality: how many proposed memories were accepted, corrected, rejected, or later rolled back?
• Forgetting behavior: did removed or expired information disappear from retrieval, derived context, and caches?
• Task impact: did memory improve the actual decision or workflow, not merely make the answer sound more informed?
• Operational cost: what latency, model usage, storage, review load, and maintenance did the improvement require?

Do not collapse these into one headline score. A high average can conceal a permission leak, a stale policy, or an identity merge that makes the product unsafe to expand. Set separate launch criteria for the failure modes that carry different consequences.

Roll out capabilities in increasing order of consequence. Begin with read-only evaluation. Then show sourced memory to users and collect corrections. Add assisted writes that require approval. Permit narrow autonomous writes only when the input class, schema, authority, monitoring, and rollback behavior are all constrained. Expand entity types and workflows after the existing ones remain useful under updates, contradictions, and deletion.

Your first implementation should serve one valuable workflow, not attempt to remember the company. Write down the recurring questions, define the smallest graph that can answer them, and test what happens when a fact changes, conflicts, or must be forgotten.

If the agent cannot produce a better answer and show why that answer is trustworthy, adding more nodes will not fix the product. Tighten the memory contract first. Expand the graph only when each new relationship has a clear consumer, an authoritative source, and a correction path.

References

• Think Tank AI – How to Build Your First Knowledge Graph With Claude Opus 5

---