A memory graph can look persuasive before it answers a single useful question. Nodes connect, topics cluster, and the interface suggests a rich understanding of the project. The practical test is simpler: when the agent needs a particular fact, how does that fact reach the prompt?
Ladybug Memory adds an independent graph-backed memory layer to Agent Zero. In the reviewed release, the graph stores memories and their topic relationships, while retrieval scores recent memory text using lexical overlap. Understanding that division makes the plugin easier to evaluate and prevents a graph visualization from being mistaken for semantic reasoning. Plugin overview Storage and retrieval
Research basis: We reviewed Ladybug Memory 0.1.0 by Alessandro Frau (
3clyp50) at0984686fed06. We traced schema creation, topic extraction, scoring, recall, storage paths, and uninstall behavior. We exercised its actual topic and scoring functions with synthetic records. No LadybugDB package was installed and no database or model-driven recall session was run.
The short version
- The graph and recall do different jobs. Topic relationships are stored in the graph; recall scores memory text.
- Candidate selection comes first. The default scan is capped at 250 recent records.
- Paraphrases can miss. The tested lexical function does not infer semantic equivalence.
Synthetic query: deploy release. Results from the actual scoring function:
| Memory text | Score |
|---|---|
deploy release receipts |
1.2 |
deploy status |
0.5 |
publish deployment evidence |
0.0 |
What the graph contains
The helper creates Memory nodes containing content, area, timestamp, source, and session identity. It creates Topic nodes and weighted ABOUT relationships between memories and topics. Topics are extracted from text tokens after stopword filtering, with frequency normalized against the most frequent selected token. Schema and topic weighting
A sentence mentioning deployment repeatedly can therefore acquire a strong deployment topic edge. That edge is useful for exploration: it exposes which memories share a term. It is not, by itself, a statement that one memory caused another, superseded it, or describes the same real-world entity.
The distinction becomes visible in the graph projection. The dashboard receives memory nodes, topic nodes, and their edges, bounded by an edge limit. A view showing only part of the graph is an exploration surface rather than an exhaustive inventory. The default graph limit is 220 edges. Graph projection Defaults
The retrieval path does not traverse that graph
search_memories first fetches recent memory records, ordered by timestamp, up to max_scan. It then scores their content against the query. The main score is the fraction of query tokens present in the memory text; an exact substring match adds 0.2. Results below the threshold are removed, and the remaining records are sorted by score and timestamp. Search implementation
With the default configuration, the scan is limited to 250 recent memories, the result limit is five, and the minimum score is 0.18. Older relevant records outside the scan cannot win, however good their content. A paraphrase using different words may score poorly even if a person recognizes the same meaning.
Our synthetic probe makes the mechanism concrete. For the query deploy release, “deploy release receipts” scored 1.2, “deploy status” scored 0.5, and “publish deployment evidence” scored 0.0. Those values came from the actual scoring function. They illustrate token matching and the substring bonus; they are not a benchmark of database speed or answer quality.
That is a useful result to know before increasing the memory population. A graph database backend does not automatically make the recall algorithm embedding-based, graph-traversal-based, or capable of resolving synonyms.
The utility model can prepare a query
Recall runs through a message-loop prompt extension. It can ask the utility model to prepare a search query from recent history and the user instruction. The query is then sent through the same lexical retrieval function. A special skip result can suppress unnecessary recall. Recall extension
Query preparation may help the model choose words that match stored text. It adds another model call and another opportunity for interpretation error. It does not change the scoring algorithm beneath it.
The default recall interval is three iterations, and the extension limits the amount of history it considers. Retrieved text is placed in the persistent extras for the prompt, with score labels. These are engineering bounds on how much memory enters the current reasoning context. They should be tuned against useful recall, rather than maximized automatically. Recall defaults
Parallel memory layers can help—and compete
The plugin is designed to operate alongside _memory, and can continue memorizing and recalling when the built-in memory plugin is disabled. Its data is separate. Enabling both therefore creates two memory pipelines, not two views of one authoritative record. Independence contract
That can be useful when comparing retrieval strategies. It can also duplicate facts, consume more prompt space, and expose conflicting versions of the same decision. If a project changes its deployment procedure, determine which store contains the old version and which recall path injected it. Otherwise, the agent may receive contradictory context while each plugin appears healthy.
For a controlled comparison, use synthetic project facts and one retrieval layer at a time. Check exact-word queries, paraphrases, older records, and project boundaries. If both layers are enabled afterward, inspect the combined prompt contribution and answer quality. This is a recommended evaluation design, not an experiment performed for this article.
Storage and uninstall deserve a close read
Global data lives under usr/plugins/ladybug_memory/data/<subdir>/. Project-isolated data lives under the project's .a0proj/ladybug_memory/ metadata. The default configuration enables project isolation. Path resolution
The location has consequences for lifecycle. The uninstall hook explicitly removes Ladybug workspaces from project metadata and conditionally uninstalls the dependency if it was managed by the plugin. Global data also sits inside the plugin's own tree. Do not assume that disabling, uninstalling, and backing up are equivalent operations, or that uninstall preserves the database. Install and uninstall hooks
Before experimenting with removal, export or back up the relevant memory data and record its scope. This recommendation follows from the actual cleanup implementation; it is not a generic warning unrelated to the plugin.
Where this design is useful
Ladybug Memory offers a visible, relatively simple relationship model. It is a reasonable system to inspect when you want to understand which conversation records cluster around recurring terms, and when its recent-window lexical search fits the workload.
It is a poor basis for claims of unlimited long-term recall, semantic equivalence, or authoritative entity reasoning without further evidence. The synthetic probe established the scorer's behavior on three examples and the topic extractor's normalization. Database durability, model-generated memory quality, and real retrieval effectiveness remain untested here.
The most useful lesson is broader than the backend: evaluate the path from stored record to retrieved evidence. A memory system earns trust when that path is understandable and produces the information the task needs.
Sources
Ladybug Memory 0.1.0, Alessandro Frau /
3clyp50, reviewed at0984686fed06.All motion illustrations are original and derived from the reviewed sources. Illustrative data is labeled.