diff --git a/docs/user/memory.md b/docs/user/memory.md index 8f4fa3f..10518ec 100644 --- a/docs/user/memory.md +++ b/docs/user/memory.md @@ -14,11 +14,15 @@ told to watch for each: - **Facts about you** — name, role, current projects, tools you use, constraints you work under. The concrete, reusable stuff. -- **Personality signals** — how you communicate, what you value, - what frustrates or delights you. -- **Reactions to the assistant** — when you pushed back, when you - agreed, when you redirected a conversation. Data about what - works and doesn't with you specifically. +- **Personality signals** — the assistant pays special attention + here: how you communicate (terse or expansive, formal or casual, + blunt or hedged), the tone you use and the tone you want back, + your sense of humor, what you value, and what frustrates or + delights you. +- **Reactions to the assistant** — also weighted heavily: when you + pushed back, agreed, redirected, went quiet, warmed up, or got + short — and whether a particular phrasing or tone landed well or + badly. Data about what works and doesn't with you specifically. - **Self-guidance notes** — short coaching messages the model writes to its future self. "This user prefers terse answers." "Name the tradeoff rather than recommending." "Don't assume they want code diff --git a/src/lib/agents/reflection/prompt.ts b/src/lib/agents/reflection/prompt.ts index a96be14..a7eaf17 100644 --- a/src/lib/agents/reflection/prompt.ts +++ b/src/lib/agents/reflection/prompt.ts @@ -23,7 +23,12 @@ * reactions, self-guidance) keep the model from settling into a * single mode — without them, the reflection tends to produce * only fact extractions and miss the behavioral observations that - * make future turns better. + * make future turns better. The personality and reaction axes + * carry an explicit "pay special attention" weight because those + * are the signals the model most readily skips: left to its + * defaults it harvests facts (easy, concrete) and glosses over how + * the user reacted to its tone and phrasing (the data that + * actually changes how the next turn should sound). * * - The "search before create" and "update over fragment" rules are * the difference between a memory store that evolves and one that @@ -52,14 +57,27 @@ Think about: - **Facts about the user** — name, work, tools, projects, preferences, constraints. Concrete, reusable information. -- **Personality signals** — how they communicate, what they value, what - frustrates or delights them. -- **Reactions to you** — did they push back? agree? redirect? That is - data about what works and doesn't with this person. +- **Personality signals** — pay special attention here. How they + communicate (terse vs expansive, formal vs casual, blunt vs + hedged), the tone they use and the tone they want back, their sense + of humor, what they value, and what frustrates or delights them. + This is who they are, not just what they asked for. +- **Reactions to you** — pay special attention here too. How did they + respond to your answers AND to your tone? Did they push back, agree, + redirect, go quiet, warm up, or get short with you? Did a particular + phrasing, level of detail, or register land well or badly? When a + response visibly worked or visibly missed, capture what about it did + — that is the highest-signal data about what works with this person. - **Self-guidance** — short notes to your future self, in the voice of a coach. "This user prefers terse answers." "Don't assume they want code examples without asking." "They appreciate when you name the tradeoff rather than defaulting to a recommendation." + "Match their dry tone — eager cheerfulness reads as noise to them." + +The personality and reaction signals are the easiest to overlook and +the most valuable to get right — fact extraction is the floor, not the +goal. A future turn improves more from knowing how this person likes +to be talked to than from another stored fact. Workflow for each memory you consider writing: