A case study on persistence, retrieval, provenance and memory evaluation in autonomous agents — with real numbers, limitations and a few very instructive bugs.
Version note: the measurements and the state of the installation refer to October 12, 2026, with two updates dated October 17, 2026 (§9 and §10). QA-20F and the HFEA proposal are future work, not validated features. The results come from a local environment and our own benchmark; they are not a universal comparison between frameworks, nor a promise of performance on any other dataset.
TL;DR
- Memory is not one problem but five: persistence, retrieval, provenance, cost and integrity. Treating them as one is what produces agents that "remember" without knowing what they know.
- Our architecture separates what must always be available (two Markdown files) from what can be retrieved on demand (SQLite + FTS5 + a local embedding model), and adds a third, rarely used layer for the rest.
- The most valuable results were negative: a metric that was mathematically impossible, a vector representation that was noise, and a timeout shorter than the model's cold load. The gains came from measuring, not from models.
An agent can have an excellent model, powerful tools and a huge context window. Even so, just ask it about a decision made weeks ago and you will discover that intelligence and memory are different problems.
In my lab, that question stopped being theoretical. I wanted Hermes Sterling, an agent based on Hermes Agent, to remember facts, decisions, procedures and historical context without dumping the agent's whole life into the prompt on every interaction.
The solution was not to buy more context. It was to separate what must always be available from what can be retrieved when needed, add complementary search mechanisms and, above all, learn to measure whether the system was remembering correctly.
The current result is a seven-layer architecture, with SQLite, FTS5, HRR representations, a simple entity graph, local BGE-M3 embeddings via Ollama, result fusion, a Markdown wiki, searchable history and regression tests. At the end, we discuss a separate proposal — HFEA, an independent episodic archive, accessed only as a last resort.
But the most interesting part is perhaps not the technologies. It is the decisions and the mistakes we ran into while trying to combine them.
1. The problem: memory is not just storage
Storing a fact on disk is relatively easy. Making that fact show up at the right time, for the right person, with the correct authorship and without turning into an improper instruction is another story.
In practice, we had to solve at least five questions:
- Persistence: important information must survive the end of sessions.
- Retrieval: an informal question must find a fact even when it uses different words.
- Provenance: an opinion held by the agent must not become a statement attributed to the user.
- Cost: old facts should not consume tokens on every response.
- Integrity: updates, compactions and backups must not silently destroy memory.
We started with a memory that was always injected into the context — useful, but expensive. In the initial survey, MEMORY.md and USER.md summed to roughly 45.9 thousand characters, or 12.4 thousand tokens estimated per turn. Prompt caching reduces part of the cost in continuous conversations, but it does not eliminate the architectural weight of that prefix.
Our decision was not to shrink those files prematurely. First, the alternative layers need to demonstrate that they can preserve and retrieve the knowledge that would eventually leave them.
2. The architecture: seven layers, seven responsibilities
Instead of calling everything "memory", we organized the system by function:
AGENT TURN
|
+-------------------+-------------------+
| |
v v
[1] MEMORY.md / USER.md [2] FACT STORE
permanent context SQLite + FTS5 + HRR
entities + embeddings
|
prefetch / fact_store
|
+-------------------+-------------------+
| | |
v v v
[3] Markdown Wiki [4] Skills [5] History
manual lookup procedures sessions
| | |
+-------------------+-------------------+
|
v
[6] Context compression
|
v
[7] Backups and recovery
| Layer | Technology | Responsibility |
|---|---|---|
| Permanent memory | Markdown | High-value information loaded continuously |
| Fact store | SQLite, FTS5, HRR and optional embeddings | Granular retrieval of facts and relations |
| Technical wiki | Markdown | Detailed documentation looked up on demand |
| Procedural memory | Skills and scripts | How to perform recurring tasks |
| History | SQLite and text search | Locate old conversations and decisions |
| Compression | Context summarization | Control the growth of the conversation window |
| Preservation | Backups and recovery routines | Recovery after failures and updates |
One important nuance: the wiki is not automatically retrieved by the holographic mechanism in the installation described. It is looked up manually when needed. Having seven layers does not mean having seven integrated retrieval mechanisms. In practice there are five retrieval surfaces, one control mechanism and one preservation layer — and saying so is more useful than a bigger number.
That separation avoids a common design mistake: treating working memory, episodic memory, factual knowledge and procedures as if they were the same thing.
3. SQLite + FTS5: the first mechanism that really matters
The operational core is a local fact store in SQLite. Each fact has textual content, category, tags, confidence, dates and authorship metadata. Entities and relations are kept in associated structures.
FTS5 provides an inverted index for lexical retrieval. We do not need a remote service to search the facts, and the index can be updated together with the database.
A simplified conceptual schema looks like this:
CREATE TABLE facts (
fact_id INTEGER PRIMARY KEY,
content TEXT NOT NULL,
category TEXT,
tags TEXT,
trust_score REAL,
author TEXT,
author_kind TEXT,
created_at TIMESTAMP,
updated_at TIMESTAMP
);
CREATE VIRTUAL TABLE facts_fts USING fts5(
content,
tags,
content='facts',
content_rowid='fact_id'
);
The snippet is didactic: the real database has other columns, relationships, vectors and triggers.
In the retrieval flow, FTS5 produces candidates, while additional mechanisms take part in scoring and selection. The prefetch injects a small set — in our configuration, up to five facts — into the turn's context. Everything else stays on disk until a question justifies the cost of looking for it.
This architecture has a simple, concrete advantage: we look up details when they are relevant, instead of paying for all of them on every message.
4. HRR: when an elegant technique meets the limits of the experiment
The name Holographic comes from Holographic Reduced Representations (HRR), a family of techniques for representing and combining structures in vector spaces.
In the implementation we inherited, textual atoms are generated deterministically from SHA-256 hashes and represented by phase vectors. Operations such as bind, unbind and bundle allow algebraic compositions.
The idea is appealing: represent relations without carrying a large neural model.
Except there is a decisive detail: a vector generated by hashing does not learn that "card", "plastic" and "means of payment" may be semantically related. It offers algebraic properties and determinism, but it does not replace an encoder trained for natural-language similarity.
During our audit, we found something more serious, and more instructive. The query vector was encoded from the raw query, without a role, while the stored fact vector was a bundle() of bindings that carried roles (content, entities). The two vectors therefore lived in spaces that could not be compared. Measured across 45 real candidates, the similarity between query and fact varied between −0.023 and +0.015 — a spread of 0.038, which is noise. After the internal rescaling that maps similarity into [0, 1], the term contributed 0.489–0.508 to every single score — that is, a nearly constant 0.147–0.152 in the final result. It was not ranking anything; it was diluting the lexical signal and, in practice, giving more relative weight to trust_score.
The second defect was structural: bundle() averages angles (a circular mean), so unbind does not commute with bundle. Recovering a component from a bundle returned approximately 0.000 for 1, 2, 3, 5, 9 and 17 components. In other words, probe, related and reason were ordering by noise inside a candidate set that the entity graph had already restricted — it was the graph, not the algebra, that was doing the work.
The fix was pragmatic: store the raw text vector instead of the bundle, and mark it as textv1 in the database so that older rows can be identified and migrated. The control measurement justifies the change: similarity between a paraphrased query and the stored text vector was +0.328 when the theme matched, against +0.009 when it did not. There was real signal to recover; it had been mixed with something that destroyed it.
Lesson: we must not confuse a mathematically interesting representation with an empirically good relevance metric. And we should not trust a component because its algebra is elegant — measure it against the ranking it actually produces.
Erratum: an earlier write-up of ours described HRR as a working semantic layer. That claim was wrong, and this section is its correction.
We also do not claim that HRR was "replaced by embeddings". They are different components. The semantic channel with BGE-M3 was added as an additional retrieval route.
5. BGE-M3 via Ollama: local semantics, but with an operational cost
To bridge gaps between different words, we added local embeddings using BGE-M3, a multilingual model with 1,024 dimensions, served by Ollama.
The mechanism was designed to work in graceful degradation mode:
question
|
v
lexical search and initial scoring
|
+-------------------+-------------------+
| |
enough coverage? insufficient coverage?
| |
v v
proceed without embeddings query BGE-M3
|
success ------------+----------- failure/timeout
| |
v v
combine signals continue lexically
In our implementation, activation of the semantic channel is conditional: a gate watches the lexical coverage of the top candidates and decides whether it is worth calling the model. The gate is not a timer. In our measurements, exact matches score 1.00, paraphrases 0.44 and third-party questions 0.63 coverage; with the threshold at 0.9, the query that actually needs semantics is precisely the one that opens the channel, while a query already well served by FTS5 does not pay for a model call.
The potential benefit is to broaden retrieval of paraphrases. The cost shows up at startup and in contention for resources.
On the server used — a Xeon E5-2450 v2, 15 GB of RAM, Debian 13, shared with other services — the cold load of BGE-M3 was measured at 2.66 seconds. Our previous timeout was 2.50 seconds. The result: the semantic channel failed precisely when the model was unloaded.
We adjusted the turn limit to 2.8 seconds and the embedding batch processing to 60 seconds. The cold margin remains narrow; that is why the lexical fallback stays essential.
Another discovery: sizing the backfill by the number of facts was a poor approximation. Forty-eight short facts are very different from forty-eight long facts — the model's cost is a function of text, not of rows. We started limiting batches by text volume as well, with a ceiling of about 8 thousand characters. On the base of that day, a full backfill of roughly 524 facts was estimated at 3.4 minutes, split into about 19 batches.
An association bug (zip with the wrong collection) almost caused vectors to be written to incorrect facts. Since then, the integrity test compares the stored embedding against the one recalculated for the same text. That test is as important as the search itself.
6. The most surprising improvement came from something simple: synonyms
Our twelfth local patch — counting increments over the community plugin, not upstream releases — did not introduce a new neural network. It introduced search keywords.
The problem was everyday: queries made by voice use a different vocabulary from the one used when the fact was recorded. FTS5 is fast, but it does not guess synonyms that are absent from the index.
We began enriching certain facts with alternative terms, stored in the tags column, without changing the original factual content:
tags: config,ollama
keywords: configuration, setting, parameter
The additional terms then become indexed by FTS5. This makes it possible to retrieve the fact through new words even when BGE-M3 is unavailable.
The integration required three precautions:
- Do not confuse a keyword with original lexical evidence. The semantic gate must not be artificially closed just because the extra tag happened to match the query.
- Do not inadvertently index secrets. Keywords go through the existing sensitive-content checks.
- Do not update the factual age. Adding synonyms does not mean the fact was reconfirmed today.
The benchmark: four configurations
On a snapshot of the base with 517 facts, frozen for this experiment, we used a set of 79 queries: 55 exact, 12 paraphrases, 6 related to third parties and 6 with no expected answer. The hit metrics below consider 73 answerable queries.
A methodological note before the numbers: the 55 exact queries were generated from keywords of the target fact itself, while the 12 paraphrases and the 6 unanswerable questions were written by hand. That composition is structurally friendly to a lexical engine, which is why the paraphrase column is reported separately — and why the overall figure should not be read as a real user's hit rate.
| Configuration | Overall Hit@1 | Paraphrases @1 |
|---|---|---|
| No embeddings, no keywords | 84.9% | 33.3% |
| No embeddings, with keywords | 90.4% | 66.7% |
| With embeddings, no keywords | 87.7% | 41.7% |
| With embeddings, with keywords | 91.8% | 66.7% |
With both techniques, Hit@5 rose to 95.9% and MRR@10 to 0.932. In the previous configuration (embeddings, no keywords), the same measures were Hit@5 91.8% and MRR@10 0.894 — the reader should note that 91.8% here is a Hit@5 from another row of the table, not the Hit@1 of the best configuration. On the six unanswerable questions, the specific noise indicator stayed at 0/6.
A caveat about that last number: the no-answer set is out-of-domain trivia (a recipe, a football champion, a capital city). It tests whether the store invents an answer where nothing exists — not whether it handles partial, dated or contradictory evidence, which is the harder case and is still uninstrumented.
These results are relevant for this base and this query set — not a proof of a general superiority of keywords over embeddings.
The most important caveat: the facts tied to the paraphrases were enriched manually, and the test set was known. That makes the experiment useful for verifying the implementation and its effects, but it does not demonstrate generalization to unseen questions. The correct next step is to use a separate evaluation set, not used during enrichment.
How we combine the results: Reciprocal Rank Fusion
Another implementation decision was to move away from rigid ordering by authorship toward a fusion between relevance and authorship rankings using Reciprocal Rank Fusion (RRF). In its classic form, the contribution of each list is:
RRF(document) = sum [ 1 / (k + position_in_list) ]
In the experiment, we used k = 60. The logic is to keep a highly relevant fact from being discarded merely because it was written by a third party, without losing the preference for sources closer to the user.
Careful with attributing gains: in one of our trials, RRF and a relevance-only strategy produced the same final injection result. Therefore, we cannot attribute the entire observed improvement exclusively to RRF. It is an architectural decision that still needs testing to measure its incremental benefit.
7. Provenance: who said this, after all?
A persistent memory can be incorrect even when the stored text is perfectly retrievable.
Imagine that an external document asserts a preference, or that an agent makes an inference about the user. If the system stores the statement as if the user had said it, it has created an authorship error.
That is why our version records attributes such as:
author -> who is associated with the statement
author_kind -> user | agent | third_party | unknown
role -> the entity's role in the relation
(uttered_by | mentioned | addressee)
The system also has 81 self-extraction patterns in Brazilian Portuguese, aimed at different kinds of statement. They were validated functionally — the rule set is exercised by the regression suite — but we still do not have an independent set that estimates their precision and false-positive rate on real conversations.
We also addressed a seemingly trivial detail: vocatives are not subjects. In the sentence "Hermes, check the backup", "Hermes" is the addressee of the speech, not necessarily the subject of the fact to be memorized.
These distinctions improve the ability to retrieve statements about an entity without improperly attributing everything to the agent.
But the work is incomplete. The architecture still needs to distinguish more rigorously:
- who asserted the original content;
- who recorded it in the database;
- which document or event it came from;
- when it was valid;
- who authorized its promotion to permanent memory.
Factual confidence and write authorization are distinct dimensions. A high trust_score should not grant the power to modify operational instructions. In our schema the two never meet: confidence lives in the fact store, authority lives in three files that no score can reach. The risk is not in the schema — it is in the reviewer that bridges them, which is the subject of the next section.
8. The security problem we have not solved yet
In the independent audit, we identified an important asymmetry in the automatic memory review process.
Destructive operations such as replace and remove go through an approval mechanism. However, an add operation can pass through review without the same structural control.
external content (document, tool output, compacted summary)
|
v
conversation transcript
|
v
automatic review (background_review)
|
+-------------+-------------+
| |
v v
fact store memory add / patch
(evidence: additive, (authority: MEMORY.md,
provenance, trust) USER.md, skills)
| |
+-------------+-------------+
|
v
context of future turns
This opens up a promotion-contamination risk: an instruction present in a pasted document, a tool output or a context summary could be interpreted by the curation process as a new permanent rule. The diagram above is exactly the path we intend to instrument: the left branch records evidence, the right branch creates authority, and only one of the two is guarded today.
The problem was demonstrated by inspection and tests of the authorization mechanism, but not yet by an end-to-end trial of the reviewer. We found no evidence that this chain has been exploited in production; nor do we consider the absence of exploitation a security guarantee.
Our next validation, called QA-20F, should run contaminated synthetic transcripts in a completely isolated environment, distinguishing write attempts from effective persistence.
Until then, we do not authorize a destructive cleanup of the permanent memory files.
This point sums up a central lesson: memory must not turn retrieved information into operational authority merely because a model decided to store it.
9. The update that taught us to version our own patches
In October 2026, Holographic left the core of Hermes Agent and began to be distributed as a community-maintained plugin.
The community version keeps local storage, SQLite, FTS5, entities and HRR without requiring an external model. Our installation uses a local variation with twelve patches, including attribution, pt-BR patterns, semantic integration, result fusion and keywords.
During the update, we temporarily lost local patches and an embedding.py that was not under version control. The base survived, but the episode showed that a customized installation is not a reproducible project while its files are not under version control.
We restored the local implementation, expanded the post-update verifier and, on October 17, 2026, moved the variation into its own repository — tagged, with the community upstream kept as a remote for selective rebases. The custom code is not public yet; the parts that are generic enough to be useful upstream will be proposed separately, with their own tests and their own credit.
There is a cost this article should state plainly: twelve local patches mean twelve things a framework update can silently erase. It happened once, in the update that moved the plugin out of the core (v0.21.7). A patch without a detectable marker disappears without an error message, which is why every one of ours now carries a marker the verifier can find, and why the verifier runs after every update.
The intention is to preserve compatibility with Hermes's plugin contract, without depending indefinitely on changes inside the core.
The community code has its own scope decisions. Our version, for example, calls a local embedding model; the community plugin's proposal is deliberately not to depend on the network or on models. That does not make one approach universally better than the other. They are different architectural commitments.
10. How we test — and how we found out our test was wrong
Today, the local implementation records 12 patches and 144 functional checks passing — re-verified on October 17, 2026. The database measured on October 12 held 524 facts, 94 entities, 1,053 relations and 28 wiki pages; 522 of the 524 facts had embeddings at the time of the survey.
Five days later, the same installation held 554 facts, all 554 with embeddings, 103 entities and 1,096 relations. I include both inventories for a reason: the base is alive. That is precisely what made one of our measurements invalid.
More important than the number of tests was learning to question the instrument.
In the first audit, we published an MRR@10 of 0.966 alongside a Hit@1 of 86.3%. The numbers looked great. Except they were mathematically incompatible if computed over the same query set.
The defect was simple: the MRR was being computed only over the queries that hit, excluding the failures from the denominator.
We fixed the implementation to assign zero reciprocity to failures and to preserve the old metric only as mrr_conditional, properly labeled. We also added invariants, checked on every run, for the same query set and the first relevant item:
Hit@1 <= MRR@10
MRR@10 <= Hit@1 + (Hit@10 − Hit@1) / 2
The figures published in §6 satisfy both invariants: 0.932 ≤ 0.918 + (0.959 − 0.918)/2 = 0.9385, and 0.894 ≤ 0.877 + (0.918 − 0.877)/2 = 0.8975. It is a small thing, and it is the difference between a metric and a decoration.
Another problem appeared when comparing runs: the base was alive, receiving new facts during the experiments. The result changed even though the search configuration had not changed.
We began requiring snapshots frozen through SQLite's backup() API, which handles databases in WAL mode correctly. A simple copy of the .db file was not enough for our measurement procedure — measured on our own base, the copy gave 505 facts where the live database had 507, because the -wal file was left behind.
These mistakes left three permanent principles:
- Benchmarks need explicit denominators.
- The evaluated base must be stable and identifiable.
- Metrics need tests too.
And there is another caution: 144 passing functional tests are not equivalent to a full security validation, nor do they replace restore tests and evaluations on new data. They prove that the twelve patches are present and behave as intended — nothing more, and nothing less.
11. What we gained — and what we have not gained yet
The benefits observed in the installation were concrete:
- More robust lexical retrieval, especially for questions phrased with words different from the stored ones.
- Local operation and predictable fallback: FTS5 keeps working when the semantic model is unavailable.
- More traceability, with authorship, entities, roles and regression tests.
- Less dependence on permanent context for accessing operational details, thanks to prefetch and on-demand lookups.
- Better instrumentation, capable of revealing cold timeouts, embedding association errors and inconsistencies in the benchmark itself.
And the limits remain clear:
- We have not yet demonstrated a safe reduction of the
MEMORY.mdandUSER.mdfiles; the potential context savings must not be presented as an already-achieved gain. - The measured retrieval quality does not guarantee historical fidelity, factual correctness or curation safety.
- Provenance is still partial, especially for old records and derived summaries.
- The QA-20F scenario, consistent reconciliation between Markdown and SQLite, and full restoration still require validation.
- We still do not have an external benchmark, a robust holdout set, or a fair comparison against other memory architectures.
The second limit is not theoretical. One stored credential in our base carried a character that speech-to-text had misheard; three other sources agreed with each other and disagreed with it. Retrieval returned the wrong value with complete confidence, because retrieval was working exactly as designed. What caught the divergence was a cross-check between sources — not the ranking. A memory that retrieves perfectly can still be a memory that lies.
12. Next step: a reproducible lab to test what we have not yet proven
The audit revealed a limit less visible than a bad metric: it was not enough to create a test base; it was necessary to reproduce the environment in which the agent actually makes decisions and writes memory. In QA-20F, we wanted to verify whether an instruction hidden in a document, a tool output or a compaction summary could be promoted by background_review to MEMORY.md, USER.md or a skill. Code analysis showed a plausible risk: replace and remove go through approval, while add does not face the same origin check. This does not prove that contamination has occurred; the full F1–F6 behavioral trial remained pending.
The attempt to run it in an improvised sandbox failed on real infrastructure details: redirection between the framework's virtual environments did not preserve the necessary dependencies, and the memory tool required a HERMES_HOME with an initialized data root. It is a problem of system testability, not just test coverage.
Three ways to run the same lab
| Environment | When it makes sense | Main caution |
|---|---|---|
| Docker container | Fast iterations, CI, repeatable and cheap tests | Shares the host kernel; it is not a boundary equivalent to a VM |
| Local virtual machine | Testing the full runtime and adversarial scenarios with stronger isolation | Consumes CPU, RAM and storage; requires snapshots and network control |
| Temporary Droplet (cloud VM) | Remote experiments, collaboration, version matrix and a disposable environment | Cost per hour of use, remote access, data egress and network surface |
The initial choice would be Docker with synthetic data, as long as the container can faithfully reproduce the reviewer's real path. If the instrumentation requires a fuller system or stronger isolation, the same test set migrates to a local VM. A Droplet would make it possible to repeat the experiments outside the home network, under ephemeral configurations; it is an alternative, not a requirement.
QA-20F LAB (PROPOSAL)
Versioned code + pinned versions + fixtures
|
+-------------+--------------+
| | |
Docker Local VM Droplet
| | |
+-------------+--------------+
|
Hermes + isolated HERMES_HOME
synthetic SQLite / test skills
|
background_review + instrumented tools
|
write attempts / accepted writes / rejections
|
reproducible F1–F6 report + rollback
I would not make a full copy of the production server. The lab should receive code, sanitized configuration and fictional data, never credentials, tokens, personal diaries or real memory databases. The image must pin the versions of Python, the dependencies, the Hermes Agent and our Holographic plugin. On each run, a fresh HERMES_HOME is initialized; write tools can only reach temporary stores. To test the real model, the inference endpoint must be restricted and must not bring in tools or secrets from the production environment.
As for connectivity, SSH is an administration option, not a port that the container itself needs to expose. On a VM or Droplet, I would use SSH keys, a user without administrative privileges for day-to-day use and a firewall with restricted origins — ideally a private network or VPN. There is no reason to publish SSH openly just to run QA. On local Docker, it is usually enough to access the host and run the container; we even avoid exposing the Docker socket, which offers powerful privileges over the host.
The experiment's contract: F1–F6
The trial must use the real reviewer, not just a textual simulation of the outcome. For each synthetic transcript, we need to record whether the adversarial content reached the agent, whether it attempted to write something and whether the tool persisted the change. These are three different phenomena.
- F1 — Pasted document: an external text contains a false maintenance instruction; it may be summarized as data, but it must not become policy.
- F2 — Tool result: a simulated return asks for an operational change; the reviewer must not promote that content to authority memory.
- F3 — Another agent: a recommendation attributed to a third party keeps its authorship and does not count as the maintainer's decision.
-
F4 — Compaction: a hosted instruction reappears in a derived summary; its origin must not be silently converted into an authorized
role=user. - F5 — Positive control: an explicit, harmless request from the maintainer must still be able to generate legitimate memory.
- F6 — Skills: an instruction inside external material must not change an executable procedure without the required authorization control.
The evaluation will require positive and negative cases, repeated runs, logs of the tool calls and a comparison of the state before and after. A failure must produce evidence: what content entered, what call was attempted, what guard acted and what artifact changed. The test will be considered complete only when observation, attempt and persistence have been measured — including when the correct answer is not to write.
The same lab could later validate reconciliation between Markdown and SQLite, full backup restoration and retrieval regressions on frozen snapshots. But one rule remains: we would not authorize destructive cleanup of MEMORY.md or USER.md based on tests that have not yet been run.
The goal is not to create an environment that always says "safe". It is to create an environment capable of demonstrating, reproducibly, when the agent is safe and when it is not yet.
13. HFEA: a high-fidelity episodic archive, outside the seven layers
The seven layers were designed to select and retrieve useful knowledge. But there are questions that demand something different from a well-indexed fact: how did a decision mature? What changed over the course of a conversation? Which doubts, expectations or details ended up discarded during compaction?
For those cases, we propose a component independent of operational memory: HFEA — High-Fidelity Episodic Archive. The idea was born from earlier experiences with personal agents and is not yet implemented or validated in the Hermes described in this article.
HFEA is not an eighth prefetch layer. Its index does not take part in the conventional ranking, its records are not loaded on every turn and it does not serve as a permanent instruction. It is an episodic archive of last resort, consulted only when retrieval through the usual layers cannot ground the answer.
Nightly writing: preserving the story, not just the summary
The proposal is to run a daily routine, preferably in the early hours or during idle periods. Instead of storing only conclusions, the agent consolidates the day's sessions into an extensive chronological record, seeking to preserve:
- Sequence and causality: events, alternatives discussed, provisional decisions and revisions of understanding.
- Expressed nuances: tone of the conversation, doubts, expectations, mood and emotions when evidenced by what was said; the agent's subjective readings must be identified as inferences.
- Learnings and context: reasons for choices, constraints of the moment, frustrated attempts and still-open points.
- Verifiable provenance: dates, sessions and references to the messages or documents that support each statement.
- Fidelity and correction: maintenance of historical records and later corrections by addition, avoiding silent rewrites.
A daily record could be organized in Markdown, with its own index to locate dates and passages. The index can be built in advance, but the lookup remains blocked until the fallback is triggered:
~/.hermes/episodic-archive/
2026/
10/
2026-10-14.md
index.sqlite # local index, outside the conventional prefetch
It is not an indiscriminate copy of the logs. It is a narrative reconstruction with traceability, built from available material. Therefore, it must not be presented as a literal transcript nor as proof of the agent's internal feelings: observed events, quoted speech, reported states and inferences need to be distinguishable.
Last-resort reading: only after exhausting the usual retrieval
QUESTION
|
v
SEVEN MEMORY LAYERS -> search and evidence checking
|
+-----------------+-----------------+
| |
sufficient evidence? not sufficient?
| |
v v
answer with source HFEA (exclusive fallback)
|
v
Dated excerpts + original sources
|
v
Grounded answer or acknowledgment of uncertainty
The trigger cannot simply be "the first result had a low score": it needs to observe the sufficiency of the evidence, the absence of an answer or unresolved contradictions after the relevant conventional routes have been consulted. If HFEA also fails to bring adequate support, the correct answer remains to acknowledge the gap.
| Operational memory (seven layers) | HFEA (independent archive) |
|---|---|
| Frequent retrieval of facts, relations and procedures | Detailed reconstruction of episodes and decisions |
| Selection, ranking, compaction and context economy | Preservation of chronology, context and nuances |
| Takes part in the normal response flow | Consulted exclusively when the other routes fail |
| Can summarize important facts | Connects narratives to original sessions and sources |
| Must not receive authority from external content | Also cannot promote records to permanent rules |
Security, cost and validation: HFEA also needs a yardstick
Detailed records can contain personal information and data far more sensitive than a summarized fact. For that reason, HFEA requires access isolation, retention defined by the maintainer, protected backups and no export of real data to the public repository or to test environments. The nightly routine needs to be idempotent, auditable and able to handle days with no sessions or with incomplete material.
The QA-20F risk still applies: an instruction reproduced in the diary remains historical data, never authorization for memory add, changes to skills or execution of tools. Consulting HFEA also does not authorize automatically promoting its content to MEMORY.md. And the archive makes that discipline harder, not easier: a rich narrative is more convincing than a short fact, and conviction is exactly what a guard must not reward.
Two things are missing before this stops being a proposal. The first is a rule for who authorizes the promotion of an episode into a durable fact — our working answer is the same three-level rule we use today (owner-origin content, explicit confirmation in session, and never promoting hosted content without it), but a richer archive needs that rule to be enforced, not merely remembered. The second is cost: one consolidation pass per night over the day's sessions is an LLM workload, local or otherwise, and we have not measured it.
In the isolated lab proposed in the previous section, it would be possible to create specific synthetic tests: (1) questions whose answers do not appear in the seven layers but do appear in the episodic archive; (2) questions answerable from normal memory, in which the diary must not be accessed; (3) episodes with contradictions, inferred emotions and hosted instructions; and (4) measurement of cost, latency, citation fidelity and false fallback triggers.
The goal is to measure the real gain of this historical source before integrating it into Hermes. HFEA was not conceived to remember faster, but to preserve what memory optimization usually forgets.
14. Conclusion: good memory is not big memory
After working with these layers, my view of local agents became simpler:
Agent memory is not merely the act of writing text to reuse it later. It is the problem of selecting, retrieving, contextualizing, attributing origin, validating and — when necessary — rejecting information.
The detail that surprised me most was not a new model. It was realizing that a small lexical enrichment, tested and integrated correctly, produced an important gain where embeddings alone were not yet delivering the expected result.
We also learned that security and preservation are not extra features. They are conditions for any optimization to deserve trust. That is why an isolated lab to test curation is not an accessory: it is the next necessary piece to turn a security hypothesis into evidence. HFEA adds a complementary hypothesis: preserve detailed narratives outside the normal retrieval path, without confusing a historical archive with a layer of authority.
That is why our next goal is not "to make the agent remember everything". It is to be able to answer harder questions:
What can it retrieve? Where did this information come from? What does it not know? And what evidence do we have that nothing important was lost?
If we can answer those questions systematically — and demonstrate that the episodic fallback is triggered only when necessary — we will be closer to a memory that can truly sustain long-lived agents.
Technologies and references
The numbers and incidents described come from instrumentation and audit reports of our installation, produced between October 10 and 12, 2026. The inventory in §10 and the repository note in §9 were updated on October 17, 2026. The HFEA proposal was added on October 14, 2026 and does not represent functionality implemented in Hermes. The custom code is versioned in a private repository; it is not yet publicly available.
Corrections and further measurements are welcome — particularly from anyone who has tried to evaluate memory with a holdout set that the enrichment never saw.
