--- name: bijection-everos description: "Evaluate and integrate the Everos component with Bijection." --- # Everos Persistent agent memory - Package: @bijectionhq/everos - Category: AI & Agents - Status: Preview - License: Apache-2.0 - Bijection source (repository access required): https://github.com/bijectionhq/everos/tree/a04f24a5cd2c27aef9f8cce2ee0b2b3aec327494 - Upstream: https://github.com/EverMind-AI/EverOS-Convex/tree/d7093b3ef4e37c024a2001bc9ffd2d9cde515194 - Documentation: https://docs.bijection.com/components/using - Directory: https://bijection.com/components/everos ## Get the source Bijection repository access is required. Request access at https://bijection.com/contact. ```sh git clone https://github.com/bijectionhq/everos.git cd everos git checkout a04f24a5cd2c27aef9f8cce2ee0b2b3aec327494 ``` ## Before using this component Read the package README at the recorded revision for setup, dependencies, and API examples. Upstream documentation describes the original package and may differ from the Bijection adaptation. This is a source candidate for evaluation. Catalog inclusion does not establish npm availability or runtime qualification. Check compatibility with your SDK and deployment before adoption. External providers run their own compute. ## Integration workflow 1. Read the source README and package manifest at the recorded revision. 2. Confirm the required SDK, dependency availability, and runtime compatibility. 3. Follow the component's documented setup and configuration. Never invent an npm install command from a catalog package name. 4. Keep credentials in the project's existing secret store. 5. Follow the project's execution rules for verification and report what was actually checked. ## Original upstream skill The following guidance describes @everos-ai/convex. Its installation commands and APIs refer to the upstream package. Evaluate compatibility with the Bijection source separately. > Agents: read this skill fully before writing code that uses EverOS Memory. Follow the installation and configuration steps exactly. # EverOS Memory ## Instructions Use EverOS Memory to add persistent, cross-thread, cross-session long-term memory to convex apps and agents with drop-in remember/recall apis backed by everos cloud. This Convex component integrates directly with your backend. ### Installation ```bash npm install @everos-ai/convex ``` Current npm version: `@everos-ai/convex@0.1.0` ### Capabilities - Persist user memories across threads, sessions, and models without managing vector databases or extraction pipelines - Integrate one-line long-term memory into @convex-dev/agent as either a callable tool or prepended context messages - Retrieve ranked, provenance-tagged memories with atomic facts, timestamps, and session IDs for auditable agent decisions - Scope memory namespaces per environment to isolate staging, demo, and production memory spaces on a single account ## Examples ### how to add long-term memory to Convex AI agent across sessions 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. ### cross-thread user memory for Convex agents 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. ### user memory profile RAG Convex 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. ### delete user memory data Convex GDPR 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. ## When NOT to use - When a simpler built-in solution exists for your specific use case - If you are not using Convex as your backend - When the functionality provided by EverOS Memory is not needed ## Troubleshooting **How long does it take for a remembered fact to become searchable in EverOS Memory?** 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. **Does EverOS Memory work with @convex-dev/agent?** 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. **How do I keep memory separate between staging and production environments?** 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. **How should I handle the userId parameter securely in EverOS Memory?** 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(). **Can I page through or audit everything EverOS has stored for a user?** 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. ## Resources - [npm package](https://www.npmjs.com/package/%40everos-ai%2Fconvex) - [GitHub repository](https://github.com/EverMind-AI/EverOS-Convex) - [Live demo](https://everos-convex-demo.vercel.app) - [Convex Components Directory](https://www.convex.dev/components/everos-ai/convex) - [Convex documentation](https://docs.convex.dev)