OpenLoomi vs. EverOS: An In-Depth Comparison Report

Written by OpenLoomi AI

1. Project Overview

These two projects belong to different categories. OpenLoomi is a product (an installed workspace with desktop, web, and CLI) that uses memory internally to drive proactive behavior. EverOS is a library (a Python package + local HTTP runtime) whose entire value is being the memory layer for self-built agents. We treat the two differently for the remainder of this report: it's like comparing a complete car to an engine you can drop into any vehicle.

2. Tech Stack Comparison

2.1 Runtime and Language

2.2 AI / LLM Integration

2.3 Database and Storage

2.4 Messaging Platform Integration

Honest note: EverOS has no first-party messaging integrations. It is a memory layer, not a transport gateway. To send messages, you need to hook EverOS behind an agent that already has transport capability (e.g., a Telegram bot or Slack app), or behind the connectors that OpenLoomi already ships.

3. Core Architecture Comparison

3.1 Memory and Agent Architecture

OpenLoomi — The Proactive AI Loop

Pull (21+ connectors)
  → Persist (raw signals)
    → Augment (openloomi-memory four-tier structure)
      → Memory (vector + graph)
        → Filter (95% noise)
          → Convert to strictly-typed decisions (5 hard types)
            → Enqueue (data/decisions.json)
              → Execute (native agent API or derived CLI)
                → State feedback

• Four-tier memory architecture: raw info → info insight → contextual memory → knowledge graph (see skills/openloomi-memory/SKILL.md).
• Five strictly-typed decisions emitted by the Loop: rsvp, email_reply, review_pr, todo, im_reply (with support for extensible typed payloads).
• Memory Consolidation runs as a standalone package, rewriting long-term context out of the short-term buffer.
• Obsidian vault scanner reads external Markdown vaults and weaves them into memory, letting users who already take notes in Obsidian keep their source of truth.

EverOS — The Portable Memory Pipeline

Add (caller pushes text/media)
  → In-process buffer
    → Boundary detector (split episodes)
      → MemCell (typed memory unit)
        → Synchronous write to episode.md
          → AgentMemoryPipeline (embed + index)
            → OME (Orchestrated Memory Engine) tags
              → Cascade daemon (monitor the file system)
                → LanceDB upload (vector + BM25)

• Four tracks + Knowledge Wiki: episodes and profile (user side), cases and skills (agent side), plus an editable Knowledge Wiki.
• Markdown is the canonical store — every memory write lands on an actual .md file you can cat, diff, grep, and git-version.
• Cascade listener watches the Markdown directory tree; if you manually edit files, LanceDB rebuilds the index automatically.
• Reflection is an offline evolution step that merges similar episode clusters and polishes profile/skill tracks between sessions.

3.2 Skill System

3.3 Tool System

4. Deployment and Operations Comparison

4.1 Deployment Models

4.2 Multi-Instance and Isolation

5. Security and Privacy Comparison

6. Developer Experience Comparison

6.1 Debugging and Testing

6.2 Documentation and Extensibility

7. Key Difference Summary

7.1 Positioning Differences

7.2 Feature Matrix

7.3 Complexity Comparison

8. Summary and Selection Guide

OpenLoomi is a product — install it, connect your accounts, and the Loop runs in the background, surfacing decisions and acting proactively. EverOS is a library — import it from your own Python agent, call add / search, and that agent gains persistent, Markdown-native memory that self-evolves between sessions. The two are not direct competitors; they sit at different layers of the stack.

1. Choose OpenLoomi when:

• You need a proactive AI workspace that actively monitors and pushes information
• You want a desktop app (Windows / Mac / Linux) plus web, as a single installed product
• You want first-party OAuth token encryption for connected services
• You want 21+ messaging and productivity connectors already integrated (Telegram, WhatsApp, iMessage, Gmail, Slack, Lark/Feishu, DingTalk, WeCom, QQ, WeChat, Calendar, RSS…)
• You want an MCP interface natively callable by other tools and agents
• Compared to raw memory dumps, you prioritize noise filtering and a strongly-typed decision panel
• You want something a non-technical user can pick up and use directly

2. Choose EverOS when:

• You are building an agent and need a memory layer to mount under it
• You want Markdown as the source of truth — readable, diff-able, git-version-able, hand-editable
• You need out-of-the-box hybrid vector + BM25 retrieval (LanceDB)
• You want memory to self-evolve via offline Reflection — merging and polishing between sessions
• Compared to a full product install, you want lightweight, single-language Python dependencies
• You want orthogonal namespaces (user_id × agent_id × app_id × project_id × session_id) to support multi-tenant agent clusters
• You want a Knowledge Wiki with a CRUD API, ready for RAG frontends

In practice, the two are complementary, not competitive. OpenLoomi uses memory; EverOS is memory. If OpenLoomi eventually opens up its memory-consolidation package as a standalone, pip-installable library (carrying on the everalgo-parser lineage), the two projects could meet at the same API boundary — that would be a genuinely worth-watching, worth-anticipating integration direction.

9. Memory Architecture Deep Dive: Holistic Context vs. EverOS Memory

This section compares the two systems at their most architecturally structured and differentiated memory layer.

9.1 Holistic Context — Eight Specific Features

9.2 EverOS Memory — Nine Specific Features

9.3 Fourteen Specific Differences

9.4 Design Trade-offs

OpenLoomi treats memory as the AI's cognitive structure — through organization, weighting, forgetting, and association, it proactively supports agent reasoning. The minimum unit of work is the AI's mental model. SQLite storage gives the system a fast, queryable substrate built for large-scale retrieval.

EverOS treats memory as the user's data asset — it must be human-readable, editable, and version-controlled. The minimum unit of work is the Markdown file. The trade-off is no runtime weight scoring and no time-travel queries.

This produces three specific trade-offs:

1. Queryable vs. human-readable — OpenLoomi puts data in SQLite tables for efficient, large-scale structured queries; EverOS puts it in .md files, optimized for human readability.
2. Proactive reasoning vs. hand-editing — OpenLoomi's evolution is AI-led (4-signal scoring, boost/decay, active/dormant, trend); EverOS allows humans to intervene directly by editing files.
3. Product-grade isolation vs. cross-agent portability — OpenLoomi's memory is part of the product (strong profile isolation, never leaks between users); EverOS's memory naturally supports cross-agent sharing via orthogonal namespaces.

9.5 Memory Architecture Capability Matrix

This matrix uses ✅/❌ markers to make the capability gaps in the memory architecture layer explicit. ⚠️ indicates partial / different implementation.

The asymmetry is structural: OpenLoomi leads on AI-driven runtime memory management (scoring, weighting, lifecycle, associations), while EverOS leads on file-level portability, human editability, and agent-agnostic infrastructure (Markdown canonical, bi-directional sync, orthogonal namespaces, knowledge wiki, emergent skills).

10. Capabilities OpenLoomi Has That EverOS Doesn't

EverOS is a library (not a product), so by design it omits every product-form capability. This gap is structural, not accidental.

10.1 Product Form (EverOS Has None of These)

10.2 Messaging and Productivity Integrations (EverOS Has None)

OpenLoomi ships first-party connectors out of the box: Telegram, WhatsApp (Baileys), Discord, Slack, iMessage, Lark/Feishu, DingTalk, QQ, WeChat, Gmail, RSS, Calendar. EverOS is a memory layer, not a transport gateway.

10.3 Proactive Behavior (EverOS Has None)

10.4 Memory Architecture Differentiated Capabilities

10.5 Execution and Tooling (EverOS Has None of These)

Browser automation (agent-browser + CUA driver), code execution (Vercel Sandbox), web search (Brave Search via Composio), voice input (Tauri), 30+ MCP tools, native agent API, multi-runtime support (Claude Code + OpenCode CLI).

Why this gap is structural: EverOS's entire value is statelessness and embeddability. Any product-form capability would couple it to a UI surface or a transport protocol — the opposite of "memory library" positioning. This gap is the price of portability.

11. Benchmark Comparison

This section compares the two systems' externally-published evaluation results on standard long-context memory benchmarks.

11.1 Evaluation Methodology Differences

11.2 Result Highlights

11.3 Reading the Numbers

OpenLoomi is tuned for decision-grade memory — the benchmarks reflect what is needed to drive a proactive Loop: temporal validity, weight scoring, and noise filtering. Results move with the product's north-star metric (signal-to-decision ratio).

EverOS is tuned for evolving frontier — Locomo is where the merging/reflection cycle shows up; the numbers reflect what their surface area changes: episode clustering, reflection consistency, and name-entity drift. Results move with how aggressively they expand to longer conversations.

The two benchmarks answer different questions. Combining them gives a fuller picture of a memory engine than either alone.

11.4 Take-aways for Practitioners

• If you care about decision quality over long horizons and noise tolerance under high signal volume, OpenLoomi's published numbers are the relevant signal.
• If you care about cross-session recall fidelity and agent-portable memory organization, EverOS's Locomo numbers are the relevant signal.
• For research use, replicating either benchmark locally takes ~2 hours on a single H100; the gating cost is dataset licensing, not compute.