Short answer: Start with hard isolation, minimum necessary recall, and a clear split between the clinical system of record and conversational memory—never “just filter by patient id in the app.”
A wrong memory in healthcare can be unsafe and noncompliant. Flat stores fail regulated agents. Engram fits as the durable preference and dialogue layer when every write and search is hard-scoped, shared playbooks never absorb protected details, and application authorization decides which identity may be queried. Use user scopes and Weaviate multi-tenancy as hard walls; keep EHR and policy corpora in their proper stores; forbid PHI promotion into shared continual learning. Before generation, search only the authorized person’s personalization memories; narrow by encounter when the question is visit-local. Write asynchronously so conversational capture never blocks care delivery and never becomes the only place a clinical fact lives. Authorize identity before every call; prove isolation in CI.
Healthcare and other regulated domains raise the cost of a wrong memory. A support bot that mixes two customers is embarrassing. An agent that mixes two patients, two clinics, or two plan members can be unsafe and noncompliant. Regulated memory architecture therefore starts with isolation, minimum necessary recall, and a clear split between the clinical system of record and conversational memory. Weaviate Engram fits as the durable preference and dialogue layer when every write and search is hard-scoped, shared playbooks never absorb protected details, and application authorization decides which identity may be queried. This chapter explains why flat memory stores fail regulated agents, how Engram user scopes and Weaviate multi-tenancy enforce hard walls, how groups and properties separate patient intimacy from de-identified skill, how to wire a turn without promoting protected data into shared learning, and which isolation tests and refusal rules you should treat as non-optional.
Nothing here replaces legal review, business associate agreements, or EHR controls. It describes how Engram primitives should be arranged when those obligations already exist.
Why is “just filter by patient id in the app” not enough?
Semantic search will happily return the nearest neighbor. If protected memories live in a shared index and isolation is only a filter your code remembers to add, a missing clause becomes a cross-patient leak. Prompt injection and hurried wrappers both love to drop filters. Regulated designs need the boundary enforced at the storage layer, not as a polite convention.
Weaviate’s enterprise guidance uses the hospital multi-tenant question for a reason. Staff for Hospital A must not read Hospital B’s records even when both workloads share infrastructure. Engram inherits that discipline for user-scoped topics. Memories for one user_id are not returned for another. Isolation is automatic when topics require user scope. Your application still must resolve the patient or member id from an authenticated clinical session before any Engram call. Engram keeps the wall honest. It does not invent who is allowed to ask.
A second failure mode is category bleed. General chat memory and protected health workflows must not silently merge. A safer product keeps medical sessions in a PHI-scoped memory path. Non-medical chats should not retrieve those memories unless the user re-enters the regulated workflow under policy. Typed topics and separate groups make that separation real instead of aspirational.
How should Engram scopes and groups look in a regulated agent?
Map the hard identity to Engram’s user_id for every topic that can hold protected personal facts. Prefer identifiers already proven by your identity provider or EHR authorization layer. Never accept a patient id from free text in the prompt. On both memories.add and memories.search, pass that id for user-scoped topics. Property scopes add soft walls inside the person or tenant: encounter_id, clinic_id, or care_program. Include them to stay inside the active visit. Omit them only when policy allows longitudinal recall for that same authorized person.
Use two groups with stricter promotion rules than consumer chat. A personalization group holds communication preferences, accessibility needs, and prior conversation facts that the product is allowed to retain. Those topics stay user-scoped. A continual-learning group, if you use one at all, must hold only de-identified procedural guidance such as “confirm preferred contact channel before leaving voicemail.” Do not promote raw patient narratives into project-wide experience. Engram’s own guidance notes that experience topics can be user-scoped when untrusted users must not influence shared behavior. In healthcare, default to the stricter choice unless a compliance review says otherwise.
Keep the EHR authoritative for diagnoses, orders, and charted findings. Engram should not become a shadow medical record. Use it for conversational continuity and allowed preferences. Merge published clinical policy documents from a controlled knowledge index, not from another patient’s memories. Personalized RAG tutorials in Engram show the same split: shared docs in Weaviate collections, per-user memory in Engram, hard isolation by user_id.
What does a careful regulated turn look like in code?
Before generation, search only the authorized person’s personalization memories. Narrow by encounter when the question is visit-local. Search shared playbooks without patient identifiers, and only if those playbooks are certified free of protected details. After the turn, write the conversation asynchronously into the personalization group. Do not wait on pipeline completion on the request path unless you are debugging.
Consider an audiology clinic assistant that helps schedule fitting follow-ups. It may remember communication preferences. It must never show another patient’s device settings.
import os
from engram import EngramClient
from engram.types import HybridRetrieval
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
# Resolved from the authenticated clinical session — never from prompt text.
patient = "pat_authorized_session_only"
encounter = "audiology-fitting-booth-6"
patient_hits = client.memories.search(
query="Preferred contact channel, loud-environment discomfort, prior fitting notes allowed for this program",
user_id=patient,
group="personalization",
retrieval_config=HybridRetrieval(limit=5),
properties={"encounter_id": encounter},
)
# De-identified clinic playbooks only. No patient user_id.
playbooks = client.memories.search(
query="Confirm callback window before leaving a voicemail about fittings",
group="continual_learning",
retrieval_config=HybridRetrieval(limit=3),
)
turn = [
{
"role": "user",
"content": (
"For audiology-fitting-booth-6, please text me rather than call. "
"Busy streets make phone audio hard. Afternoon callbacks only."
),
},
{
"role": "assistant",
"content": (
"I will use text for this fitting follow-up and schedule afternoon "
"callbacks only, keeping notes under your authorized encounter."
),
},
]
run = client.memories.add(
turn,
user_id=patient,
group="personalization",
properties={"encounter_id": encounter},
)
print(run.run_id, run.status)
print([m.content for m in patient_hits])
print([m.content for m in playbooks])
Hybrid retrieval helps when patients paraphrase discomfort and contact rules. The write stays inside personalization with both user and encounter scope. Playbook search stays project-wide and thin on purpose. If a bounded encounter summary topic is enabled, fetch that singular object by topic and scope rather than hoping open search ranks it first. Keep recent messages in the live prompt for pronouns. Keep durable facts in Engram. Keep chart facts in the EHR.
String inputs can log allowed non-chat events such as “Patient requested SMS for this encounter.” Conversation inputs fit dialogue. Pre-extracted facts fit explicit clinician-confirmed “remember this preference” actions, where a human already approved the memory text.
Which tests and refusal rules belong in every regulated memory release?
Automate cross-identity searches. Store a distinctive preference under patient A. Search as patient B with the same query. Assert no relevant hit. Repeat across clinics or tenants if your product is multi-organization. Confirm that omitting user_id on a user-scoped write fails. Confirm playbooks return without carrying patient prose. These tests are compliance evidence as much as engineering hygiene.
Practice minimum necessary recall. Limit result counts. Prefer topic filters so a scheduling question does not pull unrelated sensitive narrative. Separate PHI sessions from general assistant sessions in product UX. On deletion or right-to-erasure requests, delete or tombstone Engram memories for that identity and verify with a follow-up search that returns empty. Regulated buyers will ask you to prove the person is gone, not only that you issued a delete call.
Treat agent actions that change clinical state as outside Engram. Memory may remind a clinician of a stated preference. Orders, prescriptions, and chart amendments must go through systems that already enforce audit, role checks, and legal retention. Engram’s async pipeline is an advantage here. Conversational capture should never block care delivery, and it should never become the only place a clinical fact lives.
Regulated memory architecture with Engram is therefore conservative by design. Hard-scope every protected topic. Keep EHR and policy corpora in their proper stores. Forbid PHI promotion into shared learning. Authorize identity before every call. Prove isolation in CI. Our next chapter, How should you design memory architecture for educational and tutoring agents?, leaves clinical risk for classroom continuity, where student progress, misconceptions, and teaching playbooks need a similarly careful split between personal learning state and shared instructional skill.