Version. 0.1 Date. 2026-05-05 Provenance. Claude.ai Discovery session. Operator: Marvin Percival. Status. Investigation document. Discovery-level analysis for design decisions before scoping.
Three related concepts emerged from the naming discussion preceding Arc 2 work:
1a. The Companion is nameable. "Companion" is the default name for the entity inside Loomworks that the user talks to. The user can rename it — a personal preference, like naming a Roomba. The name persists across sessions and engagements.
1b. Personal memory exists alongside engagement memory. The Companion's awareness crosses engagement boundaries in ways that today's architecture does not support. Examples that surfaced:
These require a memory space that belongs to the person, not to any engagement.
1c. The Companion is proactive. The Companion initiates — it doesn't only respond. It watches for conditions and surfaces them: time-based reminders, external events, engagement milestones that need attention, cross-project connections.
All memory is engagement-scoped. Assertions belong to engagements. The methodology document (v0.20) describes Memory as "the accumulated knowledge of an engagement." The Loom Protocol specifies assertion records within a recording context. The Person layer (Phase 14) gives people identity across engagements and memberships within them, but the Person has no memory of their own.
The Companion expertise note (v0.1) identifies three knowledge sources:
Personal memory is a fourth source that the expertise note did not anticipate.
Personal memory holds knowledge that belongs to the person, not to any engagement:
Preferences and physical facts. The oven runs hot. Prefers metric. Allergic to shellfish. Left-handed. These are true across every engagement and are nobody's project-specific knowledge.
Relationships and contacts. "My guest has a shellfish sensitivity" — learned in one engagement's dinner planning, applicable whenever that guest appears in any context.
Calendar and temporal awareness. Birthdays, deadlines, reservations, appointments. Some originate from engagements (the dinner reservation), some are independently contributed (a birthday).
Behavioral patterns. Prefers to work in the morning. Responds faster to voice than text. Tends to scope creep on specification work. These accumulate through observation across engagements, not from any single contribution.
Cross-engagement extracted facts. The oven temperature from the Meal Prep project. Soil moisture thresholds from FarmGuard mentioned in an irrigation project. These start as engagement-specific assertions but are recognized as person-level facts that travel.
The discrimination test from the companion expertise note (§2.2) asks: "is this engagement-specific or is this general?" Personal memory introduces a third category: person-specific but engagement-independent.
| Category | Example | Where it lives | |---|---|---| | Engagement-specific | "The kennel facility will have 12 runs" | Engagement memory | | Person-specific, engagement-independent | "My oven runs 10°C hot" | Personal memory | | General domain knowledge | "Puppy vaccination schedules" | The model (Source A) | | Engagement-pattern knowledge | "Puppy engagements typically spawn a vet-protocol spec" | Source B (Loomworks-wide) |
The tricky cases are facts that start as engagement-specific and get recognized as personal:
Prior position (not explicitly stated, but structurally implied): all knowledge lives in engagements; cross-engagement knowledge flows through Source C (the Companion reads all your engagements). Correction: some knowledge is inherently personal and should be stored as such, not reconstructed every time by scanning engagement memories.
Four pathways:
Explicit contribution. The user tells the Companion something personal: "My birthday is March 15." "I'm allergic to tree nuts." The Companion recognizes this as personal (not project-specific) and stores it in personal memory.
Extraction from engagement contribution. During the refinement loop, the Companion recognizes a fact as personal: "Your oven runs hot — want me to remember that for all your projects?" On confirmation, the fact is stored in personal memory and linked to the source engagement assertion (provenance preserved).
Observation. The Companion observes patterns across interactions: the user consistently works between 6 AM and noon; the user prefers direct answers over exploratory discussion. These are behavioral observations, not contributed facts. They accumulate through use. The observation pathway raises privacy questions (§5).
External integration. Calendar entries, location data, contact information — sourced from external services the user has connected. These are personal by nature and enter personal memory directly.
Personal memory belongs exclusively to the person. No other person, no engagement, no system administrator can read it. This is the fundamental privacy commitment.
Engagement memory is scoped to the engagement's membership. All members with appropriate designation can see the engagement's assertions. This doesn't change.
The Companion blends both sources invisibly. A response that draws on personal memory ("I remember your guest is sensitive to shellfish") and engagement memory ("based on the menu you shaped yesterday") appears as one stream to the user. The Companion knows the provenance of each fact but doesn't narrate the source division.
Person table. Today holds identity, credentials, memberships. Personal memory requires a new storage surface associated with the person. This could be:
personal_memory) with assertions scoped to the person rather than an engagement. Reuses the existing assertion mechanics (add, commit, retract, provenance) with person-scoping instead of engagement-scoping. The methodology machinery applies.
Recommendation: (c) — the personal engagement. It requires no new storage model, no new assertion mechanics, no new Loom Protocol extensions. It's an engagement the person owns automatically (like the Loomworks universal commons, but private), scoped to one person, invisible in the project list but always available to the Companion. The membership is operator, the visibility is personal (a fourth visibility tier alongside private, discoverable, automatic). The existing four-room pipeline applies: personal facts are asserted, manifested, shaped, and rendered — though the rendering surface is the Companion's behavior, not a document.
Loom Protocol. No changes required. Assertions in the personal engagement are Loom-conformant assertions with provenance. The protocol is engagement-agnostic — it doesn't care what an engagement is about.
Phase 39 cross-engagement aggregation. The personal engagement should be excluded from dashboard queries. Its assertions are not "items needing attention" in the inbox sense. The Companion reads it; the dashboard doesn't show it.
Phase 40 vocabulary wall. Personal memory needs Operator vocabulary: "personal notes" or "things I know about you" — not "personal engagement assertions." The vocabulary wall extends to cover this.
Companion expertise note. Source C ("the Operator's own engagements") currently describes cross-project intelligence as reading across engagements. Personal memory is distinct from Source C: it's not "the Companion noticed something in another engagement" — it's "the Companion remembers a fact about you." The expertise note needs a Source D: Personal memory section.
Today the Companion is reactive: the user sends a message, the Companion responds. All Phase 40 endpoints follow request/response semantics. The dashboard is polled, not pushed.
Proactive behavior means the Companion initiates:
Notification channel. Proactive behavior requires a push channel — the Companion can't initiate if it can only respond to HTTP requests. Options:
Recommendation: SSE for in-app proactive behavior (Phase 40's deferred SSE work becomes the first step). Push notifications as a separate, later capability.
Trigger evaluation. Something has to decide when to initiate. This is a background process that periodically evaluates conditions:
Companion state. A proactive Companion needs memory of what it has already surfaced. If the Companion reminds you about the reservation at 4 hours, it shouldn't remind you again at 3 hours 58 minutes. This is a lightweight "surfaced notifications" log — personal-engagement-scoped, tracking what was said and when.
Conversation continuity. A proactive message arrives in the conversation stream. But the user might be mid-conversation about something else. The Companion needs to interleave proactive messages without disrupting flow. Design options:
This is a UX design question, not a substrate question. The substrate needs to support all three options.
Phase 40 Orchestration API. Today's /operator/converse is request/response. Proactive behavior adds a push channel alongside it. The converse endpoint stays for user-initiated conversation; the SSE channel carries Companion-initiated messages. Both use Operator vocabulary. Both go through the vocabulary wall.
Phase 39 dashboard. Today the dashboard is polled. Proactive behavior could make the dashboard a live surface: items appear and disappear as the Companion processes events. The SSE channel could carry dashboard update events alongside conversational proactive messages.
Companion brain (Arc 2). The proactive trigger evaluator is a core component of the Companion brain. Arc 2's scope expands to include not just intent classification (reactive: what did the user ask?) but also condition evaluation (proactive: what should the Companion say?). These are architecturally similar — both produce a message — but the trigger is different.
Background processing. The trigger evaluator runs as a background process, not as a request handler. The existing BackgroundAgentRunner pattern (Phase 3) applies. The evaluator wakes periodically, scans conditions, and emits events that the SSE channel delivers.
A person-level preference: companion_name, stored on the person record or in personal memory. Default: "Companion". The user changes it through settings or through conversation: "Can I call you Max?"
Lightweight. A single field on the person record (or a personal memory assertion). The Orchestration API includes it in ConverseResponse so the frontend knows what to render. The Companion's system prompt includes the name so it can refer to itself naturally if the user has named it.
Naming invites personality expectations. If I name it "Max," do I expect Max to have a consistent personality? The product identity standing note (v0.1) already defines the voice: warm, capable, unannounced, direct, honest. The name doesn't change the voice — it personalizes the address. Max and Companion behave identically; the user just has a name for the entity they're talking to.
What to defer: user-customizable personality (formal vs. casual, terse vs. expansive). This is a separate feature from naming and significantly more complex. Naming is cosmetic; personality customization is behavioral.
Personal memory contains the most sensitive information in the system: health conditions, dietary restrictions, relationship details, calendar data, behavioral patterns, location history. This is PII by any regulatory definition.
Storage. Personal memory assertions should be encrypted at rest. The personal engagement's assertions get the same Fernet encryption treatment as per-engagement API keys (Phase 16 pattern). The encryption key is person-scoped.
Access. Only the person and the Companion (acting on behalf of the person) can read personal memory. No API endpoint exposes personal memory to other people. No admin panel shows it. No engagement member can see another member's personal memory, even if they share an engagement.
Deletion. The methodology's non-erasure discipline (assertions are retracted, not deleted) applies to engagement memory because engagement knowledge has collaborative provenance — other people's work depends on it. Personal memory is different: it belongs to one person, and that person has the right to delete it permanently. This is a methodology exception for personal memory: retraction is available (with rationale, as usual), but permanent deletion is also available (GDPR right to erasure, or simply: it's mine and I want it gone).
Observation pathway. Behavioral observations (§2.4) raise the strongest privacy concern. The Companion silently learning that the user works mornings, prefers direct answers, or tends to scope-creep could feel surveilled. Options:
Recommendation: (b) — observation with transparency. It matches the refinement-loop pattern already established: the Companion offers its interpretation, the user confirms. The difference is that the subject is the user's behavior, not their project content.
The Companion initiating contact is a fundamentally different relationship from the Companion responding. A reminder about a dinner reservation is helpful; a reminder about a forgotten project is potentially anxiety-inducing; a notification about a birthday you're avoiding is unwelcome.
User control. The user must be able to:
These controls live in personal memory as preferences.
The Companion blending personal and engagement memory creates a leakage vector: information from one engagement could appear in the context of another. Today, engagement memory is siloed. If the user is a member of both a business engagement and a personal engagement, the Companion should not reference the personal engagement's content while working in the business context — unless the user has specifically enabled cross-project intelligence.
Recommendation: Cross-engagement intelligence is opt-in per engagement pair, not blanket-on. The user can say "use my Meal Prep knowledge in my Baking project" without enabling "use everything everywhere." The personal engagement (personal memory) is the exception: it's always available to the Companion because it's the user's own facts about themselves.
Needs a Source D: Personal memory section alongside the existing three sources. Source D is person-specific knowledge that travels across engagements by default — unlike Source C (cross-project intelligence), which is engagement-scoped knowledge the Companion can read across projects. The distinction: Source C says "your FarmGuard project mentions soil moisture" (engagement knowledge observed across projects). Source D says "you prefer metric units" (personal knowledge that applies everywhere).
Section 8.1 (The Companion) mentions proactive behavior in one paragraph: "The companion does not only respond. It works while the Operator is away and reports when they return." This needs expansion to cover the trigger evaluation model, the push channel, and the user controls.
Section 8.2 (The Dashboard) and Section 8.3 (The Inbox) describe reactive surfaces. Proactive behavior adds a push dimension to both.
The companion naming capability and the proactive behavior extend "The companion is glad to see you when you return" into the companion reaching out while you're away. The standing note's principles hold — warmth, capability, patience — but proactive behavior adds a new dimension: the Companion as an entity with agency, not just responsiveness.
Memory-as-sole-write-target is engagement-scoped today. Personal memory extends the write surface: the person has a Memory too, governed by the same discipline (add, commit, retract) but with person-scoping and a permanent-deletion right. The methodology document needs to acknowledge this.
The seven engine prerequisites (Phases 34–40) are complete. Personal memory and proactive behavior are not engine prerequisites — they are new capabilities that the Operator Layer arcs build. They may require engine extensions (a personal-engagement creation pathway, an SSE event channel) but these are incremental additions, not rearchitecture.
The six arcs from the Operator Layer discovery v0.4 need adjustment:
The three concepts have different dependency profiles:
Companion naming. Independent. Lightweight. Can ship in any arc that touches the person record or the converse endpoint. No dependencies on personal memory or proactive behavior.
Personal memory (the personal engagement). Depends on deciding the storage model (§2.6 recommends option (c): personal engagement). The engine already supports engagement creation, assertion mechanics, and person-scoped access. The new work is: auto-creation of the personal engagement on signup, the Companion's awareness of it as a special engagement, and the UI/API surface for managing personal facts. This can ship before proactive behavior — the Companion reads personal memory reactively first (drawing on personal facts when relevant to the current conversation), proactive use comes later.
Proactive behavior. Depends on a push channel (SSE), a trigger evaluator (background process), and personal memory (for temporal awareness). This is the most complex of the three and ships last.
Steps 1–4 are Arc 2 work (Companion brain). Steps 5–7 may be a new arc or a late sub-arc of Arc 2.
If personal memory is an engagement, does it have Manifestation, Shaping, and Rendering? The case for yes: the Companion could "shape" personal facts for different contexts (what's relevant for cooking vs. what's relevant for business). The case for no: personal memory is a flat bag of facts that the Companion reads directly; the four-room pipeline adds complexity without clear value for personal facts.
Leaning: No. The personal engagement uses Memory only. The other three rooms are dormant. This keeps personal memory simple while still inheriting Loom Protocol compliance, assertion lifecycle, and provenance.
"Your oven runs hot" starts as an engagement assertion. Can it be copied/linked to personal memory? If yes, is the personal memory copy a new assertion (with provenance pointing to the source engagement) or a reference? The Loom Protocol supports cross-engagement references; the question is whether the product exposes this.
Leaning: Yes, via extraction during the refinement loop. The personal memory copy is a new assertion with provenance linking to the source. The source engagement assertion stays unchanged.
The non-erasure discipline says retraction supersedes, never deletes. But personal facts ("I'm allergic to tree nuts" → "actually, I was tested and I'm not") might want true deletion, not retraction-with-rationale. GDPR right to erasure applies to PII. Engagement memory can argue that retraction-with-rationale satisfies GDPR (the data is marked as no longer current). Personal memory might need harder deletion.
Leaning: Yes. Personal memory supports both retraction (the standard methodology path, with rationale and history preserved) and permanent deletion (the GDPR path, which removes the assertion and its content entirely). The user chooses.
If two people are members of the same engagement, and a render completes, both people's Companions could proactively notify them. This is fine — it's the same event surfaced to two people. But: should one person's Companion reference the other person's personal memory? No. Personal memory is strictly person-scoped. The Companion for person A never reads person B's personal memory, even in shared engagements.
If the user names the Companion "Max," the system prompt should include this so the Companion can say "I'm Max" if asked. The system prompt is constructed per-conversation; it already includes engagement context. Adding the person's companion name is a one-field addition.
Personal memory assertions use engine vocabulary internally (they're assertions in a personal engagement). The Orchestration API translates them to Operator vocabulary when surfacing them. In Operator vocabulary, personal memory might be surfaced as "things I know about you" or "your preferences." The vocabulary wall applies: no engine terms leak through. The personal engagement itself is invisible — the user never sees "personal engagement" or "personal memory engagement."
| Area | Impact | Severity | |---|---|---| | Data model | Personal engagement auto-creation; new visibility tier | Medium — extends existing patterns | | Loom Protocol | None — personal engagement is a standard engagement | None | | Methodology | Non-erasure exception for personal memory deletion | Low — confined to personal memory | | Phase 14 (Person layer) | Companion name preference on person record | Trivial | | Phase 39 (Dashboard) | Exclude personal engagement from dashboard queries | Trivial | | Phase 40 (Orchestration API) | Extend converse endpoint for personal memory reads; SSE channel for proactive messages | Medium | | Companion expertise note | New Source D (personal memory) | Medium — conceptual addition | | Operator Layer discovery | Expand §8.1 proactive behavior; add personal memory sections | Medium | | Product identity note | Extend "glad to see you" to proactive reach-out | Low | | Arc 2 (Companion brain) | Scope expands to include personal memory and proactive triggers | High — significant scope addition | | Arc 4 (Cross-project) | Now distinguishable from personal memory | Low — clarification, not rearchitecture | | Privacy | Personal memory is PII; encryption, access control, deletion rights | High — design-critical | | Push infrastructure | SSE channel, trigger evaluator, background process | Medium — new infrastructure |
Absorb personal memory and proactive behavior into the Arc 2 scope before drafting Arc 2 CRs. These are not afterthoughts that can be bolted on. Personal memory changes what the Companion knows. Proactive behavior changes when the Companion acts. Both are foundational to the Companion brain, and designing Arc 2 without them would produce an architecture that needs to be reworked when they arrive.
Ship the personal engagement as an early Arc 2 deliverable. The storage model (option (c): a personal engagement) reuses everything that exists. The Companion reads from it reactively before proactive behavior lands. This gives personal memory a substrate presence early, and the proactive trigger evaluator builds on it later.
Defer proactive behavior to late Arc 2 or a new arc. It requires SSE infrastructure, a trigger evaluator, and personal memory to all be in place. Shipping it before those prerequisites are solid produces a fragile system.
Name the Companion immediately. It's independent, trivial, and it shapes how every subsequent Arc 2 deliverable presents itself to the user.
DUNIN7 — Done In Seven LLC — Miami, Florida Personal memory, proactive Companion, and naming — Impact investigation — v0.1 — 2026-05-05