How do you choose an architecture pattern by use case?

Architecture patterns only help if you can pick one under deadline. The earlier chapters in this stretch named five shapes—no persistent memory, flat vector memory, tiered memory, graph-based memory, and an enterprise context layer—then showed how experiential Engram memory combines with organizational knowledge and when one store is not enough. Choosing among them is not a beauty contest. It is a match between the questions your agent must answer and the failure modes you refuse to accept.

This chapter gives a decision path you can run in order, maps common product jobs onto pattern combinations with Weaviate Engram as the default experiential plane, shows how to grow without ripping out the first store, and walks a conservation-sewing-frame desk through the same questions. After selection comes a narrower cut: what changes when the system is still a single agent.

Which questions should you answer before you name a pattern?

Start with the workload, not the diagram. Ask whether the agent must remember a person across sessions. If no—and answers must stay identical for every caller—Pattern One (no persistent memory) or a pure organizational RAG plane is enough. Ask whether continuity is mostly independent facts and preferences. If yes, a flat Engram memory surface with hybrid search and user_id scopes is the default personalization layer. Ask whether history outgrows one retrieval budget and you need hot versus cold tiers, summaries, and pinned fetches. That is Pattern Three: tiered memory, still often implemented with Engram groups plus FetchRetrieval for known ids.

Then ask whether the hard questions are relational: which account owns which contract, which part depends on which supplier lot, who approved which change. Similarity alone stalls there; Pattern Four (graph-backed memory or GraphRAG beside vectors) earns its keep. Finally ask whether answers must cite certified definitions, in-force SOPs, and permission boundaries. That requirement pulls in Pattern Five—an enterprise context layer—usually as a Weaviate collection plane beside Engram, not as a replacement for personalization.

If you answer “yes” to more than one of those later questions, you are already composing patterns. Production systems rarely ship a single pure pattern for long. They ship a small stack with explicit routing.

How do common product jobs map onto that stack?

Those questions become concrete when you name the job. A single-turn FAQ bot over a small handbook stays on Pattern One plus document retrieval: no Engram writes, Weaviate hybrid search over docs, empty personalization scopes. A returning-customer assistant that must recall shipping taste and past decisions starts on Pattern Two with Engram: memories.add after extract/transform, memories.search with HybridRetrieval, groups like personalization. When sessions lengthen and raw episodes drown the useful preferences, add Pattern Three behaviors—summaries, supersession, soft-forgetting in ranking, cold archival—without abandoning Engram.

A B2B ops agent that must traverse account → site → asset → open ticket leans on Pattern Four for the multi-hop spine, with Engram still holding operator preferences and prior playbook choices. A regulated change-control or finance assistant that may not invent metric definitions needs Pattern Five’s governed context plane for authority, Engram for experiential continuity, and assembly rules that keep policy above anecdote. Across these jobs, Engram remains the default place for lived, user-scoped memory because its API already models scope, hybrid search, and fetch-by-id. Organizational collections and graphs sit beside it when the question type demands them.

Resist the reflex to buy the most complex pattern because a blog ranked it highest on a long-conversation benchmark. Benchmarks reward continuity under synthetic dialogue. Your tickets may actually be about permissioned SOP fidelity. Match the pattern to the ticket class you see weekly.

How should the architecture grow without a rewrite every quarter?

Once the first fit is chosen, plan the upgrade path in the same order the questions ran. Many teams begin with Engram flat memory for personalization. When ranking quality drops under volume, introduce tiers and maintenance jobs before introducing a graph. When relational misses dominate the incident log, add a graph or structured entity layer for those queries only—keep Engram for preference and episode recall. When compliance review fails because chat memory was treated as policy, split organizational knowledge into a dedicated collection and enforce multi-store assembly.

Keep contracts stable while substrates change. Preserve user_id, group names, and scenario ids. Keep org documents filterable by status and ACL. Put routing in application code: classify whether this turn needs person memory, document grounding, multi-hop entities, or certified definitions, then call the matching plane. That routing layer is cheaper to evolve than a blended index you must later untangle.

Also decide explicitly what you will not build yet. Skipping Pattern Four until multi-hop failures are real is discipline, not neglect. Skipping Pattern Five in a regulated domain is not discipline—it is deferred incident cost. The selection guide is as much about postponing complexity as about adding it.

What does the decision path look like at a book conservation frame?

Walk the same questions on a concrete desk. A studio assistant helps conservators at a book-conservation sewing-frame station. Jobs range from “what thread size does the house SOP allow for this textblock” to “how does Ana prefer her collation notes phrased” to “which prior repair on this accession number used which adhesive.” Scenario id: book-conservation-sewing-frame-desk-2.

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

engram = EngramClient()
user_id = "conservator-ana"
group = "personalization"
scenario = "book-conservation-sewing-frame-desk-2"

def route(turn_kind: str, query: str):
    """Use-case router: pattern choice is a function of question type."""
    if turn_kind == "sop_fact":
        # Pattern Five / org collection — not Engram
        return {"plane": "org_sops", "query": query}
    if turn_kind == "preference":
        hits = engram.memories.search(
            query=query,
            retrieval=HybridRetrieval(alpha=0.5, limit=5),
            scopes={"user_id": user_id, "properties": {"group": group}},
        )
        return {"plane": "engram_flat_or_tiered", "hits": hits}
    if turn_kind == "accession_history":
        # Pattern Four-shaped: entity hops over accession → repairs
        return {"plane": "entity_graph", "query": query}
    if turn_kind == "one_shot_glossary":
        return {"plane": "none_persistent", "query": query}
    raise ValueError(turn_kind)

# Example: preference path still pins known summary memories (tiered habit)
pinned = engram.memories.get(
    memory_id="mem_ana_collation_note_style_v1",
    retrieval=FetchRetrieval(),
)

At this desk, a glossary lookup can stay Pattern One. Ana’s note style is Engram Pattern Two, graduating to tiered fetches as notes accumulate. Accession repair lineage is graph-shaped. Thread and adhesive limits are organizational SOP retrieval with Engram forbidden from overriding them. The “chosen architecture” is therefore a router over patterns, not a single sticker on the repo README. That is what choosing by use case means in shipping code.

Pick patterns by the questions your agent must answer and the failures you will not tolerate—then compose Engram personalization with organizational collections and graphs only where those question types appear. Growth should follow observed ticket classes, not fashion. Our next chapter, How should memory architecture work for single-agent systems?, narrows the lens to systems where one agent owns the loop end to end.