The author describes a pattern where worker agents emit structured memory events instead of writing directly to shared memory, using a Memory Curator to validate, deduplicate, and route them to appropriate scopes, aiming to prevent memory pollution in multi-agent systems. They compare this approach to existing frameworks and solicit community feedback.
After scaffolding a project-level memory owner a while back, the issue that kept biting me got finer-grained. Even with a project-scoped orchestrator, worker agents were still writing things straight into shared memory, and the store was getting polluted fast. Temporary guesses saved as durable facts. Project-specific decisions ending up in reusable team rules. Private context leaking into public artifacts because the worker did not know which scope it was writing to. The pattern I am testing now puts a specialist between workers and the memory store. Worker agents do not write memory at all. They emit structured memory events with a proposed scope and evidence. A separate Memory Curator agent validates, redacts, deduplicates, and routes the event to one of four scopes, or discards it outright. The four scopes I am working with are agent repo memory (durable design decisions for a single agent), agent team memory (cross-agent procedures, handoff standards, safety rules), project memory (current state, decisions, risks for one engagement), and session scratch (temporary observations that probably should not survive). The mapping in mind was to human and organizational memory categories: individual specialist memory, transactive team memory (Ren and Argote), project memory, and short-term working memory. The default routing rule is conservative. If an event is temporary, unsupported, ambiguous, or private, it goes to session scratch or gets discarded. Durable memory is earned, not automatic. The event schema is JSON with type tags for fact, decision, preference, risk, procedure, hypothesis, plus an evidence reference and a proposed scope. The curator can override the proposed scope and is the only writer to durable stores. The lineage I see this sitting in is MemGPT and MemoryBank for memory hierarchy, LEGOMem and AgentSys for modular and hierarchical agent memory, and Generative Agents for the reflection pattern where observations get distilled into longer-term memory. The transactive memory work from organizational research is where the team-vs-individual distinction comes from. Two things I am unsure about. First, whether the event-emission requirement adds enough friction to worker agents that they start either over-emitting (everything becomes a candidate event) or under-emitting (workers quietly stop bothering and useful observations get lost). Second, whether routing accuracy holds up as the number of projects grows, since session-vs-project boundaries blur on long sessions and project-vs-team boundaries blur when one project's lesson actually generalizes. Repo: reply Curious whether anyone running multi-agent setups has tried something similar. Specifically: do you let workers write directly and run a cleanup pass later, or gate writes through a curator up front? Cleanup-after is operationally easier but I suspect pollution accumulates faster than it gets removed.
A Memory Curator Agent pattern separates memory governance from worker agents, improving the quality and relevance of durable memory by having a dedicated agent evaluate and route memory events into appropriate scopes.
A discussion on the practical challenges of managing agent memory in AI systems, focusing on avoiding information overload that degrades output quality, and proposing strategies like using workflow state and multi-agent architecture.
The author proposes that durable memory in multi-agent AI systems should reside with the project owner, not with task specialists, drawing inspiration from consulting firm practices and academic literature on project memory. They present a research scaffold with templates and evaluation rubrics for a field trial.
A developer reconsiders agent memory as more than storage, proposing a living graph with roles and activation fields to give past information appropriate authority and context.
The author argues that 'agent memory' is the wrong first framing because it conflates working state and durable memory, leading to debugging issues. They advocate separating messy working state (which should expire) from strict durable memory with provenance and authority.