Memory System

The memory layer in Agenvoy has three tiers for conversation memory plus a cross-session error memory tier.

Three-tier conversation memory

1. Context window (limits.max_history_messages, default 24)

Each session keeps the most recent N messages in full and feeds them into the LLM context window. Anything older remains in history.json but is not sent to the LLM.

A rolling summary (summary.json) condenses older conversations and is injected into the system prompt at the top of each turn so older context survives beyond the N-message window.

Incremental cursor: .summary_cursor (per-session; the older summary.meta.json is migrated on startup) holds last_message_time (format YYYY-MM-DD HH:MM:SS, extracted from the timestamp in message content). On each summary.Generate invocation:

1. filterAfterTime(histories, cursor) keeps only t > cursor messages
2. Each chunk runs one generatePass LLM call (the system prompt already includes {{.Summary}}=old summary, so merge happens during generation — no separate mergePass, avoiding 2x cost)
3. On success, cursor advances to that chunk's max timestamp + SaveSummary triggers the mtime gate
4. generatePass failure → return (don't bill subsequent chunks; next cron tick retries)

2. Semantic search — ToriiDB (recent conversations)

The chat_history tool with mode=search and match=semantic runs vector similarity search via ToriiDB db.VSearch. Each hit triggers a context window expansion: 2 entries before + 1 entry after.

ToriiDB entries are cleaned during history.json compaction — entries older than the compact cutoff are removed, keeping ToriiDB focused on recent conversations. Older data lives in SQLite (tier 3).

3. Full-text archive — SQLite FTS5 (all history)

Every message written to history.json is dual-written to SQLite (~/.config/agenvoy/.store/history.db) via go-sqlkit. SQLite always holds the complete conversation history, even after history.json is compacted.

The chat_history tool with mode=search and match=keyword runs FTS5 full-text search on the SQLite archive + ToriiDB substring match on recent entries, combining results.

Compaction: when history.json exceeds max_history_bytes (default 5 MiB), the oldest messages are trimmed to 80% on a complete user+assistant pair boundary. The cutoff timestamp is recorded in SQLite message_meta.start_at so that keyword search excludes entries already present in history.json (avoiding duplicates). ToriiDB entries older than the cutoff are also removed.

Backfill: on first encounter (SQLite has no data for a session but history.json has content), the entire existing history is backfilled into SQLite.

Timestamps: stored as UTC unix nanoseconds. Timestamps in message content are parsed via time.ParseInLocation (local timezone) and converted to UTC for storage. Search queries use time.Now().UnixNano() (already UTC).

In-run compaction

Beyond the stored tiers, internal/agents/exec/compact keeps a single long run inside the model's window. Each step is a separate stage, applied in order and only as far as needed:

Manual compaction runs from the TUI (/compact; the /memory command was removed, reset is now /reset) or POST /v1/session/:id/memory. That one endpoint takes an action: compact drops older messages and returns removed, summary rebuilds the rolling summary and returns count, and reset clears the conversation — mode: "summary" keeps the rolling summary, mode: "all" wipes it too.

Search routing

Cross-session error memory

Tool failures and the fix that resolved them persist across sessions in error_memory with 90-day TTL. Only records written with outcome=resolved are stored; failed / abandoned writes are discarded, so abandoned strategies are no longer kept. On hit (either via keyword Contains or db.VSearch), the entry's TTL is refreshed via db.Expire.

When the same tool name fails in a future session, toolCall.go automatically queries error_memory and appends up to 3 related records to the failed tool result as related_errors; the agent applies the recorded fix.

A record's recorded action can be edited from the web dashboard's Lessons view (PATCH /v1/torii/error, which rewrites action and keeps the TTL); GET /v1/torii/error lists records.

Storage layout

Reset / remove behavior

Migration note

Sessions and error memory used to live under per-session JSON files. They now live in the embedded stores under ~/.config/agenvoy/.store/ — ToriiDB (db_0 tool cache, db_1 chat vectors, db_2 error memory, db_3 online markers) and history.db for session config, operator notes, the message archive, action history, file history and usage. Notes moved from ToriiDB into the SQLite note table in v0.35.3, and the state table was dropped in the same release. bot.json / bot.md / config.json / status.json / usage.log / summary.meta.json are migrated in at daemon startup and no longer written. Do not reintroduce JSON paths.

[!NOTE] This document was auto-generated by Claude after reading the full source code.