Setup
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
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.