How should you design memory architecture for personal productivity agents?

Personal productivity agents succeed when they feel like they know one person across many days. They fail when they treat every morning as a cold start, or when they dump months of chat into the prompt and hope the model finds the right habit. Goals, routines, constraints, and mood-of-the-week notes are different kinds of memory. Some must stay singular and always available. Some should accumulate as searchable facts. Some belong only to the current planning thread. Weaviate Engram is the durable layer for that architecture. This chapter explains why transcript piles break personal assistants, how the Personalization template and user scopes fit one-human products, how bounded profiles and conversation summaries keep context cheap, how life-domain properties prevent hobby noise from hijacking work planning, and how a morning briefing loop should search, fetch, and write without blocking the user.

The design target is continuity without surveillance sludge. Remember what helps. Isolate what must never leak. Leave scratchpads out of long-term store.

Why does a productivity agent need more than a long chat history?

A calendar app stores events. A notes app stores documents. A chat agent stores turns. None of those automatically become a maintained model of the person. Raw conversations are noisy, contradictory, and expensive to replay. Frontier context windows do not fix that. Models still get lost in long middle sections, and every extra token is paid on every turn. Naively indexing every message for retrieval helps latency, but it leaves contradictions unresolved and treats a cancelled goal the same as an active one.

Productivity work needs structured long-term memory. Stable preferences such as “no meetings before ten” should survive for months. Active goals such as “finish the spring hive inspection checklist” should update as plans change. Thread summaries should compress a planning session without forcing the model to reread every message. Engram’s personalization path is built for that shape. Topics act as magnets. Pipelines extract, reconcile, and commit asynchronously. Search returns what is relevant now instead of everything that was ever said.

That raises the next design question. If the product may serve many people, how do you keep one user’s routines from ever appearing in another’s briefing?

How should user scope and the Personalization template anchor a one-human memory store?

Start with Engram’s Personalization template. It seeds a group with UserKnowledge for general facts about the person. That topic is user-scoped, so every write and search requires a user_id. Hard isolation is enforced by Weaviate multi-tenancy, not by a filter your application might forget. In a multi-tenant productivity product, that boundary is non-negotiable. Breakfast preferences for one household must never rank into another household’s grocery plan.

You can tighten magnets with custom topic descriptions. Separate goals from constraints. Separate communication style from schedule rules. The descriptions guide extraction, so “I hate dawn alarms” lands as preference rather than as a one-off complaint about Tuesday. Optional bounded topics deepen the architecture. A user profile topic can hold one canonical card per person for system-prompt injection. An optional ConversationSummary topic, scoped by conversation_id, keeps one running summary per planning thread and rewrites it in place as messages arrive.

If the same product also improves its coaching skill over time, keep that in a separate continual-learning group. Shared playbooks about how to break down goals can be project-wide. Personal life facts must stay user-scoped. Mixing both into one scope is how a productivity agent either leaks private context or refuses to get better for anyone.

How do bounded summaries and dual context keep morning briefings cheap?

After scopes are clear, token budget becomes the practical problem. Users do not want a novel every morning. They want a short briefing that still feels continuous. Engram’s dual-memory pattern fits well here. Keep the last few exchanges in the live prompt for pronouns and immediate follow-ups. Search Engram for durable facts that match today’s ask. When a running summary topic is enabled, fetch that bounded memory by topic and scope instead of hoping a hybrid query ranks it first.

Fetch retrieval matters for singular objects. A profile or conversation summary is not “maybe relevant.” It is the object you configured to be unique for that scope. Hybrid search remains the right tool for open questions such as “what did I say about evening deep work?” Vector and keyword signals both help when people paraphrase their own habits. Limit results aggressively. Productivity prompts degrade when ten weak memories crowd out the calendar truth for today.

Property scopes give a second control surface. Attach life_domain values such as work, home, or hobby on topics that need soft isolation. Include the property when planning a work block. Omit it when the user asks for a whole-life weekly review. The write path still enforces required properties for those topics. The read path chooses narrow or wide on purpose.

What does a personal productivity turn look like on Engram?

Imagine a seasonal planning agent for a backyard beekeeper. The person wants short morning plans, no guilt language, and hive tasks kept separate from office deadlines. The active planning thread has its own conversation id. Durable preferences live under the user id.

import os
from engram import EngramClient, Topic
from engram.types import HybridRetrieval, FetchRetrieval

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

person = "user.lena.moss"
thread = "apiary-season-planner-4"
domain = "hobby_apiary"

# Open-ended recall across this person's durable facts for the apiary domain.
habits = client.memories.search(
    query="Morning planning style, inspection cadence, weather constraints",
    user_id=person,
    group="default",
    retrieval_config=HybridRetrieval(limit=5),
    properties={"life_domain": domain},
    topics=["UserKnowledge"],
)

# Singular running summary for this planning thread, if the topic is enabled.
summary = client.memories.search(
    query="conversation summary",
    user_id=person,
    group="default",
    topics=["ConversationSummary"],
    properties={"conversation_id": thread},
    retrieval_config=FetchRetrieval(limit=1),
)

turn = [
    {
        "role": "user",
        "content": (
            "For apiary-season-planner-4, keep mornings short. No guilt tone. "
            "This week prioritize supers before packaging honey. Rain above "
            "forty percent means indoor frame repair only."
        ),
    },
    {
        "role": "assistant",
        "content": (
            "Got it. I will draft a short morning plan, skip guilt language, "
            "put supers ahead of packaging, and move to frame repair if rain "
            "odds exceed forty percent."
        ),
    },
]

run = client.memories.add(
    turn,
    user_id=person,
    group="default",
    properties={
        "conversation_id": thread,
        "life_domain": domain,
    },
)
print(run.run_id, run.status)
print("habits", [m.content for m in habits])
print("summary", [m.content for m in summary])

The search call loads durable style and constraint memories. The fetch-shaped summary call loads the thread’s singular synopsis without relevance ranking games. The add call returns immediately so the briefing can render while Engram extracts new facts and reconciles them with older ones. If rain thresholds change next week, reconciliation should supersede the stale rule rather than leave two conflicting memories fighting in retrieval.

String inputs still help for non-chat events. A calendar webhook can add a short string such as “Moved deep work to 14:00 on Thursdays.” Conversation inputs remain best for dialogue. Pre-extracted facts are reserved for cases where the product itself already decided the exact memory text, such as an explicit “remember this” control in the UI.

What should never become durable personal memory?

Architecture is also a refusal list. Transient mood vents, one-off logistics, and raw tool dumps should not all become lifelong facts. Topic descriptions are the first filter. If a magnet asks for goals and constraints, casual venting is less likely to stick. Product UX is the second filter. Offer explicit remember and forget actions for sensitive items. Treat deletions and corrections as first-class paths, because personal productivity data is intimate by definition.

Also keep external knowledge separate from Engram. Public how-to guides about beekeeping or timeboxing can live in a normal document index. Engram holds this person’s constraints and history. The agent merges both at answer time. That split keeps publishable advice out of the private memory bank and keeps private routines out of shared content stores.

A personal productivity agent with this Engram architecture starts the day already aware of tone, goals, and domain boundaries. It keeps summaries bounded, facts searchable, and users isolated. It writes asynchronously so memory never becomes an excuse for a spinning loader. Our next chapter, How should you design memory architecture for multi-turn sales and CRM agents?, moves from one person’s private life to multi-turn commercial relationships, where account history, stakeholder preferences, and pipeline stage memory must stay accurate under much stricter CRM isolation rules.