How do you combine experiential memory with organizational knowledge?

Experiential memory and organizational knowledge answer different questions, and production agents need both. Experiential memory is what happened with this user: preferences, past decisions, soft constraints learned over sessions. Organizational knowledge is what the institution treats as true: policies, certified definitions, SOPs, product facts that must stay the same for every caller. Combining them is not dumping both into one vector index. It is retrieving each plane on purpose, then assembling a prompt where authority and personalization keep clear jobs.

This chapter shows why merging the two planes fails, how Weaviate Engram and Weaviate-backed organizational collections split the work, what assembly rules keep policy above anecdote without erasing the person, and how a dual retrieve looks in practice for a specimen-desk assistant. After that, the natural architecture question is whether those planes live in one store or many.

Why does mixing personal history with company truth in one pile go wrong?

After Pattern Five, the temptation is to treat every retrieved chunk as interchangeable context. That collapses two reliability models. Organizational knowledge is curated, versioned, and often permissioned. A return-policy paragraph should not compete with a chat note that says “this customer hates waiting.” Experiential memory is noisy, user-scoped, and meant to change when preferences drift. If both land in the same ranked list, similarity score decides the winner. Similarity does not know which text is allowed to override the other.

Failure modes are familiar. The agent cites a customer’s offhand complaint as if it were current policy. Or it answers a compliance question with last month’s personalization memory because that memory happened to embed closer to the query. Or it refuses to personalize at all because the team, burned by leakage, stripped memory out and left only docs. The fix is not “more retrieval.” The fix is two pipelines with two contracts: Engram for lived experience under a user_id, and a governed Weaviate collection (or equivalent document plane) for institutional meaning.

Think of the split the way a good librarian thinks about stacks versus circulation history. The catalog says what the library owns and how it is classified. The checkout record says what this reader borrowed and preferred. You never shelve checkout slips next to the rare-book catalog and hope ranking sorts it out.

How should Engram and organizational retrieval each be used?

That distinction only helps if you assign substrates deliberately. Put interaction-derived facts in Engram: preferred formats, recurring constraints, decisions the user already made, lessons from prior sessions. Scope them with user_id and groups such as personalization. Search with hybrid retrieval so lexical cues and semantic neighborhood both matter. Prefer bounded fetches when you already know which memory id is authoritative for a preference, so you are not re-ranking every soft note on every turn.

Put organizational material in a Weaviate collection your product treats as the knowledge plane: SOPs, glossary entries, approved FAQs, release notes, access-tagged procedure pages. That plane is read-heavy for the agent. Writes go through editorial or change-control workflows, not through casual chat extraction. When the agent needs “what is the current packing SOP for dry specimens,” it queries that collection with filters for document type, effective date, and permission tags. When it needs “how does Maya like her specimen labels phrased,” it queries Engram under Maya’s user_id.

Engram is the default experiential layer on this stack because it already models extract, transform, scoped search, and hybrid retrieval for personalization. Organizational RAG belongs beside it, not inside the same memory group. Keeping the APIs separate makes the assembly step honest: you always know which hits came from experience and which came from the institution.

What assembly rules keep authority above anecdote without erasing the person?

Once both retrieves return, the model still needs instructions about conflict. Without rules, the LLM invents a blend that sounds friendly and is wrong. A practical assembly order works like this. First, inject organizational hits that answer the factual or policy question, with titles and ids so the answer can cite them. Second, inject Engram hits that shape tone, defaults, and known user constraints. Third, tell the model explicitly: if personal memory and policy disagree on a fact, policy wins; if they disagree on preference within policy bounds, preference wins.

That third rule is where most teams under-specify. “Maya prefers overnight shipping” must not invent overnight eligibility if the SOP forbids it for live specimens. “Maya prefers overnight shipping” should still choose overnight when the SOP allows both overnight and ground. Personalization is the art of choosing among allowed options, not rewriting the rulebook. Soft-forgetting and supersession from earlier chapters matter here too: if Engram still holds an old preference that Maya superseded, ranking or explicit supersede metadata should demote the stale note before assembly.

Also separate write paths after the turn. Extract new experiential memories into Engram. Do not auto-write chat paraphrases into the organizational collection. If the conversation surfaces a policy gap, open a ticket or change request. Treating every user utterance as a candidate SOP update is how institutional knowledge corrodes.

What does a dual-plane retrieve look like for a botanical press desk?

Those rules become concrete on a small workflow. Imagine a herbarium assistant helping preparators at a botanical press specimen desk. Organizational knowledge covers mounting SOP version, adhesive limits, and shipping rules for dry sheets. Experiential memory covers each preparator’s label style, preferred latin-name formatting, and recurring notes about fragile specimens they have handled before. Scenario id: botanical-press-specimen-desk-4.

from weaviate.engram import EngramClient
from weaviate.engram.retrieval import HybridRetrieval, FetchRetrieval

engram = EngramClient()
user_id = "preparator-maya"
group = "personalization"
scenario = "botanical-press-specimen-desk-4"

# Experiential plane: what Maya prefers and has decided before
prefs = engram.memories.search(
    query="specimen label style shipping preference fragile sheets",
    retrieval=HybridRetrieval(alpha=0.5, limit=6),
    scopes={"user_id": user_id, "properties": {"group": group}},
)

# If a prior turn already pinned a preference memory, fetch it directly
pinned = engram.memories.get(
    memory_id="mem_maya_label_style_v3",
    retrieval=FetchRetrieval(),
)

# Organizational plane (product-owned Weaviate collection query — sketch)
# org_hits = org_collection.query.hybrid(
#     query="dry specimen mounting SOP packing adhesive limits",
#     filters=Filter.by_property("doc_type").equal("sop") &
#             Filter.by_property("status").equal("in_force"),
#     limit=4,
# )

# Assembly contract for the LLM (conceptual):
# 1) Answer SOP questions only from org_hits
# 2) Apply Maya prefs only inside allowed options
# 3) Never promote Engram text into policy
context = {
    "scenario": scenario,
    "organizational": "[org_hits go here]",
    "experiential": [m.content for m in prefs] + ([pinned.content] if pinned else []),
    "conflict_rule": "policy overrides preference on facts; preference chooses among allowed options",
}

In production you would run the organizational query for real against your Weaviate collection and pass structured snippets, not a comment sketch. The important shape remains: Engram search and get stay user-scoped; org retrieval stays filterable by document status; assembly encodes the conflict rule in plain language the model cannot ignore. If Maya asks whether she can use a new adhesive she liked last week, Engram may recall the preference while the SOP hit says that adhesive is not approved. The agent should refuse the adhesive change, offer approved alternatives, and optionally remember that Maya asked—so future turns can acknowledge the constraint without reopening a closed policy question every time.

Combining experiential and organizational knowledge is therefore a composition problem, not a storage trick. Engram carries the person. A governed Weaviate knowledge plane carries the institution. Assembly decides which voice owns facts and which voice owns taste. When those planes blur, agents either feel generic or become confidently wrong. Our next chapter, Should memory use a single store or multiple stores?, asks whether those planes should share one physical store or stay in separate systems—and what you trade for each choice.