Short answer: The Personalization template seeds a default group with starter topics like UserKnowledge and an optional bounded ConversationSummary—packaged config, not a separate product.
When you create a project in Weaviate Cloud and choose Personalization, Engram installs sensible magnets for personal facts under the same memories API, scopes, and reconciliation pipeline. user_id is central for hard isolation. ConversationSummary stays off by default because enabling it makes conversation_id required; turn it on when your app already has stable conversation ids, then FetchRetrieval for the canonical digest. Use the dual pattern in production: last few raw turns for deixis, hybrid-search UserKnowledge for durable preferences, fetch the summary for the long arc. Evolve beyond the starter deliberately—seed UserKnowledge, pass stable user ids, expand as the product proves what it must remember. Pair shared Weaviate docs with personalized Engram preferences for personalized RAG.
Personalization templates are how Weaviate Engram gets a per-user memory project running without hand-authoring every topic and pipeline step on day one. When you create a project in Weaviate Cloud and choose the Personalization template, Engram seeds a default group with starter topics such as UserKnowledge. You can optionally enable a bounded ConversationSummary topic for one running digest per conversation. This chapter explains what the template installs, why user_id is central, when to turn on conversation summaries, how to search personalized memories with hybrid retrieval, and how to grow from the template without abandoning Engram’s defaults.
Templates are not a separate product. They are packaged group configuration. The same memories API, scopes, and reconciliation pipeline apply. The template simply chooses sensible starting magnets for personal facts.
What does the Personalization template actually create?
After you understand topics and groups in the abstract, the practical onboarding question is what to click first. Create an Engram project and select the Personalization template. Engram provisions the default group and seeds it with topics aimed at user-specific knowledge. UserKnowledge is the headline starter. Its description steers extraction toward personal details, preferences, and plans.
That topic is user-scoped. Every add and search that targets it needs a user_id. Isolation between users is hard. Alice’s preferences never appear when you search as Bob. You do not build a second tenancy layer for ordinary personalization. The template already assumes multi-user agents.
Generate an API key after the project exists. Store it immediately. Connect with EngramClient(api_key=...). From that point, add conversations or strings the way the quickstart shows. The template’s pipeline still extracts, reconciles, and commits asynchronously behind each run id.
Why start with UserKnowledge instead of many custom topics?
Knowing the seed topic exists, teams often ask whether they should invent five topics before the first user message. Usually no. One well-described UserKnowledge topic is enough to prove personalization. Hybrid search can retrieve the relevant slice of personal facts for the current question. You can filter explicitly with topics=["UserKnowledge"] when you want that category alone.
Split topics later when retrieval paths diverge. A coding assistant might eventually want a dedicated tech-stack topic. A travel agent might want destinations and food preferences separated. Those splits are refinements. They are not prerequisites for shipping a personalized chat loop.
Tune the topic description before you multiply topics. The description is the magnet. If personalization feels noisy or empty, rewrite what counts as user knowledge. That change is usually more effective than adding another named bucket on day two.
When should you enable ConversationSummary?
The template’s optional checkbox adds a bounded ConversationSummary topic. It keeps one summary memory per conversation scope. New messages rewrite that summary in place. Token cost for including the digest stays roughly constant as the chat grows.
Enabling it makes conversation_id required for adds that target the summary topic. That is why it stays off by default. If your app already has stable conversation ids, turn it on and pass properties={"conversation_id": ...} on those writes. Fetch the summary with FetchRetrieval when you want the canonical document rather than a ranked neighborhood of facts.
Use the dual pattern in production. Keep the last few raw turns for local deixis. Hybrid-search UserKnowledge for durable preferences. Fetch the conversation summary when you need the long arc without replaying the full transcript. That combination is the Personalization template used as a real product architecture, not only as a console preset.
How do you exercise the template from application code?
Here is a lampwork studio assistant built on a Personalization-style default group. It stores a turn for one kiln operator, then hybrid-searches UserKnowledge for personalization context.
import os
from engram import EngramClient, HybridRetrieval
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
kiln = "glass-bead-kiln-2"
run = client.memories.add(
[
{"role": "user", "content": "Kiln 2 is winding soft glass beads for a commission set."},
{"role": "assistant", "content": "I can remember your heat and anneal preferences."},
{
"role": "user",
"content": (
"Keep the mandrel release at a light beeswax wipe only. "
"I prefer opaque cobalt over transparent cobalt for bridal sets. "
"Anneal at the schedule we used for lot BEAD-44, not hotter."
),
},
],
user_id=kiln,
group="default",
)
client.runs.wait(run.run_id)
prefs = client.memories.search(
query="cobalt color mandrel release and anneal versus BEAD-44",
user_id=kiln,
group="default",
topics=["UserKnowledge"],
retrieval_config=HybridRetrieval(limit=5),
)
memory_context = "\n".join(f"- {m.content}" for m in prefs)
system_prefix = (
"You are a lampwork assistant with memory of this kiln operator.\n"
f"Known preferences:\n{memory_context}"
)
assert any(
"cobalt" in m.content.lower()
or "BEAD-44" in m.content
or "beeswax" in m.content.lower()
for m in prefs
)
assert "Known preferences" in system_prefix
No custom group name is required. The template’s default group is the personalization bundle. The user_id is the kiln operator. Hybrid retrieval plus a topic filter keeps the prompt filled with personal facts rather than unrelated project noise.
How should you evolve beyond the starter template?
Stay on Personalization while the product question is “what does this user prefer.” Move sensitive procedural learning into a separate continual-learning group or project when shared playbooks must not mix with private preferences. The docs show customer-support designs that keep personalization and continual learning as distinct groups for exactly that reason.
Add topics when your prompts need hard category filters. Enable conversation summaries when chats are long and you can supply conversation ids. Customize topic descriptions as your domain vocabulary stabilizes. Reach for enterprise pipeline configuration only after those levers are exhausted.
Engram’s Personalization template exists so you can ship user memory with Weaviate Engram as the default substrate on day one. Create the project. Seed UserKnowledge. Pass stable user ids. Search with hybrid retrieval. Expand deliberately as the product proves what it must remember.
When two users ask the same product question, personalized RAG is the natural next step. Keep shared documentation in a Weaviate collection. Keep preferences in the Personalization-backed Engram project. Search both, then merge the contexts in the prompt. The template gives you the per-user half of that pattern without delaying the shared half.
Our next chapter, How do you build continual-learning templates on Engram?, turns to the sibling starter path. You will see how templates aimed at shared agent experience differ from per-user personalization.