EverOS Memory Runtime
A local-first, portable long-term memory layer for AI agents across applications and workflows.
Per-dimension scores and reasoning
Evidence shows: server defaults to binding 127.0.0.1, docs explicitly warn against exposing to untrusted networks, API keys stored in local .env and never transmitted except to configured providers. This reflects partial least privilege, but lacks user confirmation mechanisms (e.g., no explicit user confirmation before writing/deleting memory). Data flow transparency is described in README and SECURITY.md, but no detailed logging or audit features. Sensitive data handling: docs mention plaintext .md storage and recommend OS-level permissions or disk encryption, but no built-in encryption option. Dependency security: pyproject.toml pins lancedb version range with comments on known issues, but no vulnerability scanning mentioned. External effects: server defaults to local-only, but no description of impact on system files or network. Rollback: no rollback mechanism provided. Source attribution: README lists multiple external integrations, but does not clarify their provenance or trustworthiness.
Evidence shows: project has strict test suite including consistency checks (tests/_consistency_assertions.py) and CI config, indicating good self-consistency. Dependency availability: dependencies clearly listed in pyproject.toml, CI uses uv.lock for frozen versions, but no availability guarantee. Failure messages: docs mention office uploads return HTTP 415 with clear error, but overall error handling not detailed.
Evidence shows: README clearly identifies target audience (developers, AI agents) and multiple use cases (e.g., Reunite, Hive), indicating broad audience and scenarios. Capability boundaries: docs clarify demo is local educational, not connecting to server, and multimodal requires extra install, but not all feature limitations detailed. Trigger precision: API call examples provided, but no trigger conditions or permission controls. Environment fit: supports Python 3.12+, provides install instructions for macOS and Linux, but no Windows support mentioned.
Evidence shows: information architecture: README well-structured with TOC and doc links, but no full API reference. Install notes: pip install and config steps provided, but system dependencies (e.g., LibreOffice) not detailed. Naming stability: API v1 and v2 coexist, but v1 marked legacy and may be removed, posing instability risk. Examples and FAQ: multiple use cases and quickstart examples, but no FAQ. Known limitations: SECURITY.md mentions threat model, but not all limitations listed. License: Apache-2.0 full text present, declared in pyproject.toml. Versioning/changelog: CHANGELOG.md exists, but no detailed version history. Maintenance responsibility: SECURITY.md provides security contact email, but no explicit maintainers or contribution guide.
Evidence shows: output usability: API response examples and Markdown file descriptions provided, but no full output format documentation. Marginal value: project offers unique Markdown-first memory layer, differentiated from other libraries, but no performance benchmarks. Cost-benefit: requires multiple API keys (OpenRouter, DeepInfra), potentially increasing usage cost, but no cost estimates.
Evidence shows: claim traceability: feature claims in README lack specific implementation details or test evidence. Cross-source corroboration: README references multiple external projects, but no independent verification. Fact-inference separation: docs distinguish facts (e.g., feature descriptions) from inferences (e.g., 'self-evolving'), but not explicitly labeled.
- Server defaults to loopback, but if user binds to 0.0.0.0, it may be exposed to untrusted networks; configure carefully.
- Memory stored as plaintext Markdown; sensitive data requires additional encryption.
- lancedb dependency has known issues; monitor version updates.
- API v1 is legacy and may be removed; new code should use v2.
What does this agent do, and when should you use it?
EverOS is a Python library and local-first memory runtime for agents and makers. It stores conversations, files, and agent trajectories as readable Markdown, then synchronizes local SQLite and LanceDB indexes for retrieval. A locally started HTTP server exposes memory write, flush, and search operations under /api/v2; /api/v1 remains a legacy alias for existing integrations. Retrieval can be scoped across user_id, agent_id, app_id, project_id, and session_id, while user episodes/profile and agent cases/skills are separate first-class surfaces. The repository also describes offline reflection that merges episode clusters and refines profiles and skills between sessions, with data and indexes residing locally rather than in a managed memory service.
After everos server start, EverOS serves a local API. A client posts conversations with session_id, app_id, project_id, and messages to POST /api/v2/memory/add; EverOS writes Markdown and synchronizes local SQLite and LanceDB indexes in the background. POST /api/v2/memory/flush forces extraction for a session, and POST /api/v2/memory/search recalls results scoped by user and application/project identifiers. everos demo is a local, hardcoded terminal teaching visualizer that does not contact the server, while everos demo --live performs the /health, /api/v2/memory/add, /api/v2/memory/flush, and /api/v2/memory/search sequence. With everos[multimodal], content items sent to memory/add can include images, PDFs, audio, and office documents; office files are converted to PDF through LibreOffice.
- A team building a coding assistant can save messages from each coding session under project_id and session_id, then search prior context for a user in later sessions.
- A developer building a personal assistant that spans apps or devices can inspect and edit its Markdown memory directly while the cascade watcher synchronizes indexes.
- A multi-agent product can keep user episodes/profile distinct from agent cases/skills when persisting and retrieving long-term context.
- An application that needs durable context from images, PDFs, audio, or office files can install the multimodal extra and provision LibreOffice for office formats.
- A developer evaluating the memory lifecycle before configuring providers can run everos demo locally to see ingest, recall, source reveal, and replay.
What are this agent's strengths and limitations?
- Markdown is the canonical store, so memory is readable, directly editable, diffable, and suitable for Git versioning.
- Its documented local stack is Markdown, SQLite, and LanceDB, with no MongoDB, Elasticsearch, or Redis requirement.
- Retrieval supports orthogonal scoping by user_id, agent_id, app_id, project_id, and session_id instead of a single thread or namespace boundary.
- It provides a Python package, a local HTTP server, and a no-credential CLI demo for separate evaluation and integration paths.
- The real server-backed flow requires credentials for chat, multimodal, embedding, and reranking providers; the documented defaults use OpenRouter and DeepInfra.
- Index synchronization is asynchronous, so a just-written memory can produce an empty initial search result.
- Office-document ingestion depends on system-installed LibreOffice; without it, .doc, .docx, .ppt, .pptx, .xls, and .xlsx uploads return HTTP 415.
- The README identifies /api/v1 as a legacy alias that may be removed in a future major release, creating a migration requirement for older clients.
How do you install or deploy this agent?
EverOS requires Python 3.12+. Install it and run the no-key local demo:
uv pip install everos
everos demoFor the server-backed flow, run everos init and fill EVEROS_LLM__API_KEY, EVEROS_MULTIMODAL__API_KEY, EVEROS_EMBEDDING__API_KEY, and EVEROS_RERANK__API_KEY in the generated .env. The documented default uses OpenRouter for chat and multimodal requests and DeepInfra for embedding and reranking; matching *__BASE_URL values can point to other OpenAI-compatible endpoints. For non-text input, install:
uv pip install 'everos[multimodal]'Office-document ingestion also requires LibreOffice on the host.
How do you use this agent?
After configuring .env, start the service:
everos server startCheck it from another terminal:
curl http://127.0.0.1:8000/healthThe expected response is {"status":"ok"}. For a first live invocation, run:
everos demo --liveUse /api/v2 for new integrations. The normal flow is POST /api/v2/memory/add with messages, POST /api/v2/memory/flush with session_id, app_id, and project_id, then POST /api/v2/memory/search with user_id, app_id, project_id, query, and top_k. Markdown is written synchronously, but the local index catches up in the background, so an initial empty search may need a retry.