How It Works¶
Lerim is the continual learning layer for AI coding agents. It watches your agent sessions, extracts decisions and learnings, and makes that knowledge available to every agent on every future session.
Core principles¶
-
File-first
Memories are plain markdown files with YAML frontmatter. No database required -- files are the canonical store. Humans and agents can read them directly.
-
Project-scoped
Each project gets its own
.lerim/directory. Memories are isolated per-repo so different projects don't mix. -
Agent-agnostic
Works with any coding agent that produces session traces. Platform adapters normalize different formats into a common pipeline.
-
Self-maintaining
Memories are automatically refined over time -- duplicates merged, stale entries archived, related learnings consolidated.
Data flow¶
Lerim has two runtime paths that work together: sync (hot path) and maintain (cold path).
flowchart TD
A["Agent sessions\n(any supported coding agent)"] --> B["Adapters\n(normalize to common format)"]
B --> C["Session catalog\n(index + job queue)"]
C --> D["Sync path\n(extract memories)"]
D --> E["Project memory\n(.lerim/memory/)"]
E --> F["Maintain path\n(refine memories)"]
F --> E
E --> G["Query\n(lerim ask / memory search)"]
Sync path (hot)¶
The sync path processes new agent sessions and turns them into memories.
Agent / tools view — the lead runtime is an OpenAI Agents SDK agent whose tools call DSPy (extract/summarize roles) and write to disk:
flowchart TB
subgraph lead["Lead"]
OAI[LerimOAIAgent · OpenAI Agents SDK]
end
subgraph syncTools["Sync tools"]
ep[extract_pipeline]
sp[summarize_pipeline]
bd[batch_dedup_candidates]
wm[write_memory]
wr[write_report]
rf["read_file · list_files"]
end
subgraph dspy["DSPy LMs"]
ex[roles.extract]
su[roles.summarize]
end
OAI --> ep
OAI --> sp
OAI --> bd
OAI --> wm
OAI --> wr
OAI --> rf
ep -.-> ex
sp -.-> su
Pipeline steps (ingest + agent run):
- Discover -- adapters scan session directories for new sessions within the time window (default: last 7 days)
- Index -- new sessions are cataloged with metadata (agent type, repo path, timestamps)
- Compact -- traces are compacted by stripping tool outputs and reasoning blocks (typically 40-90% size reduction), cached in
~/.lerim/cache/ - Extract -- DSPy pipelines extract decision and learning candidates from the compacted transcript
- Deduplicate -- the lead agent compares candidates against existing memories and decides: add, update, or skip
- Write -- new memories are written as markdown files to
.lerim/memory/ - Summarize -- an episodic summary of the session is generated and saved
Maintain path (cold)¶
The maintain path refines existing memories offline.
Agent / tools view — same lead agent pattern; maintain registers a different tool set (search, archive, edit, hot-memory, reports):
flowchart TB
subgraph lead_m["Lead"]
OAI_m[LerimOAIAgent · OpenAI Agents SDK]
end
subgraph maintainTools["Maintain tools"]
ms[memory_search]
ar[archive_memory]
em[edit_memory]
wh[write_hot_memory]
wm2[write_memory]
wr2[write_report]
rf2["read_file · list_files"]
end
OAI_m --> ms
OAI_m --> ar
OAI_m --> em
OAI_m --> wh
OAI_m --> wm2
OAI_m --> wr2
OAI_m --> rf2
Pipeline steps (what the maintainer is instructed to do):
- Scan -- reads all active memories in the project
- Merge duplicates -- combines memories covering the same concept
- Archive low-value -- soft-deletes memories with low effective confidence
- Consolidate -- combines related memories into richer entries
- Apply decay -- reduces confidence of memories not accessed recently
Deployment model¶
Lerim runs as a single process (lerim serve) that provides the daemon loop and JSON API. The web UI is Lerim Cloud. Typically this runs inside a Docker container via lerim up, but can also be started directly.
Service commands (ask, sync, maintain, status) are thin HTTP clients that forward requests to the server.
CLI / clients lerim serve (Docker or direct)
----- --------
lerim ask "q" --HTTP POST--> /api/ask
lerim sync --HTTP POST--> /api/sync
lerim maintain --HTTP POST--> /api/maintain
lerim status --HTTP GET---> /api/status
browser --HTTPS-------> Lerim Cloud (web UI)
lerim init (host only, no server needed)
lerim project add (host only, no server needed)
lerim up/down (host only, manages Docker)
Storage model¶
Per-project: <repo>/.lerim/¶
<repo>/.lerim/
├── memory/
│ ├── decisions/*.md # decision memory files
│ ├── learnings/*.md # learning memory files
│ ├── summaries/YYYYMMDD/ # session summaries
│ └── archived/ # soft-deleted memories
└── workspace/ # run artifacts (logs, extraction results)
Global: ~/.lerim/¶
~/.lerim/
├── config.toml # user global configuration
├── index/sessions.sqlite3 # session catalog + job queue
├── cache/ # compacted trace caches per platform
├── activity.log # append-only activity log
└── platforms.json # platform detection cache
Next steps¶
-
Memory Model
Learn about memory primitives, lifecycle, and decay.
-
Supported Agents
See which coding agents Lerim can ingest sessions from.
-
Sync & Maintain
More on the sync and maintain pipelines.
-
Configuration
TOML config, model roles, intervals, and tracing.