Aravind
43dabb5f72
The store and the write trigger existed and nothing used either. This wires both ends, so "we have long-term memory" stops being a statement about code that exists and becomes one about behaviour. READ. Memories are recalled before retrieval and placed before it in the prompt: it is the smaller block and the more general one — a standing preference frames how the documents should be read, where a document does not frame a preference. The question stays last, because a model reads the last thing and answers it, and evidence after the question becomes the prompt. Skipped for smalltalk on the same terms as retrieval. Nobody needs remembering to say good morning, and paying for it is how "hi" came to cost six thousand tokens. FAILS QUIET, RECORDED LOUDLY. A memory store that is unreachable must not take the run with it: an answer without memory is worse, not wrong, and the alternative is an outage in the knowledge layer becoming an outage in the product. The trajectory records the failure, and records separately when the store returned recency instead of relevance — a reader comparing two answers needs to know which one got which. WRITE. tools.Remember is registered only where there is somewhere to put it, through DefaultToolsWithMemory rather than a nil check inside the old constructor: a deployment that has not migrated 000017 must not offer a tool whose every call fails against a table that is not there. Passing nil registers exactly the catalogue that was there before. Memory shares retrieval's embedder, and memory.Embedder is knowledge.Embedder by structure so it cannot be given a different one. Two embedding models in one deployment produce vectors that cannot be compared, and the failure is silent: a recall that returns nothing rather than an error. Five new tests on the loop, including the two that matter — a failing store still answers, and a greeting carries nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
14 KiB
14 KiB