A Production MultiAgent Memory System Splits Short-Term Context from Four-Layer Long-Term Recall
Most agent memory discussions stop at “stuff history into the prompt.” This architecture shows what a production-grade split actually looks like: parallel async loading, token budgets per scope, similarity dedup, conflict resolution, and a write-first persistence strategy that accepts eventual consistency because the memory store is an external service. Teams building multi-agent systems will hit the same boundary problems—session pollution from child agents, summary thresholds, and the impossibility of transactional writes across an HTTP API—and the design choices here are directly transferable.
The memory system treats short-term and long-term recall as two independent, parallel-loaded chains. Short-term memory uses a Redis-cached, MySQL-backed sliding window with token budget control and summary injection; long-term memory routes through MemOS semantic search across user_profile and agent-specific cubes, then allocates a fixed 4000-token budget with a 60% cap for user profile. After a session ends, an async process acquires a distributed Redis lock, marks new messages by MD5 hash for idempotency, runs LLM-based judgment to extract structured memories, performs local Jaccard/Levenshtein deduplication, resolves conflicts against existing memories, and persists new items before best-effort deletion of stale ones.
MemOS retrieval uses fast mode with MMR dedup, a 0.45 relativity threshold, and post-retrieval filtering at score < 0.3 with 1000-character truncation. The write path adopts a write-first, delete-later strategy because MemOS is an external HTTP service and cannot participate in a local transaction. Degradation paths exist throughout: Redis misses fall back to MySQL, LLM judgment failures fall back to rule-based extraction, and long-term memory query failures return empty results without blocking the main dialogue.
The four-layer model (Working, Session, User, Agent) and MemOS content types (text_mem, pref_mem, skill_mem, tool_mem) are explicitly two separate classification dimensions—a distinction most memory discussions conflate.
The platform deliberately does not inject short-term history into the long-term memory query; the two chains are parallel and independent, meaning long-term retrieval runs with an empty context on the first request of a session.
The write-first, delete-later strategy is an explicit acceptance of eventual consistency because MemOS is an external HTTP service that cannot join a local transaction—a constraint any team using a separate memory service will face.
The summary threshold of 20 unsummarized messages and the 2000-token budget are concrete operational numbers that emerged from production tuning, not arbitrary defaults.
The Redis list implementation ignores the lastN parameter for range boundaries, relying instead on application-layer token window trimming—a leaky abstraction that could surprise operators expecting Redis-side limits.
The [[NEW]] marking strategy feeds the full context to the LLM but tags only new messages, letting the model distinguish what needs extraction without losing the surrounding dialogue for disambiguation.