Your AI assistant can summarize the latest meeting and still recommend a tool you already rejected, miss a customer commitment, or present an old decision as current. The problem is not necessarily the model. It is the absence of durable business state.

If you want AI to remember why a decision changed, who approved it, what evidence supported it, and whether it still applies, you need more than saved conversations. You need a memory layer that represents relationships, time, and provenance explicitly. A knowledge graph can provide that layer, but only if you design it around real decisions instead of trying to map the whole company.

A context window is not a memory system

A large context window controls how much information a model can process in a request. It does not determine which facts should persist, which version is current, or how one decision relates to another. Even a model that can accept one million tokens does not inherently carry your business state into a new session.

You can paste old conversations back into every prompt, but that makes the model repeatedly read material it may not need. It also leaves the important interpretation work until query time: resolving duplicate names, distinguishing proposals from approvals, finding superseded decisions, and judging which evidence is still valid.

A business memory system does that work before the final answer. It turns notes, conversations, documents, decisions, and project updates into identifiable objects and relationships. Retrieval can then return the relevant slice of business state instead of an undifferentiated archive.

Business problem	What document retrieval tends to return	What graph memory should return
A tool decision changed	Documents mentioning both tools	The current decision, the decision it replaced, the change date, and the approver
A customer asks about a commitment	Meetings containing related keywords	The customer, request, resulting decision, owner, and supporting record
Two teams disagree about a claim	Two plausible passages	Separate claims connected by a contradiction, with provenance for each
An executive asks why a roadmap item moved	A collection of planning notes	The dependency, customer evidence, decision chain, and current status

This distinction also tells you when not to build a graph. If your question is simply, "Where is the latest policy document?" search may be enough. A graph becomes useful when the answer depends on several entities, a sequence of changes, conflicting evidence, or the difference between what was once true and what is true now.

Design the graph around one decision question

The fastest way to produce an expensive graph that nobody trusts is to begin with a company-wide ontology. Start with a question that already consumes time or causes repeated mistakes. A useful first question might be:

What did this customer request, what did the product team decide, why did the decision change, and what is the current commitment?

That question is narrow enough to test and rich enough to require persistent memory. Before choosing a database, write an answer contract. For every response, specify what the system must expose:

• The canonical customer, project, feature, and decision involved.
• The currently valid state, not merely the most semantically similar statement.
• The chain connecting the request to evidence and the resulting decision.
• The person or process that had authority to approve the decision.
• The record from which each material claim was extracted.
• An explicit unknown or conflict when the graph cannot justify a single answer.

A compact first schema can cover a surprising amount of product and operating work. I would begin with the six entity types that repeatedly appear in decision questions, then add another type only when an actual query cannot be answered without it.

Entity	What it represents	Question it helps answer
Project	A product initiative, campaign, research task, or operational program	Where does this fact or decision apply?
Person	A customer, collaborator, expert, owner, or decision-maker	Who requested, created, reviewed, or approved it?
Tool	A model, service, framework, or other technology	What is used, rejected, or depended upon?
Source	A meeting, report, interview, document, or dataset	Where did the claim come from?
Claim	A statement that requires evidence	What is being asserted, supported, or disputed?
Decision	An approval, rejection, commitment, or change in direction	What choice governs the current state?

Keep the first relationship vocabulary equally constrained. Relations such as USES, DEPENDS_ON, SUPPORTS, CONTRADICTS, REQUESTED_BY, DECIDED_BY, REPLACES, CREATED_FROM, and BELONGS_TO express more business meaning than a generic "related to" edge.

The schema is also a product policy. You must decide whether a recommendation counts as a Decision, who can mark a decision as authoritative, when two records should merge into one Person, and whether a new statement replaces or merely contradicts an earlier one. If those rules remain implicit, the extraction model will make inconsistent choices for you.

Use canonical identifiers and aliases for important entities. "HighLevel," "HL," and a legal company name may refer to the same organization, while two customers may share a personal name. Automatic merging is convenient for low-consequence entities. Decisions, customers, contracts, and other sensitive records need stricter merge rules and a review path.

Make time and provenance part of every fact

A graph becomes business memory when it can distinguish history from current truth. Without temporal fields, it is only a more visual form of retrieval.

Attach these fields to every material fact or relationship:

• source_id: the exact episode or record from which the fact came.
• observed_at: when the memory system encountered the fact.
• valid_from: when the fact became true in the business.
• valid_to: when it stopped being true, if known.
• status: a controlled state such as proposed, active, superseded, disputed, or withdrawn.

observed_at and valid_from are not interchangeable. A retrospective project note may be ingested today while describing a decision that took effect much earlier. If you store only the ingestion time, a historical query can produce the wrong sequence of events.

Suppose Decision B adopts a different tool and replaces Decision A. Do not overwrite A. Set its end of validity, mark it superseded, and connect B to A with REPLACES. The system can now answer both "What tool is approved?" and "What was approved before the change?" The ability to preserve both states and their effective periods is what makes a temporal graph useful for a changing business.

Provenance deserves the same attention. Structure does not turn an extracted statement into truth. A model can create the wrong edge, an old document can remain searchable, and two valid records can disagree. Store evidence at the level of the claim or relationship, not only on a distant document node.

A user should be able to move from an answer to the supporting edge, from the edge to source_id, and from that identifier to the original passage or event. If the interface cannot make that path visible, the graph may improve answer fluency without improving trust.

Do not resolve every conflict by selecting whichever record arrived last. Recency does not prove authority. Preserve competing Claim nodes, connect them with CONTRADICTS, and apply an explicit resolution rule. That rule might depend on an approved system of record, an accountable decision-maker, or a human review. The important point is that the policy is visible and testable.

Separate ingestion from retrieval and reasoning

Persistent memory works best as a pipeline with distinct responsibilities. Collapsing everything into one prompt makes failures difficult to diagnose: you cannot tell whether the answer failed because extraction missed a date, identity resolution merged two customers, retrieval selected an expired fact, or reasoning misread a correct subgraph.

1. Ingest an episode. A note, conversation, document, decision record, or project update enters the memory layer with its original text and metadata intact.
2. Extract structure. The model identifies candidate entities, relationships, dates, claims, and decision language.
3. Resolve and store. The system matches entities to canonical records, preserves aliases, checks for duplicates, and writes temporal facts to the graph.
4. Retrieve a relevant subgraph. A query selects the applicable entities, relationships, status, time range, and evidence.
5. Reason over that subgraph. The answering model composes a response, cites provenance, exposes conflict, and abstains where evidence is insufficient.

This separation gives you a practical compute policy. Repetitive extraction is mostly structured recognition and can use lower reasoning effort. Duplicate resolution and ambiguous facts deserve more. Difficult multi-hop questions deserve higher effort, while contradiction investigations or consequential decision reviews can use the most careful setting. The reasoning budget should follow the job, not default to the maximum for every ingestion event.

Retrieval should narrow the problem before the final model sees it. First apply tenant, workspace, project, and access boundaries. Then identify seed entities, follow relevant relationship types, filter temporal state, and return the evidence attached to the surviving facts. Semantic similarity can help find candidate nodes, but it should not decide whether a superseded decision is current.

Consider the question, "Which product decision changed after the customer interview, and what evidence supports the change?" A useful retrieval result is not a stack of interview and roadmap passages. It is a compact subgraph connecting Customer to Request, Request to Claim, Claim to Source, Decision B to that Claim, Decision B to its approver, and Decision B to the Decision A it replaced.

A practical pilot stack

Graphiti provides an open-source temporal graph-memory layer that can ingest episodes, extract relationships, search entities, retrieve facts, and trace provenance. Its Model Context Protocol interface lets an AI client invoke those capabilities as controlled tools instead of treating the graph as prompt text.

For a local pilot, Graphiti can run with its bundled FalkorDB setup. Neo4j is the more mature option when you need a production graph interface and operating model. Graph retrieval still needs embeddings for semantic or hybrid search; an Anthropic-based setup therefore needs a separate embedder, such as the local all-MiniLM-L6-v2 Sentence Transformers model used in the example Graphiti configuration.

Do not begin with a large historical backfill. Ingestion can trigger several model calls for extraction, deduplication, and summarization. A conservative Graphiti starting point is SEMAPHORE_LIMIT=5; for a standard Anthropic API tier, roughly five to eight concurrent episodes is the stated working range. Begin with the episodes required by your answer contract, inspect the resulting graph, and correct schema or identity rules before scaling volume.

Treat this stack as replaceable infrastructure. Your durable assets are the entity model, temporal semantics, provenance rules, permissions, evaluation set, and correction workflow. A model or graph database can change without forcing you to redefine what an approved decision means.

Operate business memory as a governed product

The risky part of persistent memory is not that the system forgets everything. It is that the system remembers a plausible interpretation and silently treats it as authoritative. The write path therefore needs stronger controls than an ordinary document index.

• Keep the original episode. You need it to audit an extraction, correct an edge, or rebuild the graph after a schema change.
• Separate observations, inferred claims, and approved decisions. A meeting comment should not acquire the same authority as a signed decision record.
• Control state transitions. Define who or what may mark a Decision active, superseded, withdrawn, or disputed.
• Enforce permissions before retrieval. The graph must not create a path around the access controls of the systems that supplied its data.
• Provide correction and deletion paths. Persistent memory without lifecycle controls becomes an accumulating data liability.
• Treat stored text as data, not instructions. Content retrieved from an episode must not be allowed to redefine the agent’s operating rules.

Evaluate the memory before evaluating the prose. A polished answer can conceal a bad edge. Build a small set of questions whose expected state and evidence you can inspect manually. Include cases for a current decision, a superseded decision, a late-arriving record, contradictory claims, entity aliases, missing evidence, and a question the system should refuse to answer.

For each case, inspect five things:

1. Entity resolution: Did the query select the correct customer, project, person, tool, or decision?
2. Temporal correctness: Did it return the fact valid for the requested period?
3. Relationship correctness: Does the path express the actual business dependency or decision chain?
4. Provenance completeness: Can every material claim be traced to an original record?
5. Abstention behavior: Does the system expose uncertainty when evidence is absent or unresolved?

Only after those checks pass should you evaluate answer usefulness, latency, and cost. This order matters. Faster generation does not compensate for stale state, and more eloquent reasoning does not repair a missing REPLACES edge.

Assign ownership as you would for any product with shared data. Someone must own the schema, someone must own connectors and ingestion health, and an accountable business role must own the meaning of authoritative states. Without that division, the graph quietly becomes a second system of record that nobody is empowered to correct.

Key takeaways

• Persistent business memory is a model of state, relationships, time, and evidence. It is not a larger chat archive.
• Start with one recurring decision question and define the answer contract before choosing infrastructure.
• Preserve replaced and contradictory facts. Use temporal fields and explicit relationships to identify what is current.
• Attach provenance to every material claim or edge so a user can inspect why an answer should be trusted.
• Separate extraction, entity resolution, retrieval, and reasoning so each failure can be found and corrected.
• Expand the graph only after it passes tests for identity, time, relationships, provenance, and abstention.

Choose a decision your organization repeatedly reopens. Write the current-state question, the historical question, and the evidence question. Load only the episodes needed to answer them. If the graph returns the right state with a traceable reason, expand into the adjacent workflow. If it does not, fix the memory model before adding more data.

References

• Substack AI Topic — How to Build Your First Knowledge Graph With Claude Opus 5

---