How do you design adaptable memory models?

Memory taxonomies are useful teaching tools and dangerous product freezes. Working, session, and long-term tiers help you reason about volatility. Episodic versus semantic splits help you reason about consolidation. Graph versus vector splits help you reason about query shape. None of those labels should become a permanent, mandatory schema that every memory must wear before the agent is allowed to learn. Prescriptive models fail when the next customer’s workload does not match the textbook diagram you shipped in v1.

This chapter argues for stable contracts with adaptable configuration, shows how Weaviate Engram’s scopes, groups, properties, and retrieval choices support evolution without a rewrite, outlines what you should hard-code versus what you should keep tunable, and walks a camera-obscura focusing desk through a memory policy that can change without renaming the universe. The practical next lever for that adaptability is topics as a configuration layer for extraction.

Why do fixed cognitive taxonomies age badly in shipping agents?

After layered memory feels clear, teams often encode the diagram as database enums: every write must be working, episodic, or semantic, every retrieve must declare a cognitive type, and every new feature must invent a new enum value. That feels rigorous. It becomes brittle the first time a support agent needs “case timeline” memories that are neither clean episodes nor tidy semantics, or a sales agent needs “open commitment” notes that are procedural without being code. Research on agent memory keeps pointing the same direction: static pipelines and hand-designed retention rules underperform when tasks shift, because the right remember/forget policy is workload-dependent.

Prescriptive models also encourage false completeness. If the taxonomy has five buckets, product managers assume five buckets cover reality. Gaps get forced into the nearest label, which corrupts retrieval. Adaptable design starts from operations you can always perform—add, search, get, update/supersede, delete—and from contracts that stay true across workloads: user scope, write gates, plane separation between personalization and organizational authority.

Use cognitive labels as documentation and dashboards, not as the only write API. Teach the team the tiers. Do not make the database reject a useful memory because it lacks a philosophically pure type. The taxonomy can live in runbooks and analytics dimensions while the write path stays open to new groups your incidents demand.

What should stay fixed, and what should stay configurable?

Hard-code the invariants that prevent harm. Always scope personalization by user_id. Never let chat extraction write organizational SOP collections. Keep assembly rules that prevent preference from overruling policy on facts. Require attribution when multiple agents write. Those are safety and tenancy contracts.

Keep configurable the behaviors that track product learning. Which groups exist (personalization, session, case_timeline). Which properties mark scenario, project, or agent. Which retrieval alpha and limits apply per intent. Which promotion rules move session digests into long-term Engram. Which soft-forgetting weights apply in ranking. Engram’s API already encourages that split: the methods stay stable while scopes, properties, and retrieval objects carry policy. That stability is what lets you experiment on extraction without threatening tenancy or forcing a platform migration every quarter.

Version the configuration, not the metaphysics. When tickets show that “sample preferences” need a dedicated group, add a group and a router branch. Do not invent a sixth universal memory faculty and migrate every historical row to satisfy a paper. Adaptability is cheap when memories are data plus metadata; it is expensive when memories are instances of a frozen ontology.

How does Engram support evolution without a substrate swap?

Engram is a strong default experiential plane partly because it does not force one academic schema. You can start with a single personalization group and hybrid search. Later you can add session-scoped properties with TTLs in the application layer, pinned summary ids with FetchRetrieval, and separate groups for agent scratch in multi-agent setups. The client calls remain memories.add, memories.search, memories.get, and memories.delete. Policy moves into scopes and into your orchestrator.

That is the opposite of a prescriptive memory model. A prescriptive model says the product is “an episodic-semantic-procedural engine” and every feature must extend that engine. An adaptable Engram-centered design says the product is “scoped durable memory with hybrid retrieval,” and extraction rules, topics, and promotion heuristics are config that can change per tenant or per skill. Organizational knowledge and graphs remain optional planes you attach when ticket classes demand them—not mandatory chapters of a single cognitive religion.

Measure adaptability with change cost. If adding a new memory kind requires a migration and a new microservice, your model was too prescriptive. If it requires a new group name, a router case, and a write-gate rule, you are in healthy territory. Prefer that three-line change even when a grand redesign would feel more architecturally complete. Completeness is not the same as fitness.

What does adaptable policy look like at a camera obscura desk?

A gallery assistant helps artists at a camera-obscura focusing desk. Early on, the only long-term need is how each artist likes exposure notes phrased. Months later, the same product must also remember which lens board setups were tried on which plates—without pretending those setup notes are “semantic faculties.” Scenario id: camera-obscura-focusing-desk-7.

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

engram = EngramClient()
user_id = "artist-soren"
scenario = "camera-obscura-focusing-desk-7"

# Config, not ontology: groups can grow without renaming "memory itself"
MEMORY_POLICY = {
    "v1": {"groups": ["personalization"], "intents": ["preference"]},
    "v2": {
        "groups": ["personalization", "setup_log"],
        "intents": ["preference", "setup_history"],
        "write_gates": {
            "personalization": "standing_preference_only",
            "setup_log": "structured_setup_event_only",
        },
    },
}

policy = MEMORY_POLICY["v2"]

def search_for(intent: str, query: str):
    group = "personalization" if intent == "preference" else "setup_log"
    if group not in policy["groups"]:
        raise ValueError("group not enabled in this policy version")
    return engram.memories.search(
        query=query,
        retrieval=HybridRetrieval(alpha=0.5, limit=5),
        scopes={"user_id": user_id, "properties": {"group": group, "scenario": scenario}},
    )

def maybe_write(intent: str, content: str):
    group = "personalization" if intent == "preference" else "setup_log"
    gate = policy["write_gates"][group]
    if gate == "standing_preference_only" and not is_standing_preference(content):
        return None
    if gate == "structured_setup_event_only" and not is_setup_event(content):
        return None
    return engram.memories.add(
        content=content,
        scopes={"user_id": user_id, "properties": {"group": group, "scenario": scenario}},
    )

# Stable pin still works across policy versions
style = engram.memories.get(
    memory_id="mem_soren_exposure_note_style_v2",
    retrieval=FetchRetrieval(),
)

Version one needed only personalization. Version two added setup_log with a stricter write gate. No migration renamed every memory into a new cognitive type. The obscura desk still uses Engram; the product adapted by configuration. That is designing for adaptability: keep the durable API and tenancy contracts, let extraction and grouping follow the work.

Avoiding prescriptive memory models means treating cognitive taxonomies as guides, not as unchangeable schemas. Fix safety and scope contracts; keep groups, gates, and routing as versioned policy on top of Engram. Our next chapter, How do topics configure memory extraction?, shows how topics make that configurable extraction layer concrete.