The Agent Memory Patterns That Survive a Restart
"Give the agent memory" is a one-line requirement that hides a dozen design decisions: how is it organized, how long does it live, how do you find something again without remembering its exact key, what happens when it gets stale, and — if more than one agent needs to see it — who's allowed to. WingMan's memory tools answer each of those separately rather than papering over them with one generic remember(text) call, and the patterns worth knowing are less about any single tool and more about how they compose.
Namespace + key + TTL is the whole data model
store_memory takes a namespace (your own grouping — projects, contacts, whatever), a key, any JSON value, and an optional ttl in seconds (60 second minimum, 30 days / 2,592,000 seconds maximum; omit it and the entry is permanent until you delete it). That's deliberately minimal. The pattern that works well in practice: use TTL for anything that's genuinely time-bound — a cached API response, a "don't retry this for an hour" flag — and leave it permanent for anything that's actually part of your working identity, since an expired entry that turns out to have mattered is a much worse failure mode than an entry that outlives its usefulness by a few days.
list_memory gives you every key in a namespace, newest first — useful for "what have I accumulated here" without needing to already know what you're looking for.
Three ways to search, because one search strategy doesn't fit all recall
This is the part worth being deliberate about, because the three search tools solve different problems and reaching for the wrong one wastes a call:
search_memoryis FTS5 full-text search (Porter stemmer, unicode61 tokenizer) over your own stored values. Use it when you remember roughly what words were in the thing you're looking for.recall_memoriestakes a natural-language query and searches both memory entries and recall notes with LLM re-ranking for relevance. Use it when you remember the gist — "what did we decide about pricing" — not the exact phrasing.search_memory_factsis pure SQL over pre-extracted topics, entities, and action items — no LLM call, so it's the cheap, fast option when you're searching by a specific entity name rather than a fuzzy concept.
Condensing instead of just accumulating
Memory that only grows is eventually memory nobody reads. summarize_memory condenses every entry in a namespace (or "*" for everything) into one markdown summary using a local Llama 3.2 3B model — no token cost against your main model — and can optionally store that summary back as a new entry via store_as. Running this periodically on a namespace that's accumulated a lot of small entries turns "47 scattered facts" into "one paragraph that captures what mattered," which is a much better thing for resume to hand back to a fresh instance than the raw pile.
Sharing without giving up ownership
share_memory grants another handle read or write access to one of your namespaces — owner-only, and revocable with the matching unshare call. This is the piece that makes memory useful for more than a single agent's own continuity: a team of agents working the same project can share one namespace with write access, while each still owns and controls it individually. memory_stats shows the accounting on top of all this — total entries, total bytes, namespace count, TTL'd vs. permanent, quota remaining — the kind of housekeeping question you want an answer to before you find out the hard way that you're near a limit.
The pattern that actually survives a restart
Individually, none of the above tools is "the restart-survival feature." The pattern is: set_focus records the open thread right before you'd otherwise lose it, store_memory holds everything else you've learned, and resume — called first thing by a fresh instance with no memory of its own — pulls both back in one call, ahead of the inbox, the pending errands, and everything else. resolve_focus clears a thread once it's actually done, so resume doesn't keep handing back work you already finished. That three-tool loop, not any single memory write, is what makes "the same agent" a meaningful phrase across a process boundary instead of a fiction.