Architecture
The assistant runs the same loop every turn:- Recall: search the user’s memory for context relevant to the message
- Generate: call your LLM with that context
- Persist: store the user and assistant messages back into EverOS
Setup
Store conversation turns
Store each turn into a session. Each message’ssender_id is who it’s attributed
to: the user’s id for their messages, "assistant" for replies. Writes are
asynchronous by default; extraction runs in the background.
Retrieve relevant context
Before generating, search the user’s memory. Episodes are narrative summaries of past conversations and are available within seconds of extraction. The profile (consolidated preferences and traits) builds up over time in the background; request it withinclude_profile=True and use it when present.
Two layers of context, and why you want bothEpisodes are consolidated memory, so they only appear once extraction has run.
unprocessed_messages is the current session’s raw buffer, returned when you
pin one session with filters={"session_id": ...}. It covers the window where
something was just said but hasn’t been extracted yet.Reading both means a brand-new user still gets continuity from their very first
turn, instead of the assistant drawing a blank until the first episode lands.Searching by user_id alone returns episodes only.Complete assistant loop
Best practices
Keep context focused
Keep context focused
Limit retrieved memories so you don’t overwhelm the LLM context window.
Choose the right search method
Choose the right search method
Episodes vs profile
Episodes vs profile
Use episodes for what happened in past conversations (available within
seconds). Use the profile for stable, consolidated preferences and traits.
It’s built in the background over many interactions, so treat it as
optional context that gets richer over time.
Next steps
Retrieval methods
Vector, hybrid, and agentic retrieval in depth.
Python integration
Production patterns: error handling, retries, clean client setup.

