My reading of the EverRoom README is that one of its key design decisions concerns what the workspace declines to remember. The project describes itself as a local-first personal context workspace for files, conversations, memory, and AI agents, yet much of its documentation explains what a source goes through before it earns a place in long-term knowledge. The README states the thesis directly: context "should be assembled from evidence, scoped to a place of work, and made visible enough for a person to govern."
Status comes first. The README marks Everroom as under active development, names macOS as the current development target, and warns that APIs, storage schemas, and agent contracts may change while the first complete local workflow is being finished. Read everything below as a description of a direction and a partially built system, not a finished product.
Memory as a routing outcome
The README positions the project against a specific pattern. It says Everroom is not intended to be "another chat client, a thin RAG screen, or a notebook that quietly accumulates unreviewed summaries." My reading is that the section on how a Room works is where that position becomes concrete. Sources are linked to a Room and kept with stable identity and version history. Routing and evidence checks then decide whether a piece of material becomes a Room wiki page, an entity candidate, a memory document, or only a link.
That final option carries the idea. A source can sit in a Room, attached and traceable, without being turned into permanent memory. The README describes the goal as a workspace that "can become more useful over time without turning every source into permanent memory."
The product model table draws the same lines. Evidence is versioned, addressable source material with positions and provenance, and the README says it protects "the difference between a source and a model's interpretation." Knowledge covers wiki pages, entities, links, and route decisions built from that evidence. Memory is conversation capture plus layered MemoryCore derivations labeled L0-L3, listed as having a visible lifecycle.
The Room draws the boundary
A Context Room is the working surface for a project, person, topic, or ongoing responsibility, and the README contrasts it with "a global prompt dump." When an Agent handles a request, it receives only the Room-scoped tools and documents needed for that request. Knowledge tools resolve the current Room or session before reading wiki pages, sources, or materials. According to the README, agents do not receive a global unbounded corpus by default.
The loop is meant to close on itself. Document changes are committed through the document kernel, recorded as operations, and sent back through the same ingest path. The README calls the loop "deliberately reversible": a generated summary is useful only when a person can inspect where it came from, correct it, and let the correction flow back into the next task.
Engineering notes along the same line
Several implementation notes in the README read to me as the governance idea applied at the storage and process level.
The ingest layer identifies and normalizes a source once, then fans it out to Knowledge, Memory, or Room links according to a recorded policy snapshot. Original files and parsed Markdown have one storage owner, and downstream systems keep stable references, hashes, and provenance instead of copying the source into several databases.
Document edits go through a transactional commit core and outbox. Knowledge and Memory fan-out happens after the authoritative document version is committed, and the README says this means an external service failure cannot corrupt the document.
Connector calls are prepared against real Action Schemas and real connections before execution. Tokens remain in trusted processes, and destructive or externally visible actions are designed to require approval.
The README also lists explicit fallback states for the fake Agent runtime, disabled MemoryCore, unavailable connectors, and model failures, with the stated aim that a missing optional service should not make local documents inaccessible.
The desktop uses Electron 39 and React, with local storage on SQLite WAL, Drizzle ORM, FTS5, and content-addressed objects.
What the main branch holds now
The README says the main branch contains the first integrated product loop, and its status table separates "Available" from "Available, evolving." The desktop workspace, the local gateway, and agent sessions are marked available. Evidence and ingest, Knowledge Rooms, Context Docs, Reality Perception (user-triggered microphone and system-audio capture with transcription), agent work management, and files and understanding carry the evolving label. Memory is available when enabled. Connectors sit at "Foundation available," with provider coverage still expanding.
Some features require optional local services or model credentials, though the README says the desktop can still start with the isolated development runtime. The prerequisites list macOS, Node.js 22 or newer, and pnpm 11.15.1.
The README also names what the first release does not begin with: continuous screen recording, an autonomous multi-agent swarm, enterprise administration, or mandatory cloud synchronization. The open question for me is how the "only a link" route behaves once a Room fills with a real project's worth of material, and the project's own status note says the complete workflow around it is still being finished.
GitHub: https://github.com/NxcoreAI/EverRoom
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)