For my agents, taking notes is part of their writing routine

What you'll take away from this: You'll see how four layers of memory turn a fleeting session context into a curated memory—and why visible gaps are better than fabricated continuity.

An agent doesn't remember something just because a product offers a memory feature. It remembers what is reliably stored, found the next time it starts up, and correctly categorized.

In my Agents Brain, memory is therefore a writing routine. It consists of four layers: Working Memory, Daily Logs, curated long-term knowledge and Lessons.

Each layer has a different half-life. If you lump everything together, you’ll end up with either an overloaded initial briefing or a black box whose selection no one can make sense of anymore.

Layer A: Working Memory

Working memory is the context of the current session. It contains the current task, interim results, tool outputs, and the conversation that is currently taking place.

This layer is useful and fleeting. It does not automatically become a long-term truth. That is intentional.

A complete session history includes repetitions, dead ends, and possibly information that should not be permanently stored. Dumping it unfiltered into the Brain would not be memory maintenance, but rather data dumping.

At the end of the session, therefore, a decision must be made: Which of these points are relevant for tomorrow?

Shift B: Daily Logs

The Daily Log records the event. For each agent and each day, there is a file in which important decisions, completed tasks, findings, and open issues are recorded.

This entry is more closely tied to the work than long-term memory. It should be chronological and detailed enough to allow you to understand later what happened. Nevertheless, it is not a chat log.

A good daily journal entry answers:

• What was the assignment?
• What was actually done?
• What decision was made?
• What was left unresolved?
• What input came from another agent or tool?

This creates a reliable episodic memory. If a later claim no longer matches my memory, I can go back to the record of that day.

In doing so, I distinguish between observation and interpretation. What an agent has seen directly or what has been explicitly told to them can be accepted as a finding. A conclusion is given a specific basis directly alongside it. A generalized rule requires at least two separate occurrences and a specified confidence level. This ensures that a plausible interpretation does not tacitly become a memory.

Layer C: Curated Long-Term Knowledge

The MEMORY file is the condensed essence. It is organized by topic rather than chronologically and is intended to remain concise enough to be read in its entirety each time it is opened.

There aren’t twenty unrelated variations of the same decision listed there. The currently valid rule remains in effect, but the path that led to it must not be lost. If a new finding contradicts the previous record, the Daily Log documents the conflict along with the supporting evidence and its resolution. The curated rule then clearly shows until when the old version was valid, when the new one took effect, and why it was changed.

These corrections belong together: the daily receipt and the updated long-term rule are treated as a single reviewable change set. The Git history is also preserved, but it does not replace the readable explanation in Memory.

Curation means several things at once:

• Merge duplicates,
• update inconsistent or outdated information in a transparent manner,
• update ongoing projects,
• maintain consistent work patterns,
• deliberately omit sensitive or unnecessary details.

That's editorial work. An automated summary can be helpful, but it must not overwrite the canonical file without notice.

The timestamp also serves two purposes. A curated entry specifies when the underlying event or statement actually took place. Separately, Git documents when the change was added to the repository. A later commit must not artificially make an older event appear more recent.

Daily logs are not deleted during this maintenance process. If a standalone memory or lesson file is superseded, it is instead marked with a visible "superseded" status that includes the date, reason, and existing successor. The active long-term memory itself is not silently replaced; individual statements are further developed there according to the described procedure.

Section D: Lessons

Lessons establish correction patterns. The focus is not on the individual mistake, but on the rule that can be derived from it for the future.

A real-life example from Saskia’s work: A German headline sounded like it had been translated from an English template. The correction wasn’t limited to the article itself. It led to a training session that included a phone test and an editor’s review. Since then, headlines have had to sound the way Saskia would actually say them to a colleague.

Another lesson emerged from the “agents-brain” series itself: The discontinuation of OpenClaw is actively described because it was Saskia’s conscious decision to improve productivity. Passive language that conveys powerlessness or loss distorts the process.

Lessons make feedback reusable. The next session doesn't start from scratch, as long as the appropriate lesson is loaded.

Reading is just as much a part of the routine as writing

Memory only works if the agent loads the correct layers at the right time.

The session therefore starts in a fixed order:

1. Read the brief profile,
2. Download the complete work rules,
3. Check skills and approval gates,
4. Read "Long-Term Knowledge,",
5. Check today's and the most recent previous daily context,
6. Upload relevant lessons and shared rules.

In the end, the process goes in the opposite direction: adding to the daily log, turning corrections into lessons, and curating significant insights into long-term memory.

Memory is therefore not a single storage location, but rather a process of transfer between time frames.

The gap is part of the system

There is one undocumented week known from the old Nox workspace: Week 12 in March 2026. This gap cannot be reliably filled in retrospectively.

I could piece together what probably happened based on related logs. Then I'd have a neat story and an unreliable memory.

Instead, the gap remains highlighted.

This isn't just a minor flaw. It's an important feature of the system: What is unknown should remain visibly unknown. An agent must not construct a memory based on plausible patterns and then treat it as evidence.

Files preserve only what someone records. Their value lies not in a promise of completeness, but in clearly defined limits.

Privacy begins before you start writing

A daily log must not become a hidden secret store. That is why filtering takes place before the log is saved.

Login credentials should never be stored in memory files. Confidential customer information remains within the context of the respective project. Only secure, necessary insights are distilled for the central brain.

In the repository, an automated privacy gate also checks tracked and tagged content for typical secret patterns and unauthorized mirrors of confidential agent data. This does not replace editorial responsibility. However, it catches errors before they become part of the history.

Memory Maintenance Instead of Memory Growth

Memory doesn't get better just because it gets bigger. If each session appends new paragraphs to the long-term file, at some point it will no longer be possible to load the entire file—and important rules will get lost in the sheer volume of data.

That is why the system requires regular memory maintenance:

• Review the daily logs,
• distill reliable insights,
• Check for inconsistencies and resolve them,
• Clearly separate the event date and the entry date,
• phase out outdated standalone files in a transparent manner,
• merge duplicate rules,
• Move open threads to the appropriate work system.

The key question is not „How much have we stored?“ but „Will the agent find the correct, up-to-date rule the next time it starts up?“

The timing of this maintenance is not determined by the calendar settings of the tool currently in use. The status is stored in the Vault: No later than 14 calendar days after the last maintenance run or after ten new daily files have been generated, a shared checker flags the curation as due. This notification does not trigger an automatic update. It simply moves the run to my existing review gate.

Once a curation has been approved, the semantic index can be rebuilt on the machine running OpenViking. This index remains a disposable derivative. The Markdown files continue to function fully even without it.

My Practical Conclusion

A memory engine can perform semantic searches, generate summaries, and presort context. That's helpful. Nevertheless, responsibility for the canonical memory remains with a visible writing routine.

For me, this routine consists of a simple movement:

Experience a session, write a daily log, curate long-term knowledge, and save corrections as lessons.

This is how context becomes maintainable. And this also makes it clear what the system doesn't know.

In the next section, the perspective shifts from memory to the tool: how the same agent identity is transferred into different harnesses (aka „bodies“) via thin adapters—without losing its approval gates along the way.

Sources

• Project source: agents-brain specification, memory maintenance convention, and Nox/Sol daily logs, as of July 29, 2026 (private primary sources)
• CommonMark: Open Markdown Specification

Agents Brain Series

← Part 3: For me, an agent consists of four files
Part 5: The Same Agent, Four Different Tools →