feat(agent-memory): Phase 4 — recall reinforcement

[jamby77]

Agent Memory — Phase 4: recall reinforcement

Stacked on #250 (Phase 3). Small phase.

What's new

• Recalled items are reinforced by default: recall() bumps each returned item's last_accessed_at (HSET) and access_count (HINCRBY).
• reinforce: false skips the writes.
• Reinforcement is best-effort — a failure (.catch(() => undefined)) never breaks the recall read path, mirroring agent-cache's "stats failure must not break the cache."

Tests

3 new unit tests (default-on bump, opt-out, failure-doesn't-break-recall); 30 total. tsc --noEmit + prettier clean.

Next

Phase 5 (eviction & TTL — selectEvictions pure selection + capacity/TTL writes).

---

Note

Medium Risk
Changes recall ranking semantics and adds write side effects on every default recall, though failures cannot break reads and deleted keys are guarded.

Overview
Recall reinforcement (Phase 4): After ranking, recall() by default updates each returned memory in Redis—last_accessed_at via HSET and access_count via HINCRBY. Callers can pass reinforce: false to skip writes. Reinforcement is best-effort (errors are swallowed) so the read path always returns hits. Before writing, EXISTS avoids touching keys that were already deleted but still appear in a stale search index.

Ranking change: Recency in compositeScore now decays from max(created_at, last_accessed_at) instead of creation time alone, so bumped access times actually improve future ranking. A new recall test asserts a recently accessed item beats an equally similar stale one when reinforcement is off.

^{Reviewed by Cursor Bugbot for commit e8e841c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1859ed5. Configure here.}

[KIvanow]

One thing I'd like to sort before this merges.

Reinforcement doesn't actually influence recall ranking. reinforce() writes last_accessed_at, but the composite recency term still decays from createdAt (ageSeconds = (now - item.createdAt) / 1000 in recall()); lastAccessedAt is parsed onto the item but never read by the scoring path. So reinforcing a memory does not make it any more likely to be recalled next time, which is the feedback loop the name implies. As it stands the write is effectively inert for recall.

If the intent is that last_accessed_at only feeds Phase 5 eviction (not recall recency), that's fine, but it's worth saying so explicitly, because right now "reinforcement" reads as if it should boost future recall and it doesn't. If recency is meant to reflect access, the composite should use max(createdAt, lastAccessedAt) (or lastAccessedAt) for the age calculation. Either way, worth a one-line decision here so the behavior matches the name.

[jamby77]

@KIvanow Fixed in fc1be01: recall recency now decays from max(created_at, last_accessed_at), so reinforcing a memory genuinely boosts its future recall (the feedback loop the name implies). Added a test asserting a recently-accessed memory outranks an equally-similar stale one.