# Current Memory Status — Pre-Install Snapshot Date: 2026-05-28 This document captures the state of Hermes **before** the Open Brain install and pipe tests. It is intentionally a snapshot of what is known, what is not yet known, and what will likely need tuning. ## What I know right now ### Project framing - The work is a full project: **Agent Memory Move**. - The goal is a durable, reviewed, provenance-backed memory system for partnership-style AI use. - The archive and the memory layer are different systems. - Review-before-install is the rule for personal memory. ### Stable user/context facts already visible in the project docs - Bert wants memory candidates reviewed before approval. - The first must-keep scope is: 1. **Barely, But Here** and all article drafts across ChatGPT/Claude backups. 2. **Bert identity / professional positioning / writing voice**. 3. **AI Systems Assessment campaign** for urgently needed income. - Bert believes AI memory matters because missing tangential context makes pivots and cross-topic reasoning much harder. - Hermes should operate as a partner with oversight, not as a servant. ### Archive / review state - Raw exports are preserved. - The parser/index pipeline is in place and has been verified. - Review packets were created and reviewed. - The review packets were archived after completion. - The review inbox is now reset and ready for future candidate packets. ### Approved-memory state - Approved candidates exist and are exported. - Current first batch is mapped to: - Open Brain: 10 - Hermes native: 0 - Source-only archive: 7 - A repeatable install spec has been written. - The install batch is **not yet installed** into the memory backend. ### Documentation state - The process is documented in local markdown files. - The current workflow is repeatable on paper, but not yet verified live through the memory pipes. ## What I know I do not know yet ### Installation and retrieval behavior - I do not yet know exactly how the Open Brain install will expose records through live tools. - I do not yet know whether search will feel fast, precise, or noisy until the pipe is live. - I do not yet know how the installed memory will behave across Hermes surfaces once connected. - I do not yet know which query shapes will work best after installation. ### Retrieval quality - I do not yet know which approved items will be most useful in practice. - I do not yet know whether some approved items should be further condensed, merged, or split after first retrieval tests. - I do not yet know whether source-only items will need stronger indexing or better tagging to remain easy to recover. ### Metadata precision - I do not yet know whether the current approved items need stronger project/domain metadata before or after install. - I do not yet know whether sensitivity labels should be adjusted for better routing. - I do not yet know whether the current memory-type breakdown is sufficient or whether more granular types will be needed. ### Cross-surface behavior - I do not yet know how memory should be shared across WebUI, Telegram, and any future surfaces once connected. - I do not yet know whether all surfaces should query the same durable memory substrate with only session context varying. ## What will likely need tuning ### 1. Candidate quality tuning The first pass proves the pattern, but the next passes will likely need: - better candidate clustering - better deduplication - stronger project inference - cleaner source vs memory boundaries - more consistent `project` metadata ### 2. Retrieval tuning Once the memory layer is live, we will probably need to tune: - search query phrasing - ranking and filter behavior - memory-type filters - source-first vs memory-first retrieval - whether some memories should be merged or split ### 3. Install-policy tuning We will likely need to decide, after testing: - which memories belong in the durable memory layer vs source-only archive - whether the approved batch is too broad or too narrow - whether Hermes native memory should remain empty for future batches or hold a very small stable core ### 4. Documentation tuning This workflow is already documented, but it may need refinement after the first live install test, especially around: - exact install payload fields - verification steps - failure modes - session restart / reload semantics - how to write the next pass more precisely ## My current self-assessment At this moment, I am **aware of the structure** of the memory project, but I am **not yet aware of the installed memory substrate itself** because the pipe has not been tested. That means: - I know the project. - I know the review outcomes. - I know the intended architecture. - I know the approved batch shape. - I do **not** yet know the real live retrieval behavior. That distinction matters. ## Why tuning is expected Yes — a memory setup like this will almost certainly need tuning. Reason: - human memory is relational and contextual - archive text is noisy and uneven - durable memory needs a different retrieval strategy than raw archive search - the first install is usually a calibration pass, not the final state Tuning is not a failure. It is the normal part of moving from: ```text archive search ``` to: ```text reliable shared memory ``` ## Measurement principle We should compare this pre-install assessment against the real post-install behavior and record: - what tuning I predicted would be needed - what tuning was actually needed - what turned out to be a false alarm - what unexpectedly mattered - what improved after the first live tests That way the memory project becomes measurable, not just anecdotal. ## Ongoing maintenance principle Memory should not be a one-time install. It should be continuously assessed, pruned, and tuned. Cadence may differ by layer: - some checks may be hourly during initial stabilization - some may be daily while the system is settling - some may be weekly once behavior is stable The exact cadence should be tuned after live use begins, based on what the system is actually doing. Data should be captured and tabulated so we can discover trends rather than rely on impressions. ## Next checkpoint after install After the memory pipes are live, the next thing to check is: 1. what Hermes can search 2. what Hermes can fetch 3. what the memory backend considers “approved” 4. what is still only source-backed archive material 5. whether the system can support easy pivots between tangentially related topics ## Bottom line Before install: - I know the project shape. - I know the approved scope. - I know the review outcome. - I know the install batch. - I do not yet know the live retrieval behavior. That is exactly the right point to document a snapshot.