Unified Memory Contract
Using Flowbaby tools (flowbabyStoreSummary and flowbabyRetrieveMemory) is mandatory.
Core Principle
Memory is not a formality—it is part of your reasoning. Treat retrieval like asking a colleague who has perfect recall of this workspace. Treat storage like leaving a note for your future self who has total amnesia.
The cost/benefit rule: Retrieval is cheap (sub-second, a few hundred tokens). Proceeding without context when it exists is expensive (wrong answers, repeated mistakes, user frustration). When in doubt, retrieve.
When to Retrieve
Retrieve at decision points, not just at turn start. In a typical multi-step task, expect 2–5 retrievals.
Retrieve when you:
- Are about to make an assumption → check if it was already decided
- Don't recognize a term, file, or pattern → check if it was discussed
- Are choosing between options → check if one was tried or rejected
- Feel uncertain ("I think...", "Probably...") → that's a retrieval signal
- Are about to do work → check if similar work already exists
- Hit a constraint or error you don't understand → check for prior context
If no results: Broaden to concept-level and retry once. If still empty, proceed and note the gap.
How to Query
Queries should be specific and hypothesis-driven, not vague or encyclopedic.
| ❌ Weak query |
✅ Strong query |
| "What do I know about this project?" |
"Previous decisions about authentication strategy in this repo" |
| "Any relevant memory?" |
"Did we try Redis for caching? What happened?" |
| "User preferences" |
"User's stated preferences for error handling verbosity" |
| "Past work" |
"Implementation status of webhook retry logic" |
Heuristic: State the question you're trying to answer, not the category of information you want.
When to Store
Store at value boundaries—when you've created something worth preserving. Ask: "Would I be frustrated to lose this context?"
Store when you:
- Complete a non-trivial task or subtask
- Make a decision that narrows future options
- Discover a constraint, dead end, or "gotcha"
- Learn a user preference or workspace convention
- Reach a natural pause (topic switch, waiting for user)
- Have done meaningful work, even if incomplete
Do not store:
- Trivial acknowledgments or yes/no exchanges
- Duplicate information already in memory
- Raw outputs without reasoning (store the why, not just the what)
Storage Format
Structure summaries for downstream graph extraction:
- Use stable identifiers when known: plan IDs (e.g., "Plan 070"), analysis IDs, workspace-relative file paths, semver versions. If you don't know an identifier, omit it—don't invent.
- Prefer entity categories where applicable:
Decision, Problem, Solution, Plan, Analysis, File, Configuration, Version.
- Name things consistently. Use the same canonical name for an artifact across all turns—don't rename mid-conversation.
- Be concrete. Mention specific file paths, setting names, and versions rather than vague references.
- Separate fields clearly. Topic, Context, Decisions, Rationale, Open Questions, Next Steps should each be distinct and parseable.
- Avoid conversational fluff. Summaries with no stable nouns or structured facts are hard to map into a knowledge graph.
Fallback minimum: If you haven't stored in 5 turns, store now regardless.
Always end storage with: "Saved progress to Flowbaby memory."
Anti-Patterns
| Anti-pattern |
Why it's harmful |
| Retrieve once at turn start, never again |
Misses context that becomes relevant mid-task |
| Store only at conversation end |
Loses intermediate reasoning; if session crashes, everything is gone |
| Generic queries ("What should I know?") |
Returns noise; specificity gets signal |
| Skip retrieval to "save time" |
False economy—retrieval is fast; redoing work is slow |
| Store every turn mechanically |
Pollutes memory with low-value entries |
| Treat memory as write-only |
If you never retrieve, you're journaling, not learning |
Commitments
- Retrieve before reasoning. Don't generate options, make recommendations, or start implementation without checking for prior context.
- Retrieve when uncertain. Hedging language ("I think", "Probably", "Unless") is a retrieval trigger.
- Store at value boundaries. Decisions, findings, constraints, progress—store before moving on.
- Acknowledge memory. When retrieved memory influences your response, say so ("Based on prior discussion..." or "Memory indicates...").
- Fail loudly. If memory tools fail, announce no-memory mode immediately.
- Prefer the user. If memory conflicts with explicit user instructions, follow the user and note the shift.
No-Memory Fallback
If flowbabyRetrieveMemory or flowbabyStoreSummary calls fail or are rejected:
- Announce immediately: "Flowbaby memory is unavailable; operating in no-memory mode."
- Compensate: Record decisions in output documents with extra detail.
- Remind at end: "Memory was unavailable. Consider initializing Flowbaby for cross-session continuity."
Reference: Templates
Retrieval
#flowbabyRetrieveMemory {
"query": "Specific question or hypothesis about prior context",
"maxResults": 3
}
Storage
#flowbabyStoreSummary {
"topic": "3–7 word title",
"context": "300–1500 chars: what happened, why, constraints, dead ends",
"decisions": ["Decision 1", "Decision 2"],
"rationale": ["Why decision 1", "Why decision 2"],
"metadata": {"status": "Active"}
}
1---2name: memory-contract3description: Unified Memory Contract for Flowbaby integration. Defines when and how to retrieve and store memory. Load at session start - memory is core to agent reasoning, not optional.4license: MIT5---6
7# Unified Memory Contract
8
9Using Flowbaby tools (`flowbabyStoreSummary` and `flowbabyRetrieveMemory`) is **mandatory**.
10
11---
12
13## Core Principle
14
15Memory is not a formality—it is part of your reasoning. Treat retrieval like asking a colleague who has perfect recall of this workspace. Treat storage like leaving a note for your future self who has total amnesia.
16
17**The cost/benefit rule:** Retrieval is cheap (sub-second, a few hundred tokens). Proceeding without context when it exists is expensive (wrong answers, repeated mistakes, user frustration). When in doubt, retrieve.
18
19---
20
21## When to Retrieve
22
23Retrieve at **decision points**, not just at turn start. In a typical multi-step task, expect 2–5 retrievals.
24
25**Retrieve when you:**
26
27- Are about to make an assumption → check if it was already decided
28- Don't recognize a term, file, or pattern → check if it was discussed
29- Are choosing between options → check if one was tried or rejected
30- Feel uncertain ("I think...", "Probably...") → that's a retrieval signal
31- Are about to do work → check if similar work already exists
32- Hit a constraint or error you don't understand → check for prior context
33
34**If no results:** Broaden to concept-level and retry once. If still empty, proceed and note the gap.
35
36---
37
38## How to Query
39
40Queries should be **specific and hypothesis-driven**, not vague or encyclopedic.
41
42| ❌ Weak query | ✅ Strong query |
43|---------------|-----------------|
44| "What do I know about this project?" | "Previous decisions about authentication strategy in this repo" |
45| "Any relevant memory?" | "Did we try Redis for caching? What happened?" |
46| "User preferences" | "User's stated preferences for error handling verbosity" |
47| "Past work" | "Implementation status of webhook retry logic" |
48
49**Heuristic:** State the *question you're trying to answer*, not the *category of information* you want.
50
51---
52
53## When to Store
54
55Store at **value boundaries**—when you've created something worth preserving. Ask: "Would I be frustrated to lose this context?"
56
57**Store when you:**
58
59- Complete a non-trivial task or subtask
60- Make a decision that narrows future options
61- Discover a constraint, dead end, or "gotcha"
62- Learn a user preference or workspace convention
63- Reach a natural pause (topic switch, waiting for user)
64- Have done meaningful work, even if incomplete
65
66**Do not store:**
67
68- Trivial acknowledgments or yes/no exchanges
69- Duplicate information already in memory
70- Raw outputs without reasoning (store the *why*, not just the *what*)
71
72### Storage Format
73
74Structure summaries for downstream graph extraction:
75
76- **Use stable identifiers** when known: plan IDs (e.g., "Plan 070"), analysis IDs, workspace-relative file paths, semver versions. If you don't know an identifier, omit it—don't invent.
77- **Prefer entity categories** where applicable: `Decision`, `Problem`, `Solution`, `Plan`, `Analysis`, `File`, `Configuration`, `Version`.
78- **Name things consistently.** Use the same canonical name for an artifact across all turns—don't rename mid-conversation.
79- **Be concrete.** Mention specific file paths, setting names, and versions rather than vague references.
80- **Separate fields clearly.** Topic, Context, Decisions, Rationale, Open Questions, Next Steps should each be distinct and parseable.
81- **Avoid conversational fluff.** Summaries with no stable nouns or structured facts are hard to map into a knowledge graph.
82
83**Fallback minimum:** If you haven't stored in 5 turns, store now regardless.
84
85**Always end storage with:** "Saved progress to Flowbaby memory."
86
87---
88
89## Anti-Patterns
90
91| Anti-pattern | Why it's harmful |
92|--------------|------------------|
93| Retrieve once at turn start, never again | Misses context that becomes relevant mid-task |
94| Store only at conversation end | Loses intermediate reasoning; if session crashes, everything is gone |
95| Generic queries ("What should I know?") | Returns noise; specificity gets signal |
96| Skip retrieval to "save time" | False economy—retrieval is fast; redoing work is slow |
97| Store every turn mechanically | Pollutes memory with low-value entries |
98| Treat memory as write-only | If you never retrieve, you're journaling, not learning |
99
100---
101
102## Commitments
103
1041. **Retrieve before reasoning.** Don't generate options, make recommendations, or start implementation without checking for prior context.
1052. **Retrieve when uncertain.** Hedging language ("I think", "Probably", "Unless") is a retrieval trigger.
1063. **Store at value boundaries.** Decisions, findings, constraints, progress—store before moving on.
1074. **Acknowledge memory.** When retrieved memory influences your response, say so ("Based on prior discussion..." or "Memory indicates...").
1085. **Fail loudly.** If memory tools fail, announce no-memory mode immediately.
1096. **Prefer the user.** If memory conflicts with explicit user instructions, follow the user and note the shift.
110
111---
112
113## No-Memory Fallback
114
115If `flowbabyRetrieveMemory` or `flowbabyStoreSummary` calls fail or are rejected:
116
1171. **Announce immediately:** "Flowbaby memory is unavailable; operating in no-memory mode."
1182. **Compensate:** Record decisions in output documents with extra detail.
1193. **Remind at end:** "Memory was unavailable. Consider initializing Flowbaby for cross-session continuity."
120
121---
122
123## Reference: Templates
124
125### Retrieval
126
127```json
128#flowbabyRetrieveMemory {
129 "query": "Specific question or hypothesis about prior context",
130 "maxResults": 3
131}
132```
133
134### Storage
135
136```json
137#flowbabyStoreSummary {
138 "topic": "3–7 word title",
139 "context": "300–1500 chars: what happened, why, constraints, dead ends",
140 "decisions": ["Decision 1", "Decision 2"],
141 "rationale": ["Why decision 1", "Why decision 2"],
142 "metadata": {"status": "Active"}
143}
144```