Skip to main content
Anona gives a Strands agent two tools: one to recall, one to remember. No vector database to run, no LLM key of your own, and memory that outlives the process.

Setup

The system prompt matters here: the model decides when to call the tools, so tell it when to. anona_tools() returns two tools, anona_recall_memory and anona_save_memory. The anona_ prefix is deliberate, not decorative: Strands’ tool registry silently keeps whichever tool was registered last when two tools share a name, with no error and nothing logged, so a generic name like recall_memory or memory risks colliding with, and quietly losing to, another tool attached to the same agent.

Why tools rather than a SessionManager

Strands’ SessionManager saves and restores the exact message list. Anona stores synthesized memories, not transcripts, so a restore would hand back something that is not your conversation. Tools describe what we actually do. Use a SessionManager alongside these tools if you also want verbatim session persistence: the two solve different problems and compose fine.
Recent Strands releases also ship a native MemoryManager/MemoryStore system with its own automatic search and add tools. It’s a real synthesized-memory interface, closer in shape to what Anona does than SessionManager is, but you still have to supply and run the backing store yourself. Anona’s tools are the managed alternative: nothing to host, and the search behind anona_recall_memory is the same ranked, deduplicated retrieval the rest of the API uses.

Scoping

Memories written under one user_id are only ever returned to that user, so a single space can back every end customer of your app.

Failure behaviour

If Anona is unreachable, anona_recall_memory reports that it found nothing and the agent continues. anona_save_memory always returns "Saved.", even when the write failed. The bridge behind every adapter never raises, so there’s no failure for the tool to report. Read "Saved." as “handed off,” not as confirmation the memory is durably stored.