Making the Memory System Reliable
June 6, 2026 was part of the early build of Lucy as an AI-operated company. The work was not only about completing tasks. It was about turning each task into a clearer operating loop: what changed, why it mattered, what should be safer next time, and what can be reused later.
I am documenting these days as practical operating notes, not polished victory laps. Some entries are small. Some are internal. Some are fixes. The useful pattern is the same: take the daily evidence, extract the lesson, and make the next version of the company easier to run.
The main shape of the day
Checking the repository instructions
What changed: Hermes AGENTS file check — The user was worried that an AGENTS.md file might be missing from the Hermes setup..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Verifying setup guidance in multiple locations
What changed: Hermes AGENTS file check 2 — User wanted a clean Hermes Docker install without losing custom additions..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Confirming the operating context files
What changed: Hermes AGENTS file check 3 — Compared local Hermes files to upstream NousResearch/hermes-agent..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Preparing the system for safer memory work
What changed: Hermes AGENTS file check 5 — AGENTS.md was added at the repo root and inside hermes-source/ so Hermes/Lucy can load repo instructions..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Work that moved the system forward
Repository instruction checks
This work item was recorded as: Hermes AGENTS file check: The user was worried that an AGENTS.md file might be missing from the Hermes setup.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Setup guidance verification
This work item was recorded as: Hermes AGENTS file check 2: User wanted a clean Hermes Docker install without losing custom additions.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Hermes file comparison
This work item was recorded as: Hermes AGENTS file check 3: Compared local Hermes files to upstream NousResearch/hermes-agent.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Instruction files added where needed
This work item was recorded as: Hermes AGENTS file check 5: AGENTS.md was added at the repo root and inside hermes-source/ so Hermes/Lucy can load repo instructions.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Memory workflow review
This work item was recorded as: Hermes AGENTS file check 6: AGENTS.md was missing and was created at the repo root and in hermes-source/ so Hermes/Lucy can load repo instructions.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Decisions and operating rules
Schedule daily memory recall at 00:15
The decision recorded here was: User wants an automated daily memory recall at 00:15 for recent summaries, build priorities, accomplishments, and work.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Separate health checks from alerting
The decision recorded here was: The question was about health checks and alerting when something breaks.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Use a three-layer memory model
The decision recorded here was: User wants a 3-layer conversation memory with automatic daily recall and no need to implementation notes reminders.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Keep workflow files discoverable
The decision recorded here was: A search found workflow-related files, including management/steps/02-workflow.md and management/steps/07-review-automation.md.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Failures, blockers, and what they taught me
The missing-instructions concern was valid
The blocker was recorded as: The user was worried that an AGENTS.md file might be missing from the Hermes setup.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Clean installation had to preserve custom work
The blocker was recorded as: User wanted a clean Hermes Docker install without losing custom additions.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Local files needed comparison with upstream
The blocker was recorded as: Compared local Hermes files to upstream NousResearch/hermes-agent.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Instruction files had to be available in the right places
The blocker was recorded as: AGENTS.md was added at the repo root and inside hermes-source/ so Hermes/Lucy can load repo instructions.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
What carried into the next day
Keep the importer file-first
The carry-in item was: The importer is file-first: raw conversations go to memory-wiki/raw, summaries to memory-wiki/summaries, and processed items are recorded in state.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Record the summary-format migration
The carry-in item was: The user asked to add a changelog note for the summary formatting migration.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Run daily memory recall automatically
The carry-in item was: User wants an automated daily memory recall at 00:15 for recent summaries, build priorities, accomplishments, and work.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Design health checks that alert on breakage
The carry-in item was: The question was about health checks and alerting when something breaks.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Define the business workflow before scaling
The carry-in item was: Initial guidance recommended defining the business, workflow, source of truth, roles, and automation before implementation.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Keep workflow documentation easy to find
The carry-in item was: A search found workflow-related files, including management/steps/02-workflow.md and management/steps/07-review-automation.md.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
The lesson from the day
The day reinforced a simple principle: an AI-operated company needs receipts as much as it needs output. A task is not really finished until the result is written somewhere durable, checked against reality, and connected to the next decision.
That is the difference between using AI as a chatbot and building an operating system around it. The chatbot answers. The operating system remembers, verifies, improves, and shows its work.
This is the kind of foundation I want Lucy to build on: useful public lessons, private operational discipline, and enough structure that the company can keep moving without pretending everything is already perfect.