Lab component — not in the Synedrix OS tech stack·Evaluated under LAB-001·Not required in any deployment mode

Not a Synedrix OS platform. EverOS is not one of the twelve platforms and holds no OS layer.

What EverOS is

EverOS (EverMind-AI/EverOS) is an open-source, local-first agent-memory runtime, self-classified Production/Stable at v1.2.3. It ships a real console script (everos, from everos.entrypoints.cli.main:app) with init, server, cascade, config, and demo subcommands — everos server start --host <host> --port <port> --root <data-dir> runs a genuine FastAPI/Uvicorn HTTP API, not a placeholder.

ConceptWhat it is
StorageMarkdown files as the human-readable source of truth, backed by SQLite for relational state and LanceDB for vector search — no separate database service to run
Memory lifecycleEpisode formation → consolidation → reflection → profile/skill distillation, exposed via an Offline Memory Engine with its own ome.toml strategy configuration
Model slotsThree independent OpenAI-compatible model slots — [llm], [embedding], [rerank] — not one, each pointed at its own endpoint
Capability flagsGET /health reports live flags (llm, embed, rerank, multimodal_llm, parser) and a disabled_features list naming exactly which endpoints are unusable given current config
Case → Skill distillationextract_agent_skill clusters recorded task trajectories (agent_case records) into reusable agent_skill entries — EverOS’s own name for procedural-memory formation

What EverOS is normally used for

  • Local-first agent memory — a self-contained runtime an agent framework can point at without standing up separate vector/relational database services
  • Case-based reasoning — recording task trajectories and distilling them into reusable skills, EverOS’s agent_case/agent_skill mechanism
  • Hybrid text retrieval — EverOS brands this “mRAG,” but it is not multimodal: files are parsed to text at ingest and raw bytes discarded; it is a hybrid BM25 + vector retriever over text only

The common thread: EverOS packages an entire memory lifecycle — capture, consolidation, distillation, recall — as one deployable unit with no companion services, at the cost of shipping its own relational and vector stores rather than using whatever the calling system already runs.

How Synedrix OS uses it

Synedrix OS does not run EverOS in production. LAB-001 evaluates it in isolation, both as a reference for the lifecycle the OS has committed to reimplementing from a written spec, and as a source for the EverMemBench benchmark family Memory Fabric Spec §12 already adopted as the memory evaluation harness.

flowchart LR
  n1([EverOS]):::term
  subgraph What it owns
    n2[Nothing in production]:::agent
  end
  n1 --> n2
  subgraph What it does not own
    n3[Semantic retrieval and similarity search]:::warn
    n4[Qdrant]:::term
    n3 --> n4
    n5[Canonical relational truth]:::warn
    n6[Supabase PG17]:::term
    n5 --> n6
    n7[Explicit relationships]:::warn
    n8[Neo4j]:::term
    n7 --> n8
  end
  n1 --> n3
  subgraph Why EverOS s runtime is not in the stack
    n9[Substrate duplication not capability]:::term
    n10[Markdown-as-truth contests Supabase s role]:::term
    n11[Ambient recall not a governed tool call]:::term
    n12[A confirmed reproducible upstream bug]:::term
    n13[A structural limitation not a config gap]:::term
  end
  n1 --> n9

What it owns

Nothing in production. Inside LAB-001’s isolation boundary, a lab-local EverOS instance runs against synthetic or this repository’s own public documentation — reachable only from lab infrastructure, never from a registered agent, and holding no production tenant data.

What it does not own

ConcernOwner
Semantic retrieval and similarity search — the single vector substrate for Layer 7Qdrant (Layer 7)
Canonical relational truth — business entities, workflow state, approvals, audit trails; write-authoritative for every audit-bearing memory tierSupabase PG17 (Layer 7)
Explicit relationships — workflow and outcome lineage, agent influence networksNeo4j (Layer 7)
Anything a registered agent may recall as memoryThe governed memory fabric (Memory Fabric Spec), never a lab component directly

Why EverOS’s runtime is not in the stack

  • Substrate duplication, not capability. ADR-OS-002 §5.4: “substrate duplication, not capability” is the deciding axis. EverOS is a capable memory runtime; the OS already has a vector store, a relational store, and a graph store, and its organizing rule is one non-overlapping platform per responsibility.
  • Markdown-as-truth contests Supabase’s role. ADR-OS-002 §5.4: EverOS’s Markdown-as-source-of-truth design directly contests Supabase PG17’s write-authoritative position for every audit-bearing memory tier — not a second opinion the OS can hold alongside its own.
  • Ambient recall, not a governed tool call. EverOS’s own runtime confirms the concern in its own words: on binding 0.0.0.0, it logs “binding to 0.0.0.0 exposes the API on all interfaces; EverOS ships no built-in auth — see SECURITY.md.” Memory Fabric Spec §6.1 requires recall to be an authorized tool call, never ambient context; LAB-001’s Q3 is testing whether an authorization shim in front of EverOS’s recall path can close that gap without forking it.
  • Worth evaluating precisely because it is not adopted. LAB-001 exists to test, in isolation and on a time box, whether the practical cost of a second relational and vector substrate is as high as ADR-OS-002 argues — a negative result strengthens that ADR rather than undermining it.

Real findings from standing it up (Phase 8, August 2026)

Not assumed from documentation — EverOS was actually built, run, and exercised:

  • A confirmed, reproducible upstream bug. everos==1.2.3 hard-pins everalgo-agent-memory==0.4.0, which raises TypeError: DetectionResult.__new__() missing 1 required positional argument: 'should_wait' on every call to POST /api/v1/memory/add under agent mode — a 100% failure rate on the agent-memory pipeline as shipped. everalgo-agent-memory==0.5.0 fixes it; applied as a documented, explicit post-install override.
  • A structural limitation, not a config gap. EverOS exposes an EVEROS_EMBEDDING__DIMENSIONS setting, but it is not threaded into LanceDB schema creation — every one of EverOS’s six LanceDB tables hardcodes _DIM = 1024 as a Python module constant. nomic-embed-text (768-dim, this repository’s own production embedding model) can write to EverOS but cannot be searched: the vector index it would write into is fixed at 1024-dim. EverOS’s own default embedding model, Qwen/Qwen3-Embedding-4B, is 1024-dim.
  • What worked end-to-end once both fixes were applied: a synthetic task trajectory was successfully memorized, then force-extracted, confirming the boundary-detection → episode-extraction pipeline is real and functional. Search could not be validated end-to-end due to the dimension limitation above.
  • No MCP server exists, despite one unsubstantiated marketing bullet — the only MCP reference anywhere in the project. Any integration must use a direct Python or HTTP call.

Full findings, including the pre-registered exit-evidence questions this evaluation is scored against, are in LAB-001.

Deployment and licensing

Self-hosting. EverOS requires no companion database service — Markdown, SQLite, and LanceDB all run inside the one process. Deploy as a container running everos server start, or as a local CLI install.

Licence — verified. EverOS is licensed under the Apache License, Version 2.0, confirmed directly against LICENSE in the official EverMind-AI/EverOS repository — matching the position ADR-OS-002 recorded, now re-verified at source per that ADR’s own Open Items.

Official documentation

  • LAB-001 — EverOS Lab Charter — Full evidence, pre-registered exit criteria, and Phase 8 findings.
  • ADR-OS-002 — Memory Fabric Control Plane — §3.1 (the retention instruction this lab discharges) and §5.4 (the rejection rationale).
  • ADR-OS-004 — Lab Lane — The governance mechanism this evaluation runs under.
  • LanceDB and SQLite — The two substrates EverOS ships with, evaluated on their own pages.
  • Memory Fabric Spec — §4/§5 (the record envelope and state machine EverOS’s lifecycle is traced against) and §6.1 (the ambient-recall invariant).

Synedrix OS · Platform reference · Lab · EverOS