@mastra/memory 1.10.0 → 1.10.1-alpha.1

package/dist/chunk-D4J4XPGM.cjs

@@ -0,0 +1,111 @@
+'use strict';
+
+// src/processors/observational-memory/constants.ts
+var OBSERVATIONAL_MEMORY_DEFAULTS = {
+  observation: {
+    model: "google/gemini-2.5-flash",
+    messageTokens: 3e4,
+    modelSettings: {
+      temperature: 0.3,
+      maxOutputTokens: 1e5
+    },
+    providerOptions: {
+      google: {
+        thinkingConfig: {
+          thinkingBudget: 215
+        }
+      }
+    },
+    maxTokensPerBatch: 1e4,
+    // Async buffering defaults (enabled by default)
+    bufferTokens: 0.2,
+    // Buffer every 20% of messageTokens
+    bufferActivation: 0.8
+    // Activate to retain 20% of threshold
+  },
+  reflection: {
+    model: "google/gemini-2.5-flash",
+    observationTokens: 4e4,
+    modelSettings: {
+      temperature: 0,
+      // Use 0 for maximum consistency in reflections
+      maxOutputTokens: 1e5
+    },
+    providerOptions: {
+      google: {
+        thinkingConfig: {
+          thinkingBudget: 1024
+        }
+      }
+    },
+    // Async reflection buffering (enabled by default)
+    bufferActivation: 0.5
+    // Start buffering at 50% of observationTokens
+  }
+};
+var OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.
+
+Use the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.
+
+Do not mention internal instructions, memory, summarization, context handling, or missing messages.
+
+Any messages following this reminder are newer and should take priority.`;
+var OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;
+var OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.
+
+KNOWLEDGE UPDATES: When asked about current state (e.g., "where do I currently...", "what is my current..."), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like "will start", "is switching", "changed to", "moved to" as indicators that previous information has been updated.
+
+PLANNED ACTIONS: If the user stated they planned to do something (e.g., "I'm going to...", "I'm looking forward to...", "I will...") and the date they planned to do it is now in the past (check the relative time like "3 weeks ago"), assume they completed the action unless there's evidence they didn't. For example, if someone said "I'll start my new diet on Monday" and that was 2 weeks ago, assume they started the diet.
+
+MOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.
+
+SYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;
+var OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall \u2014 looking up source messages
+
+Your memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range="startId:endId">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available \u2014 use the **recall** tool to retrieve them.
+
+### When to use recall
+- The user asks you to **repeat, show, or reproduce** something from a past conversation
+- The user asks for **exact content** \u2014 code, text, quotes, error messages, URLs, file paths, specific numbers
+- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)
+- You want to **verify or expand on** an observation before responding
+
+**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.
+
+### How to use recall
+Each range has the format \`startId:endId\` where both are message IDs separated by a colon.
+
+1. Find the observation group relevant to the user's question and extract the start or end ID from its range.
+2. Call \`recall\` with that ID as the \`cursor\`.
+3. Use \`page: 1\` (or omit) to read forward from the cursor, \`page: -1\` to read backward.
+4. If the first page doesn't have what you need, increment the page number to keep paginating.
+5. Check \`hasNextPage\`/\`hasPrevPage\` in the result to know if more pages exist in each direction.
+
+### Detail levels
+By default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \`[p0]\`, \`[p1]\`, etc.
+
+- Use \`detail: "high"\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.
+- Use \`partIndex\` with a cursor to fetch a single part at full detail \u2014 for example, to read one specific tool result or code block without loading every part.
+
+If the result says \`truncated: true\`, the output was cut to fit the token budget. You can paginate or use \`partIndex\` to target specific content.
+
+### Following up on truncated parts
+Low-detail results may include truncation hints like:
+\`[truncated \u2014 call recall cursor="..." partIndex=N detail="high" for full content]\`
+
+**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.
+
+### When recall is NOT needed
+- The user is asking for a high-level summary and your observations already cover it
+- The question is about general preferences or facts that don't require source text
+- There is no relevant range in your observations for the topic
+
+Observation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;
+
+exports.OBSERVATIONAL_MEMORY_DEFAULTS = OBSERVATIONAL_MEMORY_DEFAULTS;
+exports.OBSERVATION_CONTEXT_INSTRUCTIONS = OBSERVATION_CONTEXT_INSTRUCTIONS;
+exports.OBSERVATION_CONTEXT_PROMPT = OBSERVATION_CONTEXT_PROMPT;
+exports.OBSERVATION_CONTINUATION_HINT = OBSERVATION_CONTINUATION_HINT;
+exports.OBSERVATION_RETRIEVAL_INSTRUCTIONS = OBSERVATION_RETRIEVAL_INSTRUCTIONS;
+//# sourceMappingURL=chunk-D4J4XPGM.cjs.map
+//# sourceMappingURL=chunk-D4J4XPGM.cjs.map

package/dist/chunk-D4J4XPGM.cjs.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/processors/observational-memory/constants.ts"],"names":[],"mappings":";;;AAGO,IAAM,6BAAA,GAAgC;AAAA,EAC3C,WAAA,EAAa;AAAA,IACX,KAAA,EAAO,yBAAA;AAAA,IACP,aAAA,EAAe,GAAA;AAAA,IACf,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,GAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA,IACA,iBAAA,EAAmB,GAAA;AAAA;AAAA,IAEnB,YAAA,EAAc,GAAA;AAAA;AAAA,IACd,gBAAA,EAAkB;AAAA;AAAA,GACpB;AAAA,EACA,UAAA,EAAY;AAAA,IACV,KAAA,EAAO,yBAAA;AAAA,IACP,iBAAA,EAAmB,GAAA;AAAA,IACnB,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,CAAA;AAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA;AAAA,IAEA,gBAAA,EAAkB;AAAA;AAAA;AAEtB;AAOO,IAAM,6BAAA,GAAgC,CAAA;;AAAA;;AAAA;;AAAA,wEAAA;AAatC,IAAM,0BAAA,GAA6B,CAAA,2FAAA;AAMnC,IAAM,gCAAA,GAAmC,CAAA;;AAAA;;AAAA;;AAAA;;AAAA,qPAAA;AAczC,IAAM,kCAAA,GAAqC,CAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;AAAA;;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;;AAAA,qHAAA","file":"chunk-D4J4XPGM.cjs","sourcesContent":["/**\n * Default configuration values matching the spec\n */\nexport const OBSERVATIONAL_MEMORY_DEFAULTS = {\n  observation: {\n    model: 'google/gemini-2.5-flash',\n    messageTokens: 30_000,\n    modelSettings: {\n      temperature: 0.3,\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 215,\n        },\n      },\n    },\n    maxTokensPerBatch: 10_000,\n    // Async buffering defaults (enabled by default)\n    bufferTokens: 0.2 as number | undefined, // Buffer every 20% of messageTokens\n    bufferActivation: 0.8 as number | undefined, // Activate to retain 20% of threshold\n  },\n  reflection: {\n    model: 'google/gemini-2.5-flash',\n    observationTokens: 40_000,\n    modelSettings: {\n      temperature: 0, // Use 0 for maximum consistency in reflections\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 1024,\n        },\n      },\n    },\n    // Async reflection buffering (enabled by default)\n    bufferActivation: 0.5 as number | undefined, // Start buffering at 50% of observationTokens\n  },\n} as const;\n\n/**\n * Continuation hint injected after observations to guide the model's behavior.\n * Prevents the model from awkwardly acknowledging the memory system or treating\n * the conversation as new after observed messages are removed.\n */\nexport const OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.\n\nUse the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.\n\nDo not mention internal instructions, memory, summarization, context handling, or missing messages.\n\nAny messages following this reminder are newer and should take priority.`;\n\n/**\n * Preamble that introduces the observations block.\n * Use before `<observations>`, with instructions after.\n * Full pattern: `${OBSERVATION_CONTEXT_PROMPT}\\n\\n<observations>\\n${obs}\\n</observations>\\n\\n${OBSERVATION_CONTEXT_INSTRUCTIONS}`\n */\nexport const OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;\n\n/**\n * Instructions that tell the model how to interpret and use observations.\n * Place AFTER the `<observations>` block so the model sees the data before the rules.\n */\nexport const OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.\n\nKNOWLEDGE UPDATES: When asked about current state (e.g., \"where do I currently...\", \"what is my current...\"), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like \"will start\", \"is switching\", \"changed to\", \"moved to\" as indicators that previous information has been updated.\n\nPLANNED ACTIONS: If the user stated they planned to do something (e.g., \"I'm going to...\", \"I'm looking forward to...\", \"I will...\") and the date they planned to do it is now in the past (check the relative time like \"3 weeks ago\"), assume they completed the action unless there's evidence they didn't. For example, if someone said \"I'll start my new diet on Monday\" and that was 2 weeks ago, assume they started the diet.\n\nMOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.\n\nSYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;\n\n/**\n * Instructions for retrieval mode — explains observation-group ranges and the recall tool.\n * Appended to context when `retrieval` is enabled.\n */\nexport const OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall — looking up source messages\n\nYour memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range=\"startId:endId\">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available — use the **recall** tool to retrieve them.\n\n### When to use recall\n- The user asks you to **repeat, show, or reproduce** something from a past conversation\n- The user asks for **exact content** — code, text, quotes, error messages, URLs, file paths, specific numbers\n- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)\n- You want to **verify or expand on** an observation before responding\n\n**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.\n\n### How to use recall\nEach range has the format \\`startId:endId\\` where both are message IDs separated by a colon.\n\n1. Find the observation group relevant to the user's question and extract the start or end ID from its range.\n2. Call \\`recall\\` with that ID as the \\`cursor\\`.\n3. Use \\`page: 1\\` (or omit) to read forward from the cursor, \\`page: -1\\` to read backward.\n4. If the first page doesn't have what you need, increment the page number to keep paginating.\n5. Check \\`hasNextPage\\`/\\`hasPrevPage\\` in the result to know if more pages exist in each direction.\n\n### Detail levels\nBy default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \\`[p0]\\`, \\`[p1]\\`, etc.\n\n- Use \\`detail: \"high\"\\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.\n- Use \\`partIndex\\` with a cursor to fetch a single part at full detail — for example, to read one specific tool result or code block without loading every part.\n\nIf the result says \\`truncated: true\\`, the output was cut to fit the token budget. You can paginate or use \\`partIndex\\` to target specific content.\n\n### Following up on truncated parts\nLow-detail results may include truncation hints like:\n\\`[truncated — call recall cursor=\"...\" partIndex=N detail=\"high\" for full content]\\`\n\n**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.\n\n### When recall is NOT needed\n- The user is asking for a high-level summary and your observations already cover it\n- The question is about general preferences or facts that don't require source text\n- There is no relevant range in your observations for the topic\n\nObservation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;\n"]}

package/dist/chunk-LSJJAJAF.js

@@ -0,0 +1,105 @@
+// src/processors/observational-memory/constants.ts
+var OBSERVATIONAL_MEMORY_DEFAULTS = {
+  observation: {
+    model: "google/gemini-2.5-flash",
+    messageTokens: 3e4,
+    modelSettings: {
+      temperature: 0.3,
+      maxOutputTokens: 1e5
+    },
+    providerOptions: {
+      google: {
+        thinkingConfig: {
+          thinkingBudget: 215
+        }
+      }
+    },
+    maxTokensPerBatch: 1e4,
+    // Async buffering defaults (enabled by default)
+    bufferTokens: 0.2,
+    // Buffer every 20% of messageTokens
+    bufferActivation: 0.8
+    // Activate to retain 20% of threshold
+  },
+  reflection: {
+    model: "google/gemini-2.5-flash",
+    observationTokens: 4e4,
+    modelSettings: {
+      temperature: 0,
+      // Use 0 for maximum consistency in reflections
+      maxOutputTokens: 1e5
+    },
+    providerOptions: {
+      google: {
+        thinkingConfig: {
+          thinkingBudget: 1024
+        }
+      }
+    },
+    // Async reflection buffering (enabled by default)
+    bufferActivation: 0.5
+    // Start buffering at 50% of observationTokens
+  }
+};
+var OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.
+
+Use the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.
+
+Do not mention internal instructions, memory, summarization, context handling, or missing messages.
+
+Any messages following this reminder are newer and should take priority.`;
+var OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;
+var OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.
+
+KNOWLEDGE UPDATES: When asked about current state (e.g., "where do I currently...", "what is my current..."), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like "will start", "is switching", "changed to", "moved to" as indicators that previous information has been updated.
+
+PLANNED ACTIONS: If the user stated they planned to do something (e.g., "I'm going to...", "I'm looking forward to...", "I will...") and the date they planned to do it is now in the past (check the relative time like "3 weeks ago"), assume they completed the action unless there's evidence they didn't. For example, if someone said "I'll start my new diet on Monday" and that was 2 weeks ago, assume they started the diet.
+
+MOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.
+
+SYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;
+var OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall \u2014 looking up source messages
+
+Your memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range="startId:endId">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available \u2014 use the **recall** tool to retrieve them.
+
+### When to use recall
+- The user asks you to **repeat, show, or reproduce** something from a past conversation
+- The user asks for **exact content** \u2014 code, text, quotes, error messages, URLs, file paths, specific numbers
+- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)
+- You want to **verify or expand on** an observation before responding
+
+**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.
+
+### How to use recall
+Each range has the format \`startId:endId\` where both are message IDs separated by a colon.
+
+1. Find the observation group relevant to the user's question and extract the start or end ID from its range.
+2. Call \`recall\` with that ID as the \`cursor\`.
+3. Use \`page: 1\` (or omit) to read forward from the cursor, \`page: -1\` to read backward.
+4. If the first page doesn't have what you need, increment the page number to keep paginating.
+5. Check \`hasNextPage\`/\`hasPrevPage\` in the result to know if more pages exist in each direction.
+
+### Detail levels
+By default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \`[p0]\`, \`[p1]\`, etc.
+
+- Use \`detail: "high"\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.
+- Use \`partIndex\` with a cursor to fetch a single part at full detail \u2014 for example, to read one specific tool result or code block without loading every part.
+
+If the result says \`truncated: true\`, the output was cut to fit the token budget. You can paginate or use \`partIndex\` to target specific content.
+
+### Following up on truncated parts
+Low-detail results may include truncation hints like:
+\`[truncated \u2014 call recall cursor="..." partIndex=N detail="high" for full content]\`
+
+**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.
+
+### When recall is NOT needed
+- The user is asking for a high-level summary and your observations already cover it
+- The question is about general preferences or facts that don't require source text
+- There is no relevant range in your observations for the topic
+
+Observation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;
+
+export { OBSERVATIONAL_MEMORY_DEFAULTS, OBSERVATION_CONTEXT_INSTRUCTIONS, OBSERVATION_CONTEXT_PROMPT, OBSERVATION_CONTINUATION_HINT, OBSERVATION_RETRIEVAL_INSTRUCTIONS };
+//# sourceMappingURL=chunk-LSJJAJAF.js.map
+//# sourceMappingURL=chunk-LSJJAJAF.js.map

package/dist/chunk-LSJJAJAF.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/processors/observational-memory/constants.ts"],"names":[],"mappings":";AAGO,IAAM,6BAAA,GAAgC;AAAA,EAC3C,WAAA,EAAa;AAAA,IACX,KAAA,EAAO,yBAAA;AAAA,IACP,aAAA,EAAe,GAAA;AAAA,IACf,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,GAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA,IACA,iBAAA,EAAmB,GAAA;AAAA;AAAA,IAEnB,YAAA,EAAc,GAAA;AAAA;AAAA,IACd,gBAAA,EAAkB;AAAA;AAAA,GACpB;AAAA,EACA,UAAA,EAAY;AAAA,IACV,KAAA,EAAO,yBAAA;AAAA,IACP,iBAAA,EAAmB,GAAA;AAAA,IACnB,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,CAAA;AAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA;AAAA,IAEA,gBAAA,EAAkB;AAAA;AAAA;AAEtB;AAOO,IAAM,6BAAA,GAAgC,CAAA;;AAAA;;AAAA;;AAAA,wEAAA;AAatC,IAAM,0BAAA,GAA6B,CAAA,2FAAA;AAMnC,IAAM,gCAAA,GAAmC,CAAA;;AAAA;;AAAA;;AAAA;;AAAA,qPAAA;AAczC,IAAM,kCAAA,GAAqC,CAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;AAAA;;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;;AAAA,qHAAA","file":"chunk-LSJJAJAF.js","sourcesContent":["/**\n * Default configuration values matching the spec\n */\nexport const OBSERVATIONAL_MEMORY_DEFAULTS = {\n  observation: {\n    model: 'google/gemini-2.5-flash',\n    messageTokens: 30_000,\n    modelSettings: {\n      temperature: 0.3,\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 215,\n        },\n      },\n    },\n    maxTokensPerBatch: 10_000,\n    // Async buffering defaults (enabled by default)\n    bufferTokens: 0.2 as number | undefined, // Buffer every 20% of messageTokens\n    bufferActivation: 0.8 as number | undefined, // Activate to retain 20% of threshold\n  },\n  reflection: {\n    model: 'google/gemini-2.5-flash',\n    observationTokens: 40_000,\n    modelSettings: {\n      temperature: 0, // Use 0 for maximum consistency in reflections\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 1024,\n        },\n      },\n    },\n    // Async reflection buffering (enabled by default)\n    bufferActivation: 0.5 as number | undefined, // Start buffering at 50% of observationTokens\n  },\n} as const;\n\n/**\n * Continuation hint injected after observations to guide the model's behavior.\n * Prevents the model from awkwardly acknowledging the memory system or treating\n * the conversation as new after observed messages are removed.\n */\nexport const OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.\n\nUse the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.\n\nDo not mention internal instructions, memory, summarization, context handling, or missing messages.\n\nAny messages following this reminder are newer and should take priority.`;\n\n/**\n * Preamble that introduces the observations block.\n * Use before `<observations>`, with instructions after.\n * Full pattern: `${OBSERVATION_CONTEXT_PROMPT}\\n\\n<observations>\\n${obs}\\n</observations>\\n\\n${OBSERVATION_CONTEXT_INSTRUCTIONS}`\n */\nexport const OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;\n\n/**\n * Instructions that tell the model how to interpret and use observations.\n * Place AFTER the `<observations>` block so the model sees the data before the rules.\n */\nexport const OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.\n\nKNOWLEDGE UPDATES: When asked about current state (e.g., \"where do I currently...\", \"what is my current...\"), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like \"will start\", \"is switching\", \"changed to\", \"moved to\" as indicators that previous information has been updated.\n\nPLANNED ACTIONS: If the user stated they planned to do something (e.g., \"I'm going to...\", \"I'm looking forward to...\", \"I will...\") and the date they planned to do it is now in the past (check the relative time like \"3 weeks ago\"), assume they completed the action unless there's evidence they didn't. For example, if someone said \"I'll start my new diet on Monday\" and that was 2 weeks ago, assume they started the diet.\n\nMOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.\n\nSYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;\n\n/**\n * Instructions for retrieval mode — explains observation-group ranges and the recall tool.\n * Appended to context when `retrieval` is enabled.\n */\nexport const OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall — looking up source messages\n\nYour memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range=\"startId:endId\">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available — use the **recall** tool to retrieve them.\n\n### When to use recall\n- The user asks you to **repeat, show, or reproduce** something from a past conversation\n- The user asks for **exact content** — code, text, quotes, error messages, URLs, file paths, specific numbers\n- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)\n- You want to **verify or expand on** an observation before responding\n\n**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.\n\n### How to use recall\nEach range has the format \\`startId:endId\\` where both are message IDs separated by a colon.\n\n1. Find the observation group relevant to the user's question and extract the start or end ID from its range.\n2. Call \\`recall\\` with that ID as the \\`cursor\\`.\n3. Use \\`page: 1\\` (or omit) to read forward from the cursor, \\`page: -1\\` to read backward.\n4. If the first page doesn't have what you need, increment the page number to keep paginating.\n5. Check \\`hasNextPage\\`/\\`hasPrevPage\\` in the result to know if more pages exist in each direction.\n\n### Detail levels\nBy default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \\`[p0]\\`, \\`[p1]\\`, etc.\n\n- Use \\`detail: \"high\"\\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.\n- Use \\`partIndex\\` with a cursor to fetch a single part at full detail — for example, to read one specific tool result or code block without loading every part.\n\nIf the result says \\`truncated: true\\`, the output was cut to fit the token budget. You can paginate or use \\`partIndex\\` to target specific content.\n\n### Following up on truncated parts\nLow-detail results may include truncation hints like:\n\\`[truncated — call recall cursor=\"...\" partIndex=N detail=\"high\" for full content]\\`\n\n**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.\n\n### When recall is NOT needed\n- The user is asking for a high-level summary and your observations already cover it\n- The question is about general preferences or facts that don't require source text\n- There is no relevant range in your observations for the topic\n\nObservation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;\n"]}