Add persistent, cross-thread, cross-session long-term memory to Convex apps and agents with drop-in remember/recall APIs backed by EverOS Cloud.
npm install @everos-ai/convexEverOS Memory provides persistent, cross-thread, cross-session long-term memory for Convex apps and agents via the EverOS Cloud API. It exposes `remember` and `recall` methods that handle async memory extraction, local pending queues, and ranked retrieval with atomic fact provenance. The component integrates directly with `@convex-dev/agent` as either a tool or context injection, making user memory portable across agents, models, and sessions without requiring manual vector search infrastructure.
EverOS Memory provides everos.remember() and everos.recall() methods that persist and retrieve user memories across any number of threads and sessions. For @convex-dev/agent, you can attach long-term memory as a tool via everos.asTool({ userId }) or prepend recalled memories as context using everos.contextMessages(). Memories are stored in EverOS Cloud and remain searchable across model changes and new conversation threads.
EverOS Memory stores user memories outside of conversation threads so a new agent or model can immediately access what a user has shared in previous sessions. The recall API returns ranked episodic memories and a semantic user profile, each with provenance including session ID and timestamp. This enables use cases like handing off a support conversation to a specialist agent that has never seen the chat history but still knows the user's context.
EverOS Memory maintains both episodic memories and a persistent user profile extracted from ingested content. The everos.recall() method returns ranked episodic results alongside the user's profile in a single call, giving RAG pipelines structured, deduplicated context rather than raw chat log chunks. You can also call everos.getProfile() directly to fetch only the semantic profile.
EverOS Memory provides everos.forgetUser() to delete all memories for a given user both locally in the Convex component queue and remotely in EverOS Cloud. For session-level deletion, everos.forgetSession() removes only the memories associated with a specific session ID. The component does not retain copies after EverOS has extracted them, so deletion through these methods is comprehensive.
EverOS Memory runs extraction asynchronously in the background. After calling everos.remember(), extracted memories are typically searchable within 15 to 30 seconds. During that window, everos.recall() still returns the raw content from the component's local queue marked with pending: true, so recently ingested content is never invisible to your application.
Yes. EverOS Memory is designed to integrate directly with @convex-dev/agent. You can expose memory search as a tool the model calls using everos.asTool({ userId }), or prepend recalled memories as a message array using everos.contextMessages(). Both @convex-dev/agent 0.6 and 0.7 are supported.
EverOS Memory supports namespacing via the appId and projectId options passed to new EverOS(components.everos, { appId: 'staging', projectId: 'staging' }). All reads, writes, and deletes are scoped to that namespace. Using separate API keys on the same account does not isolate namespaces; you must use appId and projectId for that.
The EverOS Memory component does not perform authentication itself. The userId parameter controls which user's memory is read or written, so it must always be derived server-side from your app's auth system, for example from ctx.auth.getUserIdentity(). Passing a client-supplied userId as an argument would allow any caller to read or delete another user's memories via everos.recall() or everos.forgetUser().
Yes. EverOS Memory provides everos.listMemories({ userId, page, pageSize }) to paginate through all memories stored for a user in EverOS Cloud, returned newest first. Each recalled memory also includes atomicFacts with individual scores and timestamps, and a sessionId for tracing which conversation produced the memory.