This is an interaction I had with GPT5.6 and it using the memory system I developed Recall while doing some work on a discord based hacker simulation learning/competition app. What are your thoughts?
Yes—the key difference is not “Recall remembers more.” It is that Recall represents memory as revisable operational state.
Typical auto-memory is essentially:
- Extract a useful sentence.
- Store it as text plus an embedding.
- Retrieve similar snippets later.
- Let the model reconcile them again from scratch.
If it remembered both:
- “Practice runs are tracked.”
- “Solo is permanently untracked.”
…it could retrieve both without knowing whether they describe different modes, whether one is newer, or whether the second replaces the first. The model might blend them, choose whichever ranks higher, or require you to explain the entire system again.
What happened with HackSim was structurally different:
| Mechanic | What it enabled |
|---|---|
| Typed decision cells | Recall knew this was a product decision, not casual discussion |
| Stable IDs | The old four-mode contract remained directly addressable |
Explicit supersedes edge |
The new decision formally replaced the old one |
| Active/superseded state | Future work can prefer the current contract without deleting history |
| Supporting edges | The correction stayed connected to the three-entry Activity, ephemeral MVP, and paired-progression decisions |
| Task-relative compilation | Related decisions can be assembled into a working context rather than dumped as miscellaneous memories |
| Provenance and verification fields | We can inspect who established a decision and how trustworthy it is |
In the exact case we just handled, the old decision was:
- Learning
- tracked Practice
- Casual
- League
Then you supplied only the changed portion:
- Solo remains untracked.
- Pair becomes tracked later.
- Duel eventually develops into the agreed Casual/League contracts.
You did not have to restate the complete four-mode model. I could retrieve the prior decision, compare it clause by clause, preserve the still-valid Casual and League distinctions, replace the incompatible tracking rule, and write a new active decision that explicitly supersedes the old one.
That is much closer to a combination of:
- version control for decisions,
- event sourcing for changes,
- a typed knowledge graph for relationships,
- a compiler for producing task-specific context,
- and an admission gate for keeping malformed updates out.
Flat auto-memory is closer to a searchable notebook.
The important qualification is that Recall did not magically perform all the reasoning by itself. The language model still had to recognize that your new statement conflicted with one clause while preserving the others. Recall made that interpretation addressable, enforceable, and durable. Without the structure, even a very capable model must repeatedly infer the state of the project from overlapping prose.
Recall can still miss a relevant record, follow a bad relationship, or receive an incorrect interpretation. The structure does not guarantee intelligence. It makes continuity, correction, and auditing tractable.
That is why it feels smarter to the user: you can communicate only the delta. The system maintains the surrounding model.
A concise way to state the difference is:
Auto-memory remembers things you said. Recall maintains which decisions currently govern, what they replaced, and what else they affect.
Any auto-memory system could eventually add these capabilities—but once it has typed records, stable identity, graph relationships, lifecycle state, provenance, and governed supersession, it has stopped being ordinary auto-memory and started becoming something very much like Recall.
[Recall no-write: no durable outcome]
Top comments (2)
The supersedes-edge is the actual product here, not the model transcript wrapped around it. Version control for decisions plus an admission gate is a real architecture, and most auto-memory systems don't have it because most auto-memory systems are a search index wearing a memory costume.
One line worth sitting with longer than the rest: "provenance and verification fields, we can inspect who established a decision and how trustworthy it is." Inspect against what. If the trust score lives in the same record as the decision it's scoring, you haven't added verification, you've added a field that says verified next to a claim nobody outside the record has checked. A supersession is only real supersession if something outside the tuple had the authority to write it, otherwise "typed and superseded" just means "declared and superseded," dressed up in a schema.
The model in the transcript is doing what models do, narrating the system's design back to you fluently and confidently. That's not evidence the design works, it's evidence the model read your schema. Worth separating those before the next post, because right now the strongest claim in here (that Recall did the reasoning correctly) is resting entirely on the same LLM that's telling you it did.
my global recall store is at 9757 entries at this point and I have it tuned to the point that I can use it to switch context freely and it be as correct as starting a new session with relevant memory preloaded. whatever model it is connected to feels smarter and not by a little bit it is noticeable