Proposal: self-learning loop (skill curation + memory + recall)

[yanmxa]

Motivation

Today gen-code loads skills and remembers sessions, but it does not learn from them. After a long coding session, useful patterns evaporate — the next session starts cold. hermes-agent ships a four-layer self-learning loop that we can adapt. This issue proposes bringing the same closed loop to gen-code.

What each layer solves

L1 — Background Review (per-turn)

Problem it solves: experience from the current session is lost the moment the session ends.
What it does: every N user turns, a forked subagent runs with a whitelisted toolset (skill_manage + memory writes) and decides whether to persist anything — a new skill, an addition to USER.md, an entry in MEMORY.md.
Value: the agent gets better at your codebase the more you use it, without a manual "save this" step. Cheap because it reuses the main runtime's prefix cache.

L2 — Curator (periodic, idle)

Problem it solves: L1 produces a lot of small skills, and over weeks they become duplicated, stale, or wrong.
What it does: on a cron (idle + interval), an auxiliary model reviews agent-created skills and merges / archives / refines them. Uses three cross-validated signals (absorbed_into declaration > YAML summary > tool-call audit) so it can detect when the model hallucinates a merge target.
Value: the skill library stays compact and trustworthy. Critical invariants: never deletes, only archives; never touches the main session's prefix cache (separate endpoint); pinned skills are exempt.

L3 — Session Search (on-demand)

Problem it solves: "I solved this exact bug three weeks ago — where?" The agent has no way to recall its own past work.
What it does: SQLite FTS5 with a dual-index design (unicode61 for Latin, trigram for CJK) plus three modes: DISCOVERY (query), SCROLL (around a message), BROWSE (recent sessions). Routes short CJK queries to LIKE as a fallback.
Value: recall is zero-LLM — pure DB queries — so it's fast, free, and works offline. Gives the agent (and the user) a real long-term memory of past sessions.

L4 — User Modeling (per-turn, async)

Problem it solves: the agent re-learns who you are at the start of every session — your stack, preferences, recurring projects.
What it does: maintains an evolving USER.md written by L1, injected into the user message (not system prompt) so it doesn't bust the prefix cache. Optional: multi-pass dialectic with early bail-out for richer modeling.
Value: the agent walks in knowing you. Tone, defaults, and suggestions match your working style from turn one.

Why these four together

Each layer is independently useful, but the closed loop is the point:

• L1 writes experience → L2 maintains it → L3 recalls it → L4 personalizes how it's applied.
• Every layer runs off the main conversation's hot path (separate runtime, separate endpoint, separate index, or async prefetch) so user-facing latency is unaffected.

Mapping to current gen-code

Layer	Reusable today	Net-new work
L1	internal/subagent hub, internal/skill loader	skill_manage tool with patch semantics (9-tier match + escape-drift rejection); review trigger
L2	internal/cron, multi-provider config	Curator runner, three-signal reconciliation, run reports, pin/archive lifecycle
L3	internal/session/recorder	FTS5 schema + CJK routing, session_search tool
L4	internal/reminder (injection point)	USER.md maintenance via L1; user-message injection (not system)

Proposed phasing

1. Phase 1 — skill_manage tool + patch language (foundation everything else depends on)
2. Phase 2 — L1 Background Review
3. Phase 3 — L2 Curator
4. Phase 4 — L3 Session Search
5. Phase 5 — L4 User Modeling (markdown-based; Honcho integration deferred)

Open questions

1. Separate aux endpoint for the curator, or reuse the main model with a config hook?
2. Storage path: `~/.gen/skills/agent-created/` (isolated) vs mixed with user skills?
3. Pinning UX: `gen skill pin ` to exempt from curator?
4. L1 trigger: every N turns, every K tool iterations, or token-budget based? Coding turns are long, so turn-count alone may under-fire.
5. Should we expose a `gen curator status` / `gen curator run` CLI from day one?

References

• hermes-agent self-learning deep dive: source-level walkthrough of the four layers, including the curator's three-signal reconciliation (R1-R5) and the FTS5 CJK routing decision tree.

[yanmxa]

/PTAL @zhujian7

[zhujian7]

@yanmxa, this is something I'm really looking forward to. The closed-loop design makes a lot of sense — each layer feeding into the next without blocking the main conversation path.

One thought on L1 trigger: I'd lean toward token-budget over turn-count. In coding sessions, a single turn can range from a trivial rename (tens of tokens) to a full feature implementation (thousands of tokens + dozens of tool calls). Turn count doesn't reflect actual work done, so it will either over-fire on light turns or miss the heavy ones entirely. Token-based triggering maps much more naturally to "the agent actually did something worth remembering."

[yanmxa]

Fair point on token-count. After reading hermes-agent's implementation, I'd actually go with a split signal rather than picking one:

• Memory review → every N user turns (drifts on conversation cadence)
• Skill review → when this turn used ≥ K tool iterations (fires when the agent actually did work)

Tool-iter count beats tokens here because it's provider-agnostic (no tokenizer), unaffected by cache-token accounting, and available synchronously inside the loop. ~80% as accurate at a fraction of the cost.

Drafted a fuller plan in notes/active/l1-background-review.md — will open a PR shortly.

[yanmxa]

Tracking L1 implementation in #52, with the design doc in notes/active/l1-background-review.md (to land via PR).