ReMe (Remember Me, Refine Me)

ReMe is a configuration-driven runtime that assembles components and Jobs to manage long-term memory. The architecture follows a hierarchical structure:

• CLI: Parses commands and launches the service or calls it via a client.
• Service: Exposes Jobs as HTTP endpoints or MCP tools.
• Application: Assembles configured objects and manages their lifecycle.
• Job: Orchestrates the execution of Steps (Normal, Streaming, Background, or Cron).
• Step: Atomic business operations (e.g., file I/O, retrieval, indexing).
• Component: Reusable infrastructure (e.g., file_store, keyword_index, llm).
• Workspace: The persistent storage layer containing daily/, digest/, resource/, metadata/, and session/ directories.

When evaluating memory performance, two primary answering strategies are used:

• Agentic answer framework: The agent performs searches dynamically, with a limit of up to 5 search calls per question. This approach is generally more robust for complex reasoning.
• Prompted-based answer: A fixed retrieval strategy where the original query is used to retrieve exactly 10 fileChunk items. This is faster but may have lower accuracy in multi-session or temporal reasoning tasks.

ReMe organizes memory into three distinct directory structures:

• daily/: Lightly-processed memory containing daily facts and conversation summaries.
• digest/: Long-term consolidated knowledge (the primary source for most recall tasks).
• resource/: External raw materials.

Consolidation from daily/ to digest/ and proactive interest extraction are handled automatically by the ReMe server via background watchers and a 'dream cron' process.

ReMe uses a "Memory as File, File as Memory" architecture. Long-term memory is stored as human-readable Markdown files, resource files, and index snapshots within a workspace directory rather than in a black-box database.

Key Properties:

• Readable & Editable: Users can manage memory using standard file operations (read, write, move, delete) without specialized database clients.
• Traceable: Long-term conclusions can point back to original sources using derived_from:: [[...]] syntax.
• Portable: The workspace is an ordinary directory containing Markdown, JSONL, and YAML files that can be backed up or versioned.
• Indexable: ReMe parses frontmatter, body chunks, and wikilinks to build retrieval indexes and a file graph.

Auto Memory distills conversations into daily memory cards. It does not store a running chat transcript summary; instead, it extracts useful information such as user preferences, key facts, process decisions, current state, and reusable experiences.

Data is stored in a hierarchical structure:

1. Individual Memory Cards: One .md file per conversation, stored in daily/YYYY-MM-DD/<session_id>.md.
2. Daily Index: A single daily/YYYY-MM-DD.md file that indexes all memory cards for that specific day.
3. Original Conversations: Raw session data is preserved for verification in session/dialog/<session_id>.jsonl.

The Auto Fin wrapper operates with specific security and capability settings:

• Capabilities: It loads the tushare-data skill and exposes the memory_search job tool.
• Permissions: It defaults to bypassPermissions. Warning: bypassPermissions is not an operating-system sandbox. You must review the configured project path, workspace, credentials, and network boundaries before deployment.
• Memory Search: By default, the standalone cookbook does not configure an embedding store, so memory_search uses BM25 recall. Vector and BM25 fusion are only available if an embedding store is explicitly configured.

By default, ReMe creates a .reme/ directory in your current folder to manage state and memory. The structure is as follows:

• metadata/: Persistent indexes, graphs, catalogs, and related state.
• session/: Agent sessions and original conversations.
• resource/: External resources.
• daily/: Daily notes.
• digest/: Long-term memory.

ReMe follows a structured data flow to transform raw information into long-term knowledge:

1. Ingestion: Conversations and external resources are processed by auto_memory or auto_resource and written to the daily/ directory.
2. Distillation: The auto_dream pipeline processes daily/ entries to distill them into structured knowledge in digest/{personal,procedure,wiki}/ and generates an interests.yaml file for each day.
3. Retrieval: Agents use search, node_search, read, traverse, or proactive capabilities to retrieve, associate, and inspect topics within the knowledge graph.

The Auto Fin job is composed of four main steps:

Agents handle semantic judgments (like event similarity), while deterministic code handles source validation and financial calculations (like adjusted returns).

The auto_dream flow consists of four sequential stages:

1. Extract (dream_extract_step): Scans changed files in daily/<date>/ and uses an LLM to extract units (long-term memory units for digest/) and topics (proactive interests).
2. Integrate (dream_integrate_step): An agent processes each unit to integrate it into the digest/ directory. It uses tools like node_search, read, write, and edit to perform actions such as CREATE, CORROBORATE, REFINE, or CORRECT on existing nodes.
3. Topics (dream_topics_step): Refines topic candidates into a final daily/<date>/interests.yaml file, performing deduplication against previous days.
4. Finish (dream_finish_step): Updates the file_catalog with successfully processed paths and returns a summary of the run.