A database led memory for your AI Agents that works across providers.
Fast, efficient with massive memory capacity.

In your editor

You already do this manually. README.md. CLAUDE.md. Code comments. Notion pages with team gotchas. Commit messages explaining the WHY. All the places you write down the lesson once so the next person does not repeat the mistake. It works, until you have to remember to check it.

What Lore does

Lore is the structured cross-agent memory store every AI session can query. Save a lesson once via the `save` action, what happened, what fixed it, optional category (gotcha · bug · decision · pattern · preference), severity, file or symbol anchors, error-pattern triggers. Every future agent that touches the related code, searches relevant terms, or hits a matching error sees that lesson **automatically attached to its tool response**, before it walks into the same trap. Four search modalities (file anchor, symbol anchor, FTS5 keyword, semantic KNN via sqlite-vec). Drift detection knows when the underlying code has changed since the lesson was saved and flags the entry as potentially stale. Application tracking records how often each lesson is surfaced and how often it actually helped, useful lessons rise; ignored ones can be archived.

How it actually works

AI coding agents have a memory problem: every new session starts from zero. The fix the agent worked out yesterday, the gotcha it eventually noticed at 2am, the architectural reason the obvious refactor was wrong, the prior incident that explains why this code looks weird, none of it survives. The next agent (or the same agent in a new session) walks straight back into the same trap. Lore is Twira’s answer: a structured, agent-agnostic memory layer that every Twira-using AI shares.

Breaking the same-mistake-twice pattern is what Lore actually solves. The failure mode it stops is the "agent makes the same wrong fix three times in a row because it does not remember the last attempt" one. Lore captures the lesson at the moment of discovery; Twira then surfaces that lesson automatically the next time any agent touches the related code, before the wrong fix is attempted again. One session learns, every future session benefits.

Agent-agnostic by design, every MCP-using AI sees the same lore. Lore lives in your project’s local Twira database at .Twira/index.db. Any agent connected to Twira’s MCP server reads from and writes to the same store. Claude Code on Monday, Gemini CLI on Tuesday, Codex CLI on Wednesday, they all share the institutional memory. No agent-specific lore silo, no per-vendor knowledge graph to keep in sync, no proprietary format that locks the lessons to one provider.

SQLite, not markdown, built to be queried in milliseconds. Most teams’ "AI memory" today is a folder of markdown files or a JSON dump that the agent has to scan from scratch every session. Lore is a real structured knowledge store: a lore table with categories, severities, statuses, and a supersedes chain; a lore_anchors table linking lessons to files and symbols; a lore_triggers table for error-pattern auto-surfacing; a lore_applications table tracking when each lesson is used; an FTS5 virtual table (lore_fts) for keyword search; and a sqlite-vec virtual table (lore_embeddings) for semantic similarity. Queries return in milliseconds against thousands of entries. Nothing is ever lost, supersession links new entries to old, statuses move through candidate → verified → stale → superseded → archived without deletion.

Four search modalities, used singly or combined. A query can search by file anchor (every lesson tagged with this file path), symbol anchor (every lesson tagged with this function or class), FTS5 keyword search (full-text across content + resolution, with Porter stemming and Unicode tokenisation, handles natural-language phrases), and semantic KNN (vector similarity via sqlite-vec, finds lessons that mean the same thing in different words). Combine all four in one call, results are deduped by entry, ordered by severity then recency, and returned together.

Auto-surfacing is the killer feature you never call. When the agent runs search, read, impact (refs / deps / blast_radius), or diagnose, Twira silently looks up matching lore by file, symbol, query keyword, and semantic similarity, then attaches the matches to the response. The agent sees the relevant past lesson without ever calling Lore explicitly. The function that does this, surface_lore() in the MCP handler, fires in six dispatch paths across the four most-used canonical MCP tools. Six small hooks, but they cover where the agent spends most of its time. The lesson appears at the moment the agent is about to need it.

Five categories, four severities, five statuses, structure, not free-form notes. Every entry is classified. Category is one of gotcha (default), bug, decision (architectural), pattern (do this / do not do this), or preference (style or convention). Severity is one of critical, high, medium (default), or low. Status moves through candidate (unverified), verified (default), stale, superseded, or archived. The structure is what makes search and ranking sharp, "show me every critical security gotcha touching the auth layer in the last three months" becomes a single query.

Anchors bind lessons to specific code locations. Each lore entry can carry one or more anchors, each tied to a file path, a symbol name, and an anchor_type of file, function, or module. The anchor record also stores an anchor_confidence score and a symbol_hash, the hash powers drift detection. Anchors are how the auto-surfacer knows what is relevant: "this lesson applies when you touch crates/storage/src/index_store.rs, or any caller of IndexStorage::create_in_memory" becomes a machine-checkable rule, not a hopeful comment in a README.

Drift detection knows when the code has changed since the lesson was saved. Anchored symbols are hashed at save-time. When the same symbol is touched again, Twira recomputes the hash and compares. If the symbol has changed, the check action returns a drift warning alongside the entry, "Symbol parseToken has changed since lore was saved; review entry #42 for accuracy." Stops stale lore from misleading future agents, and flags entries for re-verification rather than blindly trusting them.

Triggers are patterns that auto-surface the relevant lesson when a matching error fires. A lore entry can register one or more triggers, pattern_type of text (literal substring), regex (full regular expression), or error_code (exact match on an error identifier). The first time someone debugs "Error E0432 in build cache" and writes the resolution into Lore with that error code as a trigger, every future agent that hits the same error sees the fix immediately, without having to ask.

Three actions cover the full surface, save, search, check, the rest is automatic. save records a new lesson: content plus optional resolution, category, severity, file anchors, symbol anchors, and triggers. Returns the new entry ID and confirms whether an embedding was generated. search finds lore by keyword, file, symbol, category, or severity, in any combination. check takes a file path and returns every lore entry relevant to that file, with any drift warnings, the deterministic pre-edit safety check, no LLM round-trip required. The auto-surfacing inside search, read, impact, and diagnose happens without any explicit call.

Applications tracking measures which lessons actually help. Every time a lore entry is surfaced or applied, Twira writes a row to lore_applications (tool, query, outcome) and updates counters on the entry itself, surface_count (how often it has appeared), success_count (how often it actually helped), dismiss_count (how often it was ignored), last_surfaced_at. Useful lessons rise in rank over time; ignored ones become candidates for archival. The knowledge base self-prunes, institutional memory that nobody acts on is institutional cruft.

Storage and scope, local to your machine, agent-agnostic, never deleted. Lore lives in .Twira/index.db alongside the code index. Local to your machine, not auto-synced to teammates by default. (If you want to share lessons with your team, the simplest path today is to commit the lore export, or align on a shared mount; team-wide auto-sync is on the roadmap, not in the product.) Local also means: fully offline, no telemetry, no third-party sync, your lessons stay on your machine.

What Lore is NOT. It is not auto-extracted from your code, agents have to call save deliberately when they learn something worth keeping. It is not a chat log, each entry is a deliberate, structured lesson. It is not a knowledge base for product documentation, use your docs site for that. And it is not yet cross-machine: each developer’s lore is local to their .Twira/ until you set up a sharing path. Use it for the lessons that genuinely belong as agent-context, not for everything you ever wrote down.

Setup is zero. Lore is enabled on every Pro licence, gated through the lore feature flag in the licence layer. The lore tables are created on first use, alongside the code index. The vector index for semantic search requires an embedding provider (configured in Twira.json under the embeddings block); without one, the other three search modalities, file, symbol, FTS5 keyword, still work fully.

What it isn’t

• ·Not auto-extracted. Lessons have to be deliberately saved when something is worth keeping. Lore is structured agent context, not "every chat log."
• ·Local to your machine by default. Each developer’s lore lives in `<project>/.Twira/index.db`. Team-wide sync is on the roadmap, not in the product today, for shared lessons, commit the lore export or align on a shared mount.
• ·Not a docs site replacement. Use Lore for agent-relevant gotchas and decisions; use your docs site for product documentation.
• ·Drift detection is structural (AST hash). It catches *"the symbol changed"*, it does not catch *"the lesson is still relevant but worded differently."* False stales surface as candidates, not silent removals.
• ·Pro tier. Enabled on every Pro licence. The vector-search modality requires an embedding provider configured; the other three search modes work without one.