Add plexer subsystem, container test infra, and last-resort opencode box backend

- Plexer: always-active terminal multiplexing. NativePlexerController/ TmuxPlexerController share one interface, chosen by which env var is already set (TAI_PLEXER_SOCKET vs TMUX_PANE); NativePlexerBackend is the pty.fork()-based wrapper (raw mode, SIGWINCH resize forwarding, a Unix-socket control protocol, continuous session logging, a Ctrl+A prefix key distinct from tmux's own Ctrl+B). Auto-wraps new interactive shells via a .bashrc hook mirroring the existing command-not-found install pattern, gated on $TMUX/$TAI_PLEXER_ACTIVE/ a $HOME/.tai-no-plexer bypass. New plexer_send/read/type/status tools, env-gated on a detected controller. - tests/container.py + docker-compose.yml + tests/docker/Dockerfile: a disposable podman/docker image for the tests that must never touch a real machine (installing the plexer hook into a real ~/.bashrc, a live tmux session). Required suite (test_seal.py, test_tai.py, tests/plexer.py, tests/bashrc.py) gates the result; tests/rag.py runs as best-effort since its real-LLM dependency can't be satisfied inside a disposable container with no nested engine. - tests/bashrc.py: real end-to-end hook install + bash -i auto-wrap, anti-recursion, tmux-active skip, non-interactive skip, a live TmuxPlexerController test, and an install/uninstall round-trip. - tests/plexer.py: NativePlexerBackend under a real pty, plus a dedicated robustness pass (file permissions, >64KB payload framing, a malformed control request, a genuine self-deadlock fix in the write-to-child path). - tai_test.py: the shared async process-driving framework (pipe/pty transport, group-wide kill-and-reap, a StdinBridge for --interactive) both test files build on. - ChatClient last-resort backend: when there's no local opencode CLI but the sandbox box is already running, install opencode into it (official Node tarball, not apt -- apt's nodejs/npm pull in webpack/babel/jest as transitive deps) and route through it instead of giving up. Only reachable after the first retry round already failed everything else; never creates the box itself. TmuxPlexerController.status() fixed to use `list-panes` instead of `display-message -p`, which silently fell back to the default pane instead of erroring against a dead target. - Fix 4 pre-existing test_tai.py bugs surfaced by running it in a clean environment for the first time: two stale mock signatures (subprocess.run's stdout= kwarg, Chat.complete's deadline= kwarg), one $TMUX-dependent catalog assertion, one tty-dependent color assertion. - research/: a sourced research archive (Source Dossier/Citation Card/Conclusion tiers) backing the above design decisions, with its own audit.py consistency checker. - .gitignore: fix a blanket *.md rule that was about to silently drop the entire research/ archive from version control; add __pycache__/ and the one-off debug transcript this session started from. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-10 04:36:05 +02:00
parent f078ab4731
commit 9dbd1fe667
247 changed files with 11187 additions and 26 deletions
@@ -0,0 +1,28 @@
+# Performance of Date-Only vs Date-Time Indexes (forum thread)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Performance of Date-Only vs Date-Time Indexes |
+| Source URL | https://www.access-programmers.co.uk/forums/goto/post?id=1120144 |
+| Source type | forum thread |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing"; an MS Access-focused forum discussion on date-index performance, tangential to SQLite specifically but conceptually adjacent. Not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# 2Q Cache Management Algorithm
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | 2Q Cache Management Algorithm |
+| Source URL | https://arpit.substack.com/p/2q-cache-management-algorithm |
+| Source publisher / author | Arpit (Substack newsletter), explaining Johnson & Shasha's 1994 VLDB paper |
+| Source type | blog post (explainer of a primary paper) |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+An accessible explainer of Johnson & Shasha's 1994 "2Q" buffer-replacement algorithm — a constant-overhead, no-tuning alternative to full LRU that influenced real database buffer-pool design, most notably PostgreSQL's.
+
+## Key findings
+
+- 2Q answers whether a constant-overhead-per-access scheme can match LRU/2 page-replacement performance; the 1994 paper's answer is yes, with no tuning required.
+- The design splits the buffer into three structures: a main LRU queue for confirmed-hot pages, a first-in (probationary) queue for newly-seen pages, and a ghost queue that stores only the identifiers of recently-evicted pages (not their data).
+- A page enters the probationary queue on first access; if it's re-referenced while still represented in the ghost queue, it gets promoted into the main queue.
+- This design is specifically scan-resistant: a one-time sequential scan fills and drains the probationary queue without ever polluting the main hot-page queue.
+- Per the source, 2Q's simplicity and effectiveness influenced PostgreSQL's own buffer-management design.
+
+## Pros / strengths
+
+- O(1), constant-overhead-per-access, no tuning parameters — directly addresses the "speed is important" constraint behind this entire research task, as a possible template if tai ever needs a real eviction policy rather than just tracking.
+- Real production lineage (PostgreSQL) gives confidence this isn't just an academic curiosity.
+
+## Cons / limitations / caveats
+
+- 2Q's own main-LRU-queue component is itself expensive to make concurrent under high contention — this is exactly the weakness that `arxiv-2511-21958-clock2q-plus.md` (Clock2Q+) sets out to fix by replacing that component with a CLOCK-style structure.
+- 2Q is an eviction-policy design for buffer pools; tai is not (yet) building eviction at all, only tracking — so 2Q is background context for a possible future phase, not something applicable today.
+
+## Relevance to tai
+
+Background/comparative context only for this research pass — explicitly not part of the current proposal (which is tracking-only, no eviction), but recorded here so a future eviction-policy decision doesn't have to rediscover 2Q as a candidate from scratch.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,53 @@
+# Generative Agents: Interactive Simulacra of Human Behavior
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Generative Agents: Interactive Simulacra of Human Behavior |
+| Source URL | https://arxiv.org/pdf/2304.03442 |
+| Source publisher / author | Park, Joon Sung et al. (Stanford / Google), 2023 |
+| Source type | paper |
+| Source date (published) | 2023-04-07 (arXiv submission) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+This is the original "generative agents" paper that introduced a retrieval-scoring scheme for agent memory combining recency, importance, and relevance into a single retrieval score. It is the foundational reference almost every later agent-memory system (MemGPT, Letta, Mem0, and the smaller forgetting-curve projects) cites or reacts against.
+
+## Key findings
+
+- Recency is modeled as an exponential decay over time since a memory was *last retrieved* (not last created), with a decay factor of 0.995 per sandbox game hour.
+- Importance is an LLM-assigned integer score (1–10 "poignancy" scale) — the paper found that simply asking the model to output an integer score worked well in practice.
+- Relevance is cosine similarity between embedding vectors of the memory text and the current situation's text.
+- The three signals are combined into one retrieval score; sources disagree on the exact combination — some report equal weighting after normalization, others note the released implementation simply uses a weight of 1 for all three.
+- The paper separately introduces "reflection": higher-level, more abstract thoughts generated by the agent, which are themselves injected back into the memory stream and participate in retrieval.
+
+## Pros / strengths
+
+- Recency, importance, and relevance are kept as three independent signals combined only at retrieval time, not pre-collapsed into one opaque score at write time — this is a reusable design principle independent of the specific decay constant chosen.
+- The scheme is simple enough to reimplement and has become the de facto reference point for the whole field, which makes it a useful common vocabulary even where tai's design diverges from it.
+
+## Cons / limitations / caveats
+
+- The importance score depends on an LLM call per memory, which is a real cost this paper does not need to justify for its own research-simulation use case, but which matters for a production system.
+- The exact weighting of the three signals is not consistently reported across secondary sources — the dossier author was not able to confirm the canonical weights straight from the paper text, only from secondary synthesis of it, so treat exact weight numbers as uncertain pending a direct read of the paper's equations.
+- Decay is calibrated to "sandbox game hours" in a simulated environment; the constant (0.995/hour) is not inherently meaningful for tai's real-wall-clock vault usage and would need its own calibration if ever adopted.
+
+## Relevance to tai
+
+This is the primary precedent for keeping recency as an independent, un-collapsed signal rather than baking a final blended score into storage — directly informing the recommendation in this subject's conclusion to store `last_used` and `use_count` as raw signals rather than a single derived priority number.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,51 @@
+# MemGPT: Towards LLMs as Operating Systems
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | MemGPT: Towards LLMs as Operating Systems |
+| Source URL | https://arxiv.org/pdf/2310.08560 |
+| Source publisher / author | Packer, Charles et al., 2023 |
+| Source type | paper |
+| Source date (published) | 2023-10-12 (arXiv submission) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+MemGPT proposes an OS-inspired memory architecture for LLM agents: a bounded in-context "main context" and an external, larger "archival"/"recall" storage, with a queue manager handling overflow. Important for this subject because it is the most commonly cited "LRU-ish" agent memory architecture, and it turns out its actual eviction policy is FIFO, not LRU.
+
+## Key findings
+
+- Eviction policy is queue-based and FIFO, not recency-based: a queue manager controls context overflow via a queue eviction policy.
+- Before an eviction actually happens, the queue manager inserts a system message warning the LLM that eviction is imminent, so the model can proactively save important content to working context or to archival storage first — the eviction decision point is made visible to the model, not hidden.
+- One implementation pattern described in newer benchmark work pairs a bounded main-context FIFO with a FAISS-backed archival recall store — i.e. a vector index sits behind the FIFO-managed front end.
+- Overflow handling in some descriptions is characterized as a "swap": evict, recursively summarize, and store into recall storage, triggered at a fraction of fast-context capacity.
+
+## Pros / strengths
+
+- Makes the overflow/eviction moment an explicit, LLM-visible event rather than a silent background process — directly useful precedent for "don't silently throw memory away."
+- The tiering concept (fast/bounded vs. slow/large) maps cleanly onto database buffer-pool thinking, which is where this subject's CLOCK/2Q research (see `arpit-2q-cache-algorithm.md`, `arxiv-2511-21958-clock2q-plus.md`) becomes relevant as a possible future eviction mechanism if tai ever needs one.
+
+## Cons / limitations / caveats
+
+- FIFO is a simpler policy than LRU and explicitly does not use access recency to decide what gets evicted — so despite being the paper most people reach for when discussing "agent memory eviction," it is not actually a precedent for LRU-style tracking, only for tiered memory in general.
+- The paper predates, and is architecturally distinct from, the current Letta product (see `letta-agent-memory-blog.md`), which has evolved considerably since; details attributed to "MemGPT" in secondary sources sometimes actually describe current Letta behavior instead.
+
+## Relevance to tai
+
+Confirms that even the most prominent "OS-for-LLMs" memory paper does not use LRU for eviction — reinforcing that tai's proposed `last_used`/`use_count` tracking is building a *new* capability for this project, not replicating an established pattern that already has a known-good eviction policy to copy. tai's conclusion deliberately defers the eviction-policy question rather than assuming FIFO or LRU is obviously correct.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,46 @@
+# Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory |
+| Source URL | https://arxiv.org/pdf/2504.19413 |
+| Source publisher / author | Mem0 team (official paper) |
+| Source type | paper |
+| Source date (published) | 2025 (per arXiv id range; exact date unstated in material reviewed) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+The official research paper underlying the Mem0 product, describing its production long-term-memory architecture. This research pass surfaced it mainly as the primary-source counterpart to the Mem0 vendor blog posts (`mem0-introducing-memory-decay.md`, `mem0-memory-eviction-forgetting.md`), rather than extracting independent technical detail from it directly.
+
+## Key findings
+
+- Establishes Mem0 as a scalable long-term-memory layer intended for production agent deployments, which is the context the decay/eviction features documented in the companion blog-post dossiers were built for.
+
+## Pros / strengths
+
+- Being a peer-reviewable paper rather than pure marketing copy, it is a stronger source of record for Mem0's architecture than the blog posts alone, even though this specific research pass did not extract line-level technical detail from it.
+
+## Cons / limitations / caveats
+
+- This research pass's synthesis of this specific paper was thin relative to the blog-post dossiers — the search results centered discussion on the blog posts, not the paper's own equations or benchmarks. A future pass that reads the paper directly should promote or supplement this dossier with the paper's actual decay/scoring formulas if they are more precisely specified there than in the blog posts.
+
+## Relevance to tai
+
+Primary-source backing for the Mem0 precedent cited throughout this subject's conclusion; included at Tier 1 rather than Tier 2 because it is the official paper behind a directly relevant product, even though the specific numeric formulas could not be independently confirmed from it in this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# GATSim: Urban Mobility Simulation with Generative Agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | GATSim: Urban Mobility Simulation with Generative Agents |
+| Source URL | https://arxiv.org/pdf/2506.23306 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper" as an applied follow-up using the generative-agents memory architecture for urban mobility simulation; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Modeling realistic human behavior using generative agents in a multimodal transport system: Software architecture and Application to Toulouse
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Modeling realistic human behavior using generative agents in a multimodal transport system: Software architecture and Application to Toulouse |
+| Source URL | https://arxiv.org/pdf/2510.19497 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper" as another applied generative-agents simulation (transport modeling in Toulouse); not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,50 @@
+# Clock2Q+: A Simple and Efficient Replacement Algorithm for Metadata Cache in VMware vSAN
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Clock2Q+: A Simple and Efficient Replacement Algorithm for Metadata Cache in VMware vSAN |
+| Source URL | https://arxiv.org/pdf/2511.21958 |
+| Source publisher / author | VMware vSAN team (per title context), 2025 |
+| Source type | paper |
+| Source date (published) | 2025 (per arXiv id; exact date unstated in material reviewed) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+A 2025 paper proposing Clock2Q+, which keeps 2Q's three-queue structure but replaces its expensive main LRU queue with a CLOCK-style reference-bit structure, directly targeting the concurrency/overhead weakness of classic 2Q — and the single strongest primary-source explanation found in this research pass for *why* CLOCK-style tracking is cheap.
+
+## Key findings
+
+- 2Q's main LRU queue has high CPU and memory overhead and is hard to make concurrent, per the paper's own stated motivation.
+- Clock2Q+ replaces that main structure with a CLOCK-style structure: on a hit, the algorithm only sets a reference bit, with no list mutation and no lock-protected reordering on the hot path.
+- The paper also argues the classic design choice (allocating 25% of the cache to the small/probationary FIFO queue, a figure from 1994) is outdated now that caches are far larger than they were 30 years ago, and that shrinking it frees more room for the main structure.
+- Adds a "correlation window" to filter burst-correlated metadata hits, intended to prevent cache pollution while still promoting genuinely hot blocks.
+
+## Pros / strengths
+
+- This is the clearest, most directly-stated primary-source explanation in this entire subject for the general principle behind low-write-overhead recency tracking: a hit only flips a bit instead of mutating a data structure. This principle, not the specific vSAN metadata-cache application, is what's actually relevant to tai.
+- Being a 2025 paper, it's a current, non-dated reference for this specific design pattern.
+
+## Cons / limitations / caveats
+
+- The paper's actual subject is a VMware vSAN metadata cache, a very different workload (block-storage metadata, extremely high access rates) from tai's vault (a local SQLite file with comparatively low concurrent access). The specific tuning (correlation windows, FIFO queue sizing) does not transfer; only the general "reference bit instead of list mutation" principle does.
+
+## Relevance to tai
+
+The clearest primary-source justification, among everything found in this subject, for *why* the throttled/conditional-UPDATE pattern recommended in this subject's conclusion is the right shape of optimization (minimize writes on the hot read path) even though tai's proposal uses a timestamp column and a conditional SQL UPDATE rather than a literal CLOCK reference bit — the underlying principle (don't mutate proportional to every access) is the same one being applied.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,49 @@
+# Evolution of Buffer Management in Database Systems: From Classical Algorithms to Machine Learning and Disaggregated Memory
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Evolution of Buffer Management in Database Systems: From Classical Algorithms to Machine Learning and Disaggregated Memory |
+| Source URL | https://arxiv.org/pdf/2512.22995 |
+| Source publisher / author | Unknown authors (per material reviewed) |
+| Source type | paper (survey) |
+| Source date (published) | 2025 (per arXiv id; exact date unstated in material reviewed) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+A 2025 survey of database buffer-management algorithms spanning classical approaches through ML-based and disaggregated-memory techniques. This research pass drew one specific comparative point from it: its coverage of LIRS and its comparison-table characterization of 2Q.
+
+## Key findings
+
+- Describes LIRS (Low Inter-reference Recency Set) as ranking pages by *inter-reference recency* — the gap between successive accesses — rather than by plain recency (time since last access alone).
+- Its comparison table characterizes 2Q as scan-resistant with O(1) complexity, corroborating the `arpit-2q-cache-algorithm.md` dossier from an independent, more academic source.
+
+## Pros / strengths
+
+- As a survey, it situates 2Q and CLOCK-family algorithms within the broader, still-evolving landscape of buffer management (including newer ML-based and disaggregated-memory approaches), which is useful context even though those newer approaches are well beyond anything tai would need.
+- Independent corroboration of 2Q's O(1)/scan-resistant characterization strengthens confidence in that specific claim.
+
+## Cons / limitations / caveats
+
+- This research pass did not extract detail on the survey's ML-based or disaggregated-memory sections — only the classical-algorithms comparison was actually used, so claims about those newer sections cannot responsibly be made from this dossier.
+- LIRS itself (inter-reference recency) is noted but not explored further in this pass — flagged here as a candidate for deeper investigation only if tai ever gets to a real eviction-policy design phase.
+
+## Relevance to tai
+
+Secondary corroboration for the 2Q/CLOCK-family background research; not independently load-bearing for the subject's conclusion, which does not require (or recommend) adopting any specific eviction algorithm yet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Toward Efficient Agents: Memory, Tool learning, and Planning
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Toward Efficient Agents: Memory, Tool learning, and Planning |
+| Source URL | https://arxiv.org/pdf/2601.14192 |
+| Source type | paper (survey) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper"; a broad survey covering memory among other agent-efficiency topics, not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Crystal-KV: Efficient KV Cache Management for Chain-of-Thought LLMs via Answer-First Principle
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Crystal-KV: Efficient KV Cache Management for Chain-of-Thought LLMs via Answer-First Principle |
+| Source URL | https://arxiv.org/pdf/2601.16986 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LRFU combined recency frequency cache replacement formula least recently frequently used"; the research synthesis noted that newer work applies the LRFU "combined recency and frequency" scoring idea to LLM inference KV-cache management specifically (scoring cache entries by a sum of lambda^(t-t_j) over past hit times) — this paper is the likely source of that specific application, though it was not independently opened to confirm the exact formula variant used.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Entity-Collision: A Stratified Protocol for Attributing Retrieval Lift in Agent Memory
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Entity-Collision: A Stratified Protocol for Attributing Retrieval Lift in Agent Memory |
+| Source URL | https://arxiv.org/pdf/2605.29630 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management"; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Learning What to Remember: A Cognitively Grounded Multi-Factor Value Model for Agentic Memory
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Learning What to Remember: A Cognitively Grounded Multi-Factor Value Model for Agentic Memory |
+| Source URL | https://arxiv.org/pdf/2606.12945 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper"; title suggests direct relevance to multi-factor memory value scoring (recency+frequency+importance style), a plausible candidate for deeper reading in a future research pass, but not opened or quoted during this one.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Beyond Memory Leaderboards: Evaluating Scientific Memory as Budgeted Context Restoration
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Beyond Memory Leaderboards: Evaluating Scientific Memory as Budgeted Context Restoration |
+| Source URL | https://arxiv.org/pdf/2607.16848 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper" as a related follow-up paper on evaluating agent memory systems; not opened or quoted during this research pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems |
+| Source URL | https://arxiv.org/pdf/2607.21503 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management"; title suggests direct relevance to lifecycle-based memory management, a plausible candidate for deeper reading in a future research pass, but not opened or quoted during this one.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# AgentMemBench: A Systematic Benchmark for Evaluating Long-Term Memory Management Strategies in Conversational AI Agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AgentMemBench: A Systematic Benchmark for Evaluating Long-Term Memory Management Strategies in Conversational AI Agents |
+| Source URL | https://arxiv.org/pdf/2608.00009 |
+| Source type | paper (benchmark) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management"; the search synthesis noted this benchmark's MemGPT-style adapter uses "a bounded main-context FIFO + FAISS archival recall" — a useful implementation detail — but the dossier for this card was not independently expanded beyond that single attributed detail, which is recorded instead in `arxiv-2310-08560-memgpt.md`'s Tier 1 dossier.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Measure Before You Manage: Evaluating Agent Working Memory in Coding Agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Measure Before You Manage: Evaluating Agent Working Memory in Coding Agents |
+| Source URL | https://arxiv.org/pdf/2608.31057 |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper"; relevant to coding-agent working memory specifically, which overlaps with tai's own domain (a coding agent), but not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# An Improved Adaptive Policy Based on Recency and Frequency (Atlantis Press)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | An Improved Adaptive Policy Based on Recency and Frequency |
+| Source URL | https://www.atlantis-press.com/article/21835.pdf |
+| Source type | paper (conference proceedings, AMEII 2015) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LRFU combined recency frequency cache replacement formula least recently frequently used"; per the search synthesis, this 2015 paper proposes an adaptive variant of LRFU that lets the recency/frequency tradeoff parameter (lambda) adjust dynamically rather than staying fixed, addressing the main criticism of classic LRFU. A second, related paper from the same Atlantis Press proceedings (`https://www.atlantis-press.com/article/21834.pdf`) also surfaced and is treated as the same source family, logged under this one card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# bm25 (BlackGlory's digital garden — SQLite FTS5 auxiliary function note)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | bm25 (auxiliary function note) |
+| Source URL | https://blackglory.me/notes/sqlite/SQLite3/FTS_Full-Text_Search/FTS5/Querying/Auxiliary_Functions/bm25?variant=en |
+| Source type | other (personal notes/digital garden) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "boost BM25 FTS5 search ranking by recency last accessed hybrid scoring formula" as personal notes on FTS5's `bm25()` auxiliary function; closely related to the sign-convention point recorded at Tier 1 in `sqlite-org-bm25-sign-flip-commit.md`, but this specific note page was not independently opened.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# lang_datefunc (chiark.greenend.org.uk mirror of SQLite docs)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | lang_datefunc |
+| Source URL | https://www.chiark.greenend.org.uk/doc/sqlite3/lang_datefunc.html |
+| Source type | vendor docs (third-party documentation mirror) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing" as a mirror of SQLite's official date-function documentation. Its specific technical point — that an INTEGER value needs the `'unixepoch'` modifier or SQLite's date functions will misread it as a Julian day number — is recorded directly in the `sqlite-forum-timestamp-integer-vs-text.md` Tier 1 dossier, sourced from the broader search synthesis rather than an independent read of this specific mirror page. A second mirror of the same documentation (sao.ru) also surfaced and is treated as the same underlying source.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# SQLite date and time (Coddy.tech docs mirror)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | date and time |
+| Source URL | https://coddy.tech/docs/de/sqlite/date-and-time |
+| Source type | vendor docs (third-party documentation mirror) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing"; its content (TEXT/REAL/INTEGER as the three date/time storage representations) is corroborated directly in the `sqlite-forum-timestamp-integer-vs-text.md` Tier 1 dossier, but this specific mirror page was not independently opened. A near-identical English-language and Japanese-language mirror of the same documentation also surfaced elsewhere in this subject's research and is treated as the same underlying source.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Papers We Love — caching archive mirror (code.garrettmills.dev)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Papers We Love — caching directory (git archive mirror) |
+| Source URL | https://code.garrettmills.dev/Archives/papers-we-love_papers-we-love/src/commit/23fff13692fb378bcac40e9ace7b7c1b0ec9f83d/caching |
+| Source type | repository (git mirror) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "approximate LRU algorithm CLOCK 2Q low write overhead cache eviction database" as a mirrored git archive of the Papers We Love caching-papers directory. A second, near-identical commit of the same mirror also surfaced in the same result set and is treated as the same source, not filed separately.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,61 @@
+# Conclusion: Last-Used / Use-Count Tracking Proposal for the tai Vault
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-09 |
+| Decided by | retoor, advised by tai (agent, Claude Sonnet 5) |
+| Status | Active (proposal recorded, not yet implemented) |
+| Confidence | Medium |
+
+## Question / problem statement
+
+retoor asked for a way to track when a vault record (and, by extension, a chunk) was last used, or was recently part of a search result, with an eye toward a future LRU-style prioritization or faster-access mechanism. The explicit instruction was to research this thoroughly first — specifically looking at how agent-memory systems already do this, and at systems/database techniques for doing it cheaply — and to produce a concrete proposal, with building anything explicitly forbidden for this task.
+
+## Conclusion
+
+The recommended design (not yet built) is:
+
+- Add a `last_used INTEGER` column (Unix epoch seconds) to both the `records` and `chunks` tables. This is a deliberate exception to the vault's otherwise-universal ISO-8601 TEXT timestamp convention, justified specifically because this column is compared, sorted, and range-scanned on a hot path in a way the vault's other timestamp columns are not.
+- Add a `use_count INTEGER` column to `chunks`. `records` already has an existing `reads` counter that serves the same purpose, so no duplicate column is needed there.
+- "Used" is triggered by two kinds of event: (a) an explicit `record_read`/`get_record` call, and (b) a record or chunk appearing in `search` results — a chunk hit should also propagate an update to its parent record's `last_used`, since the parent is "the record" in retoor's own framing of the request.
+- Writes must be throttled/conditional, never unconditional on every hit: `UPDATE ... SET last_used = ? WHERE last_used IS NULL OR last_used < ?` with a coalescing window (a starting estimate of roughly one minute), modeled directly on Linux's `relatime` mount option and the real, documented GitLab `last_downloaded_at` production incident.
+- No eviction policy and no search-ranking integration is being built in this phase. This is tracking-substrate only — recording the raw signal so a future, separate decision can use it, matching how both the Generative Agents paper and Mem0's product keep recency as an independent signal rather than baking a final blended formula in at write time.
+
+## Supporting sources
+
+- `arxiv-2304-03442-generative-agents.md` (Tier 1) — the foundational precedent for keeping recency, importance, and relevance as three independent, un-collapsed signals combined only at retrieval time.
+- `arxiv-2310-08560-memgpt.md`, `letta-agent-memory-blog.md` (Tier 1) — establish that even the most prominent "OS-for-LLMs" memory architecture uses FIFO eviction, not LRU, and keeps ranking (recency-aware) separate from eviction/compaction — informing the decision to defer eviction entirely rather than assume a policy.
+- `mem0-introducing-memory-decay.md`, `mem0-memory-eviction-forgetting.md`, `arxiv-2504-19413-mem0-paper.md` (Tier 1) — the closest existing commercial precedent: recency as a soft search-time re-ranking multiplier, not a deletion trigger; and an explicit distinction between decay (ranking), TTL (lifecycle), and deletion APIs (user-visible forgetting) that this proposal deliberately mirrors by staying purely in the "raw signal" category.
+- `arpit-2q-cache-algorithm.md`, `arxiv-2511-21958-clock2q-plus.md`, `arxiv-2512-22995-buffer-management-survey.md` (Tier 1) — background precedent for low-write-overhead recency tracking (2Q, CLOCK), recorded for a *possible future* eviction-policy phase, not used directly in the current tracking-only proposal.
+- `redhat-relatime-drive-access.md`, `gitlab-last-downloaded-at-write-amplification.md` (Tier 1) — the direct justification for the throttled/conditional-UPDATE write pattern: `relatime` is the exact same tradeoff already running on effectively every Linux filesystem read, and the GitLab incident is concrete, quantified, real-world proof that the naive unconditional-update approach causes genuine production problems.
+- `sqlite-forum-timestamp-integer-vs-text.md`, `sqlite-org-bm25-sign-flip-commit.md` (Tier 1) — justify the Unix-epoch-INTEGER column choice and flag the BM25 ranking-direction gotcha for whoever eventually builds the ranking-integration phase.
+- `glama-code-index-mcp-bm25-hybrid.md` (Tier 1) — a concrete, reusable BM25-normalization-and-fusion reference for that same future phase.
+
+## Alternatives considered and rejected
+
+- **Unconditional `UPDATE` on every access.** Rejected outright, per the GitLab incident's own documented production consequences (row-version and index-entry multiplication on a hot read path) — this is the one alternative with direct, quantified evidence against it, not just theoretical concern.
+- **In-memory batched writes flushed periodically** (the `lazytime` approach). Not rejected — deferred as a second-stage optimization, to be built only if the simple throttled-UPDATE approach proves insufficient under real measured load. Recorded explicitly as "not rejected, just not needed yet," not as a worse option.
+- **A single blended LRFU-style score computed and stored at write time**, instead of separate `last_used`/`use_count` columns. Rejected for this phase because collapsing recency and frequency into one opaque number at write time would destroy the ability to use them as independent inputs to whatever ranking or eviction decision gets made later — a decision that has not been made yet. This mirrors the Generative Agents / Mem0 pattern of keeping signals separate until the moment they're actually used.
+- **ISO-8601 TEXT for `last_used`, matching every other timestamp column in the vault.** Considered, since consistency has its own value and was retoor's own suggested fallback ("if it doesn't matter just use the same date format as the other columns"). Rejected specifically for this one column because it is the one column in the whole schema expected to be compared/range-scanned on a genuine hot path, where the SQLite-forum-documented integer advantages (no text parsing, smaller index entries, no timezone ambiguity) are the kind of thing that could plausibly matter — this is the one deliberate inconsistency in the schema, and it is being flagged as such rather than introduced silently.
+
+## Risks / open questions
+
+- The ~one-minute throttle window is an engineering estimate, not a measured value against tai's actual read/search volume — it has not been benchmarked.
+- Whether chunk-level `use_count` should itself decay over time (as in Mem0's or YourMemory's Ebbinghaus-curve approaches) is an open question explicitly deferred to a future decision, not resolved here.
+- Whether a chunk hit should *always* propagate to its parent record's `last_used`, or only under some condition, is a design detail that was decided one way here (always propagate) but not independently stress-tested against real usage patterns.
+
+## Action taken
+
+None yet. retoor's instructions for this research task explicitly forbade building anything — this document records the proposal and its supporting research only. Implementation remains a future decision.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial conclusion recorded. |
@@ -0,0 +1,28 @@
+# LLMs as Operating Systems: Agent Memory (DeepLearning.AI course)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | LLMs as Operating Systems: Agent Memory |
+| Source URL | https://www.deeplearning.ai/courses/llms-as-operating-systems-agent-memory |
+| Source type | vendor docs (course page) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management" as a DeepLearning.AI course page covering the same OS-metaphor memory architecture as MemGPT/Letta; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# AI Agent Memory Part 2: The Case for Intelligent Forgetting
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AI Agent Memory Part 2: The Case for Intelligent Forgetting |
+| Source URL | https://dev.to/sudarshangouda/ai-agent-memory-part-2-the-case-for-intelligent-forgetting-4i48 |
+| Source type | blog post |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Mem0 memory scoring decay forgetting curve AI agent long term memory"; a independent blog series entry on intelligent forgetting in agent memory, conceptually adjacent to the Mem0/YourMemory Tier 1 dossiers but not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# kindling-provider (docs.rs)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | kindling-provider |
+| Source URL | https://docs.rs/kindling-provider |
+| Source type | repository (Rust crate documentation) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "boost BM25 FTS5 search ranking by recency last accessed hybrid scoring formula" as a Rust crate's documentation page; relevance to the subject was not established — not opened or quoted during this pass, logged for completeness only.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Generative Agents: Human-like AI Behaviors
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Generative Agents: Human-like AI Behaviors |
+| Source URL | https://www.emergentmind.com/topics/generative-agents |
+| Source type | vendor/aggregator topic page |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper" as an EmergentMind topic-overview page on the Generative Agents paper; potentially a useful secondary overview but not opened or quoted during this research pass — the primary paper (`arxiv-2304-03442-generative-agents.md`) was used instead.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# MemGPT: OS-Inspired Memory Architecture
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | MemGPT: OS-Inspired Memory Architecture |
+| Source URL | https://www.emergentmind.com/topics/memgpt |
+| Source type | vendor/aggregator topic page |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management" as an EmergentMind overview page; the primary MemGPT paper (`arxiv-2310-08560-memgpt.md`) was used as the Tier 1 source instead.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Frontiers in Psychology — Generative agents article
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | (Frontiers in Psychology journal article, title not individually captured by this research pass) |
+| Source URL | https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2025.1591618/full |
+| Source type | paper (journal article) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LLM agent memory recency importance relevance retrieval scoring generative agents paper" as a psychology-journal angle on generative agents; not opened or quoted during this pass, and even its own title was not individually captured in the search synthesis.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,48 @@
+# YourMemory — Agentic AI memory with Ebbinghaus forgetting curve decay
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | YourMemory: Agentic AI memory with Ebbinghaus forgetting curve decay |
+| Source URL | https://github.com/sachitrafa/YourMemory |
+| Source publisher / author | sachitrafa (GitHub, independent/open-source project) |
+| Source type | repository |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+An open-source, smaller competitor project to Mem0 that implements agent memory aging explicitly on an Ebbinghaus forgetting-curve model, rather than Mem0's simpler linear-ish 0.3x–1.5x recency multiplier — and claims a measurable recall improvement over Mem0 on a named benchmark.
+
+## Key findings
+
+- Every memory is described as aging on an Ebbinghaus forgetting curve: stale, unused facts fade; important and frequently-recalled ones persist.
+- The project claims "+16pp better recall than Mem0 on LoCoMo" (a named long-context-memory benchmark).
+
+## Pros / strengths
+
+- Represents a concrete, implemented alternative to Mem0's simpler decay curve, grounded in an actual cognitive-science forgetting model rather than an ad hoc multiplier range — useful as a second data point on "how might decay actually be shaped" if tai ever builds a ranking-integration phase.
+
+## Cons / limitations / caveats
+
+- The "+16pp better recall than Mem0" figure is the competing project's own self-reported claim, on its own chosen benchmark, with no independent verification found during this research pass. It should be treated as a marketing/positioning claim, not a verified result, until independently reproduced.
+- Smaller, less established project than Mem0 or Letta — lower confidence that its described behavior matches real-world production experience at scale.
+
+## Relevance to tai
+
+A second, independent example (alongside Mem0) that agent-memory products are converging on recency-as-decay-curve for ranking rather than for eviction — reinforces, but does not change, the subject's conclusion that tai's current proposal should stop at raw tracking and defer any decay-curve decision.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,51 @@
+# S16 follow-up: three open surfaces of the last_downloaded_at write-amplification argument
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | S16 follow-up: three open surfaces of the last_downloaded_at write-amplification argument |
+| Source URL | https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/680 |
+| Source publisher / author | GitLab (internal engineering work item, publicly visible) |
+| Source type | other (production engineering issue tracker entry) |
+| Source date (published) | Unknown — not stated (exact work item date not captured by this research pass) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+A real, named production incident write-up from GitLab's own artifact registry engineering work, documenting the exact failure mode this subject's conclusion is designed to avoid: an unconditional "touch" update on a hot read path causing serious database write amplification — with a concrete, quantified load estimate and GitLab's own fix.
+
+## Key findings
+
+- The `last_downloaded_at` column in question is part of a btree index, so updating it cannot be satisfied by a heap-only-tuple (HOT) update — every bump therefore creates a new row version *and* a new entry in every index the row belongs to.
+- Concrete load estimate given: a 10-layer container image pulled 100 times a minute, with every layer resolving to the same underlying row, works out to roughly 17 row versions per second plus 51 index entries per second on that one row — from what looks like "just incrementing a timestamp."
+- GitLab's actual fix was a throttled update: the write is skipped based on the freshness of the row's own existing timestamp, so repeated reads within the throttle window are no-ops at the database layer.
+- The work item notes one of the two write routes was throttled this way while a second (blob reads, which have no manifest row to check against) was not yet fixed at time of writing — i.e. even GitLab's own fix was partial/in-progress, not a universally complete solution captured in this source.
+
+## Pros / strengths
+
+- This is a real, quantified, named production incident — not a theoretical cache paper — making it the single most concrete evidence in this entire subject that "just add a last_used column and UPDATE it on every read" is a genuine, not hypothetical, performance risk.
+- The fix GitLab actually applied (throttle based on the row's own existing timestamp) is structurally identical to the pattern this subject's conclusion recommends for tai (`UPDATE ... WHERE last_used IS NULL OR last_used < ?`).
+
+## Cons / limitations / caveats
+
+- This is PostgreSQL-specific in its mechanics (HOT updates, btree index versioning) — SQLite (tai's actual database) has different internals, so the exact row-version/index-entry multiplication described here does not transfer number-for-number. The general lesson (indexed, frequently-touched timestamp columns cause real write amplification) does transfer; the specific "17 row versions/sec, 51 index entries/sec" figures are PostgreSQL-specific illustrations, not a universal constant.
+- The source itself documents an incomplete, in-progress fix (one route throttled, one not) — it should not be read as "GitLab solved this cleanly," only as "GitLab hit this problem and applied a partial, same-shaped fix."
+
+## Relevance to tai
+
+This is the primary real-world justification, cited directly in this subject's conclusion, for why tai's `last_used` column must never be updated unconditionally on every read/hit, and for why the recommended fix is a conditional/throttled UPDATE rather than a naive touch-on-every-access implementation.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# claude-memory-mcp — semantic-search.ts (Glama MCP server listing)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | semantic search (claude-memory-mcp) |
+| Source URL | https://glama.ai/mcp/servers/@WhenMoon-afk/claude-memory-mcp/blob/5f8d26e416fc516efffb63d3efffe7d00a7c17cc/src/search/semantic-search.ts |
+| Source type | repository (hosted source blob) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "boost BM25 FTS5 search ranking by recency last accessed hybrid scoring formula" as an MCP memory server's semantic-search implementation file; not opened or quoted during this pass. The specific numeric hybrid-fusion details used in this subject's research came from a different result in the same search, recorded at Tier 1 in `glama-code-index-mcp-bm25-hybrid.md`'s sibling card below.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,48 @@
+# BM25 Hybrid Search Implementation Summary (Code-Index-MCP)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | BM25 Hybrid Search Implementation Summary |
+| Source URL | https://glama.ai/mcp/servers/@ViperJuice/Code-Index-MCP/blob/e3183d0106c586aec03535faabe632b4db4d6046/docs/implementation/BM25_HYBRID_SEARCH_IMPLEMENTATION.md |
+| Source publisher / author | ViperJuice (Code-Index-MCP project) |
+| Source type | repository (implementation documentation) |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+An implementation-documentation file from an MCP code-indexing server describing how it normalizes raw BM25 scores and fuses them with semantic/vector scores for hybrid search. Promoted to Tier 1 (rather than the plain citation-card treatment of its sibling results in the same search) because the research synthesis attributed specific, concrete numeric details to this exact document, meeting the "independently analyzed" bar the Tier 1/Tier 2 distinction is built on.
+
+## Key findings
+
+- Normalizes raw BM25 rank to a [0,1] scale via a linear, clamped mapping: a raw rank of 0 maps to 1.0 (best), -5 maps to 0.5, and -10-or-worse clamps to 0.0; positive values are clamped to 1.0.
+- Fuses keyword (BM25) and semantic (vector) scores as a weighted linear sum, with stated defaults of 0.3 (keyword) and 0.7 (semantic), configurable via custom weights.
+
+## Pros / strengths
+
+- Gives a concrete, already-implemented example of score normalization for BM25 specifically (not just the sign-convention point from `sqlite-org-bm25-sign-flip-commit.md`, but an actual usable clamp-and-scale formula) — directly reusable reference if tai ever builds a phase that blends `last_used`/`use_count` into search ranking alongside BM25.
+
+## Cons / limitations / caveats
+
+- The specific clamp thresholds (0, -5, -10) are this project's own tuning, calibrated to its own corpus and BM25 configuration — not a universal constant, and not verified against tai's own `fts_docs` table's actual score distribution.
+- This dossier is based on the search tool's synthesis of the document, not a direct fetch and read of the full file — treat the two numeric details above as reliably attributed, but do not assume the rest of the document's content beyond what's stated here.
+
+## Relevance to tai
+
+A candidate reference implementation for a future (explicitly out-of-scope-for-now) phase where `last_used`/`use_count` get blended into tai's existing `bm25(fts_docs)`-based ranking — not used in the current tracking-only proposal, but recorded so that future phase doesn't start from zero.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created (promoted to Tier 1 on authoring, since specific attributable numeric findings were available, rather than filed as a bare Tier 2 citation card). |
@@ -0,0 +1,28 @@
+# gnosis-mcp — SQLite backend (aiosqlite + FTS5 + optional sqlite-vec)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | SQLite backend using aiosqlite + FTS5 + optional sqlite-vec for hybrid search |
+| Source URL | https://glama.ai/mcp/servers/@nicholasglazer/gnosis-mcp/blob/c98bf9ef8f3067a6a63b78e3c3ff9c126d52042c/src/gnosis_mcp/sqlite_backend.py |
+| Source type | repository (hosted source blob) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "boost BM25 FTS5 search ranking by recency last accessed hybrid scoring formula" as another MCP server using an aiosqlite+FTS5+optional-sqlite-vec hybrid backend — architecturally similar in spirit to the `sqlite-rag-hybrid-search` subject's own research, but not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# mcp-memory-service — test_hybrid_search.py (Glama MCP server listing)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | test hybrid search |
+| Source URL | https://glama.ai/mcp/servers/@doobidoo/mcp-memory-service/blob/8f6d4f397e1c5cc9cd94234732635810bb972a4a/tests/storage/test_hybrid_search.py |
+| Source type | repository (test suite file) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "boost BM25 FTS5 search ranking by recency last accessed hybrid scoring formula" as another MCP memory server's hybrid-search test file; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# MFLRU Replacement (HiPC 2002 poster)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | MFLRU Replacement |
+| Source URL | https://www.hipc.org/hipc2002/2002Posters/MFLRU_Replacement.pdf |
+| Source type | paper (conference poster) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LRFU combined recency frequency cache replacement formula least recently frequently used" as a 2002 HiPC conference poster on an MFLRU (Most-Frequent-Least-Recently-Used, per name inference) replacement scheme; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Agent Memory: How to Build Agents That Learn and Remember
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Agent Memory: How to Build Agents That Learn and Remember |
+| Source URL | https://www.letta.com/blog/agent-memory/ |
+| Source publisher / author | Letta (vendor blog) |
+| Source type | blog post / vendor docs |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+Letta (the company that productized MemGPT's ideas) describes its current tiered memory model: Core (in-context, RAM-analogue), Recall (cache-analogue), Archival (cold-storage analogue), with the model itself responsible for paging decisions through explicit tool calls.
+
+## Key findings
+
+- Tiers are explicitly analogized to a memory hierarchy: Core (RAM) / Recall (cache) / Archival (cold).
+- The LLM itself manages memory autonomously via function calls such as `search_memory` and `add_to_working`, rather than an external, opaque eviction process.
+- Retrieval uses a hybrid of embedding similarity and recency-based scoring — recency plays a role in *ranking* results, but the source material does not tie it to any formal LRU *eviction* rule; eviction and ranking are presented as separate concerns.
+- A separate 2026-dated survey (per the research synthesis) describes newer Letta features: developer-defined memory blocks, automatic compaction of older messages, and experimental "sleep-time" agents that process memory in the background between interactions.
+
+## Pros / strengths
+
+- Clear, current (vendor-maintained) articulation of a three-tier memory hierarchy that other agent-memory systems implicitly reference.
+- Explicitly separates "how do we rank what to retrieve" (recency+embeddings) from "how do we decide what to evict/compact" (the model's own tool calls, or background "sleep-time" compaction) — a clean separation tai's own design should probably preserve.
+
+## Cons / limitations / caveats
+
+- It is vendor marketing content, not an independent technical analysis or paper — claims about Letta's internals should be treated as the vendor's own self-description, not independently verified.
+- "Recency-based scoring" is mentioned without a documented formula; this dossier cannot cite an exact decay function because the source did not state one in the material the search tool returned.
+
+## Relevance to tai
+
+Reinforces the pattern (also seen in MemGPT and Mem0) of keeping ranking and eviction/compaction as separate mechanisms, and of letting recency inform ranking without being the sole driver of deletion — consistent with this subject's conclusion to track `last_used`/`use_count` now while explicitly deferring any eviction or ranking-integration decision.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Letta - LLM Agent Research (notes)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Letta - LLM Agent Research |
+| Source URL | https://lin-guanguo.github.io/llm-memory-research/letta.research/ |
+| Source type | blog post (personal research notes) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management" as an individual researcher's personal notes on Letta; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Once Upon Atime (LWN.net kernel article)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Once Upon Atime |
+| Source URL | https://lwn.net/Articles/244829 |
+| Source type | other (kernel-development news article) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Linux relatime lazytime atime update reduce write overhead filesystem technique" as LWN's own historical coverage of the atime/relatime kernel discussion; the Red Hat documentation (`redhat-relatime-drive-access.md`) was used as the Tier 1 source for the actual relatime/lazytime mechanics instead of this article, which was not independently opened.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,48 @@
+# Paper Review: Generative Agents: Interactive Simulacra of Human Behavior
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Paper Review: Generative Agents: Interactive Simulacra of Human Behavior |
+| Source URL | https://artgor.medium.com/paper-review-generative-agents-interactive-simulacra-of-human-behavior-cc5f8294b4ac |
+| Source publisher / author | artgor (Medium) |
+| Source type | blog post (secondary review) |
+| Source date (published) | Unknown — not stated; the search tool flagged this piece as roughly 1,150 days old relative to the search date, i.e. a multi-year-old secondary source |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+A secondary review/summary of the Generative Agents paper (see `arxiv-2304-03442-generative-agents.md`), useful mainly as corroboration of the recency/importance/relevance retrieval-score structure from an independent reader rather than as a primary source in its own right.
+
+## Key findings
+
+- Corroborates the three-part retrieval score (recency, importance, relevance) and the normalize-then-combine framing.
+- Does not appear to add technical detail beyond the original paper; its value here is as a second, independent restatement that agrees with the primary source.
+
+## Pros / strengths
+
+- Independent confirmation reduces the risk that the primary dossier's synthesis of the original paper was a search-tool misreading.
+
+## Cons / limitations / caveats
+
+- Multi-year-old secondary commentary; the field has moved substantially since (see the Mem0 and MemGPT/Letta dossiers in this same subject), so anything in this review not corroborated by the primary paper or by current vendor documentation should be treated as dated.
+- Adds no new findings beyond the primary source.
+
+## Relevance to tai
+
+Low standalone relevance — included for completeness and cross-checking, not as an independent input to the conclusion in this subject.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Stateful AI Agents: A Deep Dive into Letta (MemGPT) Memory Models
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Stateful AI Agents: A Deep Dive into Letta (MemGPT) Memory Models |
+| Source URL | https://medium.com/@piyush.jhamb4u/stateful-ai-agents-a-deep-dive-into-letta-memgpt-memory-models-a2ffc01a7ea1 |
+| Source type | blog post |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management" as an independent deep-dive blog post; the Letta vendor blog and MemGPT paper were used as the Tier 1 sources instead of this secondary writeup.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# AI Memory Management: 4 Layers & Production Benchmarks (Mem0)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AI Memory Management: 4 Layers & Production Benchmarks |
+| Source URL | https://mem0.ai/blog/ai-memory-management-for-llms-and-agents |
+| Source type | blog post / vendor docs |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Mem0 memory scoring decay forgetting curve AI agent long term memory" as a broader Mem0 blog post on a "4 layers" memory-management framework; not opened or quoted independently during this pass, with the decay-specific and eviction-specific posts used as Tier 1 sources instead.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agent Memory Staleness: How Recency-Aware Ranking Fixes Retrieval Drift (Mem0)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agent Memory Staleness: How Recency-Aware Ranking Fixes Retrieval Drift |
+| Source URL | https://mem0.ai/library/context-engineering/memory-decay-for-long-running-agents-how-recency-aware-ranking-fixes-retrieval-staleness |
+| Source type | blog post / vendor docs |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Mem0 memory scoring decay forgetting curve AI agent long term memory" as a context-engineering-focused Mem0 library article specifically about recency-aware ranking and retrieval staleness — closely related to the decay mechanism covered at Tier 1 in `mem0-introducing-memory-decay.md`, but this specific article was not independently opened during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# How to create AI agents with long-term memory (Mem0)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | How to create AI agents with long-term memory |
+| Source URL | https://mem0.ai/blog/how-to-create-ai-agents-with-long-term-memory |
+| Source type | blog post / vendor docs |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Mem0 memory scoring decay forgetting curve AI agent long term memory" as a how-to-oriented blog post; not opened or quoted independently during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Introducing Memory Decay in Mem0
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Introducing Memory Decay in Mem0 |
+| Source URL | https://mem0.ai/blog/introducing-memory-decay-in-mem0 |
+| Source publisher / author | Mem0 (vendor blog) |
+| Source type | blog post / vendor docs |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+Mem0's "Memory Decay" feature is a search-time re-ranking multiplier based on recency since last access — not a deletion/forgetting mechanism. It is the closest thing in current commercial agent-memory products to what tai is being asked to build the tracking substrate for.
+
+## Key findings
+
+- Each memory receives a recency-based scaling factor between 0.3x and 1.5x: recently accessed memories get boosted up to 1.5x, idle ones drift down toward a 0.3x floor.
+- Nothing is ever deleted by this mechanism — the 0.3x floor means an idle-but-genuinely-relevant memory can still surface for the right query, just lower in the ranking.
+- Access to a memory resets/raises its decay score — i.e. "used" directly and immediately affects future ranking.
+- Mem0's own A/B test is reported to have moved the correct memory to rank 1 in 3 of 4 test cases, and widened score separation from a ~0.0001 margin to a 0.15+ gap.
+
+## Pros / strengths
+
+- Exactly the "soft re-ranking, not hard eviction" pattern this subject's conclusion recommends tai consider for a *future* phase (explicitly not being built now) — recording this now means the next phase doesn't have to rediscover this precedent.
+- The 0.3x–1.5x framing is simple enough to reason about and reimplement if/when tai decides to build a ranking-integration phase.
+
+## Cons / limitations / caveats
+
+- The "3 of 4 test cases" and "0.15+ gap" figures are vendor-reported, from a vendor's own blog post, on an unstated and likely small sample size — this is marketing evidence, not an independently reproduced benchmark, and should not be treated as a general guarantee.
+- No exact decay formula (e.g. half-life, decay constant) is disclosed in the material available to this research pass — the mechanism's existence and rough behavior are known; its precise math is not.
+
+## Relevance to tai
+
+Directly relevant precedent for a possible future phase of tai's `last_used`/`use_count` work (ranking integration), explicitly out of scope for the current proposal, which is tracking-only. Cited in the subject's conclusion document as the main real-world analogue for "recency as a soft ranking signal, not a deletion trigger."
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# AI Agent Memory Library: Guides & Tutorials (Mem0)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AI Agent Memory Library: Guides & Tutorials |
+| Source URL | https://mem0.ai/library |
+| Source type | vendor docs |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Mem0 memory scoring decay forgetting curve AI agent long term memory" as Mem0's general guide/tutorial library index page; the specific decay and eviction blog posts were used as Tier 1 sources instead of this general index.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,50 @@
+# Memory eviction and forgetting in AI agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Memory eviction and forgetting in AI agents |
+| Source URL | https://mem0.ai/blog/memory-eviction-and-forgetting-in-ai-agents |
+| Source publisher / author | Mem0 (vendor blog) |
+| Source type | blog post / vendor docs |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+Mem0's broader guidance on eviction/forgetting beyond the Memory Decay feature specifically: it distinguishes soft re-ranking (decay) from real pruning, and recommends TTL policies plus explicit deletion APIs for genuine forgetting, with tiered memory lifetimes by scope.
+
+## Key findings
+
+- Session memory is described as persisting minutes-to-hours and being cleared explicitly; user- and organization-level memory are long-lived by contrast.
+- For episodic data specifically, the guidance is to use timestamps plus explicit TTL policies rather than relying on decay alone.
+- The source explicitly states memory systems need deletion APIs and UX patterns that expose what is remembered — i.e. forgetting should be an observable, intentional operation, not an opaque side effect.
+- Decay (see `mem0-introducing-memory-decay.md`) is characterized here as "decays low-relevance entries over time, freeing up space and attention" — a description, not a documented formula.
+
+## Pros / strengths
+
+- Clearly separates three distinct concerns that are easy to conflate: ranking (decay), lifecycle/expiry (TTL), and user-visible deletion (explicit API) — a useful three-way framework for tai to keep in mind even though only the tracking substrate for the first concern is being built right now.
+
+## Cons / limitations / caveats
+
+- Lacks a documented formula for its own decay mechanism (consistent with the companion decay-announcement post); this source is guidance-level, not implementation-level detail.
+- Vendor content, not independently verified.
+
+## Relevance to tai
+
+Useful for correctly scoping what tai's `last_used`/`use_count` proposal is and is not: it is tracking substrate that could later feed a decay-style ranking signal (per Mem0's own distinction), but it is explicitly not a TTL/expiry mechanism and not a deletion mechanism — those would be separate, later decisions if ever made.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# AI Agent Memory: Complete Guide & Architecture (Mem0)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AI Agent Memory: Complete Guide & Architecture |
+| Source URL | https://mem0.ai/blog/memory-in-agents-what-why-and-how |
+| Source type | blog post / vendor docs |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "Mem0 memory scoring decay forgetting curve AI agent long term memory" as a general architecture-overview blog post; not opened or quoted independently during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# 2Q: A Low Overhead High Performance Buffer Management Replacement Algorithm (Papers We Love)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | 2Q: A Low Overhead High Performance Buffer Management Replacement Algorithm |
+| Source URL | https://paperswelove.org/papers/2q-a-low-overhead-high-performance-buffer-manageme-98fa2c32/ |
+| Source type | paper (hosted copy of the original Johnson & Shasha 1994 VLDB paper) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "approximate LRU algorithm CLOCK 2Q low write overhead cache eviction database" as the original primary paper behind the 2Q algorithm already summarized at Tier 1 via `arpit-2q-cache-algorithm.md`'s explainer; this is the primary document itself, logged here rather than promoted to Tier 1 because this research pass worked from the explainer, not a direct read of the original paper's full text.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Relatime Drive Access Optimization
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Relatime Drive Access Optimization |
+| Source URL | https://docs.redhat.com/en/documentation/Red_Hat_Enterprise_Linux/7/html/power_management_guide/relatime |
+| Source publisher / author | Red Hat (official product documentation) |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (RHEL 7 era documentation) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Official Red Hat documentation of the Linux `relatime` mount option, which is the single clearest, most battle-tested real-world precedent found in this entire subject for "track last-access time without writing on every single access." `relatime` has been Linux's default mount behavior since kernel 2.6.20.
+
+## Key findings
+
+- The underlying problem: maintaining atime (access time) traditionally requires a write to storage on every read, even when the read itself was satisfied entirely from page cache — turning cheap reads into disk writes purely for bookkeeping.
+- `noatime` disables access-time tracking entirely, but this can break software that depends on it (some mail clients comparing mtime/atime to determine unread status, `tmpwatch`, some backup tools).
+- `relatime` (the default since kernel 2.6.20) is the middle ground: atime is only written to disk if the file has been modified since atime was last updated, OR if the existing atime is older than a threshold (default: one day).
+- `lazytime` goes further: atime/mtime/ctime updates are kept purely in memory and only flushed to disk on a non-time-related change, an explicit `fsync`/`syncfs`/`sync` call, or inode eviction — acceptable under POSIX specifically because there's no crash-durability guarantee for a value without an explicit fsync.
+
+## Pros / strengths
+
+- This is a genuinely load-bearing, decades-battle-tested real-world precedent, not a theoretical cache-algorithm paper — Linux runs this exact tradeoff on essentially every filesystem read on the planet.
+- Gives two distinct, usable patterns at two different levels of aggressiveness: `relatime`'s "write only if stale" rule maps directly onto a conditional SQL `UPDATE ... WHERE last_used < threshold`; `lazytime`'s "batch in memory, flush later" maps onto an in-process batching layer if the simpler approach ever proves insufficient.
+
+## Cons / limitations / caveats
+
+- This is filesystem-level precedent, not database-level — the exact mechanics (inode eviction, fsync semantics) don't transfer literally to a SQLite table, only the *principle* (don't write on every read; write only when stale, or batch in memory) transfers.
+- The one-day default staleness threshold for `relatime` is tuned for filesystem atime semantics and general-purpose workloads; it is not necessarily the right throttle window for tai's `last_used` tracking, which this subject's conclusion separately estimates at roughly one minute as a starting point — that number is this project's own guess, not something `relatime` itself recommends.
+
+## Relevance to tai
+
+This is the primary justification, cited directly in this subject's conclusion, for using a throttled/conditional-UPDATE pattern (`UPDATE ... WHERE last_used IS NULL OR last_used < ?`) instead of an unconditional write on every hit — the exact same engineering tradeoff Linux already made, battle-tested at a far larger scale than tai will ever need.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# rmarcus.info Database Paper Browser — Clock2Q+ entry
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Database Paper Browser (rmarcus.info dbscholar) |
+| Source URL | https://rmarcus.info/dbscholar/papers/hc626719af823404a |
+| Source type | other (paper-browser/aggregator entry) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "approximate LRU algorithm CLOCK 2Q low write overhead cache eviction database" as an entry in Ryan Marcus's personal database-paper browser tool, pointing to Clock2Q+-related material. Two further rmarcus.info paper-browser pages (`https://rmarcus.info/dbscholar/papers/8213` and `https://rmarcus.info/dbscholar/papers/he7c2c6333f9a3929`) also surfaced during the same and related searches and are treated as the same source family — logged under this one card rather than filed separately, since all three are the same aggregator tool pointing at adjacent database-paper-browser entries rather than independently distinct content.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Is there advantage of using Integer in table column created_at? (SitePoint forum)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Is there advantage of using Integer in table column created_at? |
+| Source URL | https://www.sitepoint.com/community/t/is-there-advantage-of-using-integer-in-table-column-created-at/343308 |
+| Source type | forum thread |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing" as a directly on-topic forum thread (integer vs. other types for a timestamp column); not opened or quoted independently during this pass beyond what's already captured in the Tier 1 dossier for the primary SQLite forum source.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# SQLite Forum — second datetime-related thread
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | (SQLite Forum thread, title not individually captured) |
+| Source URL | https://sqlite.org/forum/info/5203f28a039a028754fda31591bbfb3c9ca9a949277cb45d789a2f78aecbd52f?t=c |
+| Source type | forum thread |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing" as a second, distinct SQLite forum thread from the one used as the Tier 1 source (`sqlite-forum-timestamp-integer-vs-text.md`); not opened or quoted independently during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,50 @@
+# SQLite Forum: INTEGER vs TEXT timestamp storage discussion
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | SQLite Forum post on date/time storage representations |
+| Source URL | https://sqlite.org/forum/forumpost/92d9dbc02808629a?raw |
+| Source publisher / author | SQLite official forum (community post, unnamed individual poster) |
+| Source type | forum thread |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+A SQLite community forum discussion on the tradeoffs between storing timestamps as Unix-epoch INTEGER versus ISO-8601 TEXT. Explicitly an opinion/forum post, not a controlled benchmark — the search tool itself flagged this distinction, which this dossier preserves.
+
+## Key findings
+
+- SQLite has no dedicated datetime column type; it natively supports three representations: TEXT (`YYYY-MM-DD HH:MM:SS.SSS`), REAL (Julian day number), and INTEGER (Unix time).
+- The forum poster's argument for integers: faster indexed range queries (`BETWEEN`/`>=`/`<=` directly on the integer index), no text parsing needed, smaller storage footprint than ISO-8601 text.
+- The poster's argument is explicitly their own opinion, not a measured benchmark, per the search synthesis of this thread.
+- Integer Unix timestamps are unambiguous across daylight-saving-time transitions in a way that naive local-time text values are not (a correctness point, separate from the raw-speed point).
+- A counterpoint noted in the broader discussion: ISO-8601 text sorts correctly as a plain string and remains the most human-readable choice; its index entries are simply larger, not functionally broken.
+
+## Pros / strengths
+
+- Directly surfaces both sides of exactly the tradeoff this subject's conclusion needed to resolve (integer vs. text for a `last_used` column), from a venue (SQLite's own community forum) with direct relevant expertise.
+
+## Cons / limitations / caveats
+
+- Self-admittedly opinion-based, not a controlled benchmark — no actual timing numbers were produced in the material reviewed. The practical recommendation this subject reaches (use INTEGER for `last_used` specifically, because it's a hot, comparison-heavy column, while leaving the vault's other timestamp columns as ISO-8601 TEXT) is a judgment call informed by this thread's reasoning, not a number verified against tai's actual workload.
+
+## Relevance to tai
+
+Directly informs the one explicitly-flagged exception in this subject's conclusion: recommending `last_used` be stored as Unix-epoch INTEGER even though every other timestamp column in tai's vault schema is ISO-8601 TEXT, specifically because this column is compared/sorted/range-scanned on the hot path in a way the others generally are not.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,47 @@
+# SQLite source history: bm25() sign-convention change
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | SQLite source/commit history entry concerning the bm25() auxiliary function |
+| Source URL | https://sqlite.org/src/info/3ee7b5a9f987c269 |
+| Source publisher / author | SQLite project (official source repository) |
+| Source type | other (source control history entry) |
+| Source date (published) | Unknown — not stated (historical commit; exact date not captured by this research pass) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+A SQLite source-history record documenting that the `bm25()` FTS5 auxiliary ranking function's result is multiplied by -1, so that a *lower* (more negative) score means a *better* match — meaning correct usage requires `ORDER BY rank` ascending, not descending, which is the opposite of the intuitive "higher score = better" assumption.
+
+## Key findings
+
+- `bm25()` scores are inverted relative to naive expectation: better matches produce lower (more negative) numbers.
+- Consequently, ranking queries must sort ascending (`ORDER BY rank` with no `DESC`) to get best-matches-first, not descending.
+
+## Pros / strengths
+
+- Primary-source (SQLite's own project history) confirmation of a detail that is easy to get backwards and silently misrank results if assumed rather than checked.
+
+## Cons / limitations / caveats
+
+- This is a narrow, mechanical fact about FTS5's API, not itself evidence about recency tracking or write amplification — it's included here because it surfaced in the same research query about combining BM25 with recency-aware ranking, and is directly relevant to *correctly implementing* any future phase that blends `last_used` into search ranking.
+
+## Relevance to tai
+
+Tai's existing `fts_search()` code already sorts by `bm25(fts_docs)` ascending (confirmed independently in the codebase, not from this source) — this dossier exists so that if/when a future phase blends a recency signal into ranking, whoever implements it does not accidentally assume "higher bm25 score is better" and invert the ranking.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Tarantool Vinyl: throttle tx to ensure compaction keeps up with dumps (patch series)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | vinyl: throttle tx to ensure compaction keeps up with dumps |
+| Source URL | https://lists.tarantool.org/pipermail/tarantool-patches/2019-January/004332.html |
+| Source type | other (mailing-list patch series) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "throttled lazy timestamp update avoid write amplification last_accessed database pattern". This research pass's own synthesis explicitly flagged this result (and two further patch-series revisions in the same thread, v2 and v3, treated here as the same source family) as off-target/tangential: it concerns throttling transactions to keep LSM-tree compaction ahead of memory dumps in Tarantool's Vinyl storage engine, which is a related-but-distinct throttling concern from the specific "don't write a timestamp on every read" pattern this subject needed. Logged honestly as a near-miss rather than omitted or misrepresented as directly on-topic.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed (off-target / tangential to this subject). |
@@ -0,0 +1,28 @@
+# USENIX 2001 — Zhou et al., trace analysis section
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | (USENIX 2001 full paper by Zhou et al., "Traces" section) |
+| Source URL | https://static.usenix.org/event/usenix01/full_papers/zhou/zhou_html/node3.html |
+| Source type | paper |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LRFU combined recency frequency cache replacement formula least recently frequently used" as a related-work mention alongside LRFU, FBR, LRU-K, 2Q, and ARC; this specific "Traces" section of a 2001 USENIX paper was not independently opened during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Preventing write amplification during frequent data updates (US Patents 10,037,155 B2 and 11,494,276 B2)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Preventing write amplification during frequent data updates; Reduced write amplification using small-block log |
+| Source URL | https://patents.google.com/patent/US10037155 (related: https://patents.google.com/patent/US11494276B2) |
+| Source type | patent |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "throttled lazy timestamp update avoid write amplification last_accessed database pattern" as two related patents on write-amplification mitigation in storage systems; logged together as one source family since both surfaced from the same query for the same general concern and neither was independently opened. These are storage-device/firmware-level write-amplification patents (a different mechanism, closer to SSD wear-leveling concerns) rather than the database-row-update write amplification this subject's conclusion is actually about — flagged here as adjacent-but-distinct, consistent with this research pass's honesty requirement.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed (adjacent concern: storage-level, not row-update-level, write amplification). |
@@ -0,0 +1,28 @@
+# System and method for implementing an adaptive replacement cache policy (US Patent 6,996,676 — the ARC patent)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | System and method for implementing an adaptive replacement cache policy |
+| Source URL | https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/6996676 |
+| Source type | patent |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LRFU combined recency frequency cache replacement formula least recently frequently used" — this is the patent underlying the well-known ARC (Adaptive Replacement Cache) algorithm, notable by name even though this research pass did not open or independently verify its specific claims. Worth flagging for a future deeper pass given ARC's real-world prominence (used in ZFS, among other systems), but out of scope for the current tracking-only proposal.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# System and method for adaptively managing pages in a memory (US Patent 7,167,953)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | System and method for adaptively managing pages in a memory |
+| Source URL | https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/7167953 |
+| Source type | patent |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "LRFU combined recency frequency cache replacement formula least recently frequently used" as a patent in the adaptive-page-replacement space; not opened or quoted during this pass. Patents in this space are logged for completeness but treated with extra caution since patent claims describe legal scope, not necessarily the clearest technical explanation — the LRFU explainer content used for the subject's background research came from academic-paper summaries, not this patent.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Mem0 vs Letta (MemGPT): AI Agent Memory Compared (2026)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Mem0 vs Letta (MemGPT): AI Agent Memory Compared (2026) |
+| Source URL | https://vectorize.io/articles/mem0-vs-letta |
+| Source type | blog post (vendor-adjacent comparison) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "MemGPT Letta memory tiering LRU eviction agent context management" as a direct comparison of the two leading products discussed in this subject's Tier 1 dossiers; a strong candidate for deeper reading in a future pass, but not opened or quoted during this one since the vendor-primary sources were used instead.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# VLDB 1994 DBLP bibliography listing
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | VLDB '94 proceedings — DBLP bibliography listing |
+| Source URL | https://mail.vldb.org/dblp/db/conf/vldb/vldb94-439.html |
+| Source type | other (bibliography index page) |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "approximate LRU algorithm CLOCK 2Q low write overhead cache eviction database" as the DBLP bibliographic record for the VLDB 1994 proceedings containing the original 2Q paper; purely a citation-index page, not opened for content.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# WebmasterWorld PHP forum — datetime index thread
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | (WebmasterWorld PHP forum thread, title not individually captured) |
+| Source URL | https://www.webmasterworld.com/php/3532632.htm |
+| Source type | forum thread |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing"; a MySQL-focused (not SQLite) forum thread on the same general timestamp-type question, which the search synthesis noted concluded with "there is no substitute for running your own performance tests." Not opened directly or quoted beyond that one summarized takeaway, which is instead recorded in the `sqlite-forum-timestamp-integer-vs-text.md` Tier 1 dossier.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# DateTime to SQLite (Xojo forum thread)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-memory-recency-tracking |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | DateTime to SQLite |
+| Source URL | https://forum.xojo.com/t/datetime-to-sqlite/42307?page=2 |
+| Source type | forum thread |
+| Date researched | 2026-10-09 |
+| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the search "SQLite last_accessed column unix timestamp vs datetime performance indexing" as a Xojo-framework-specific forum thread on converting DateTime values for SQLite storage; not opened or quoted during this pass.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-09 | Logged as consulted-but-not-analyzed. |