- 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>
3.1 KiB
3.1 KiB
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_memoryandadd_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. |