Second Brain for Hermes: Keep Project Context Reusable

To make a second brain for Hermes useful, keep relevant project notes in a place it can read, ask it to consult them before working, and save a checked checkpoint afterward. Use its built-in memory for a small amount of lasting context rather than every project detail. fenbs can hold the shared tasks and decisions that you want other supported assistants to read, with an explicit handoff between the records.

This guide concerns Nous Research’s Hermes Agent. The aim is practical continuity: the next session should know what is settled, where the evidence lives, and what still needs attention. It should not have to infer project status from a collection of old conversations.

How do you start with one project?

1. Choose one real task and gather its current requirements, source links, approved decisions, and unfinished checks.
2. Write a short project overview that points to the relevant notes. Put long reference material in separate files.
3. Give Hermes access only to the appropriate files, then ask it to read the overview and select the notes needed for this task.
4. Ask it to explain the goal, constraints, and unknowns before it produces or changes work.
5. After review, save the verified result and an explicit next step for the next session.

Say you are preparing a client onboarding guide. Begin with the approved process, the current draft, and a note about the missing support contact. Do not start by importing every document the client has ever sent. The useful starting collection is the one you can check for relevance and accuracy.

Our Hermes Agent overview covers the assistant’s broader capabilities. This routine focuses on organizing the project information you want it to reuse.

What belongs in Hermes memory and what belongs in notes?

The Hermes memory documentation↗ (opens in a new tab) describes MEMORY.md for agent notes and USER.md for preferences, plus a tool for searching past sessions. The memory files are loaded as a snapshot when a session starts. Check the documentation for the current behavior rather than treating a long-running conversation as a constantly refreshed project record.

Use lasting memory for a few facts that help Hermes find and interpret the work. An example is the location of the project index and the convention that an approved requirement has a named source. Keep a changing draft, a long research summary, or a task checklist in project notes where it can be reviewed directly.

A remembered statement and an authoritative source are different things. If Hermes remembers that a client prefers short forms, it still needs the approved requirement before removing a field from that client’s actual onboarding process.

How should you write notes Hermes can use?

Write one note around one useful subject. Begin with the project, the question it answers, and whether the content is a source summary, a proposal, or an approved choice. Add the original link and the date you last checked it.

Separate evidence from interpretation. For the onboarding guide, a source might say that customers can contact support through a form. Your proposal might be to put that form in the welcome email. Those sentences should not merge into a false claim that the company has already approved the email change.

Project: Customer onboarding guide
Question: How should new customers contact support?
Source: Link to the approved support instructions
Checked: Date the source was last reviewed
Confirmed: The support form is the current contact route
Proposal: Add the form link to the welcome email
Waiting: A person must approve the email change
Next: Review the draft wording against the source

For a broader explanation of reusable knowledge, see what an AI second brain is. If you want versioned Markdown notes, the GitHub second-brain guide covers that storage choice.

What should Hermes read before it acts?

Start each task with a short reading request. Name the project overview, the current checkpoint, and the subject it should investigate. Ask it to identify the sources used and any conflict between them before drafting an answer.

Then give a bounded task. “Revise the welcome section using the approved support route; leave the proposed email change open” is clearer than “Use my second brain to finish onboarding.” A precise request makes it easier to see whether the assistant respected the difference between a fact and a proposal.

The Hermes skills documentation↗ (opens in a new tab) describes skills as knowledge documents loaded when needed. A reviewed procedure can be useful for repeating the reading and checkpoint routine. Keep project-specific status in the project record so the procedure does not preserve yesterday’s unfinished task as a permanent step.

For work that also involves another AI app, use a single shared decision record rather than copying the approved answer into several private memories. fenbs keeps that record with the task and context; its handoff workflow explains what the receiving session needs.

How do you save a checkpoint you can trust?

Ask Hermes to save the outcome to the named project location, then inspect it. A chat message saying something was remembered does not prove that the right record changed. Confirm the checkpoint exists and describes the result you actually reviewed.

Include the work completed, the checks performed, anything unverified, and the first action for the next session. If a person still needs to approve a proposal, write that plainly. Do not let “draft prepared” become “change approved” in the handoff.

• Completed: The welcome section uses the confirmed support form.
• Checked: Its wording matches the approved support instructions.
• Not checked: Whether the form opens correctly from the email client.
• Waiting: A person must approve adding the link to the welcome email.
• Next: Check the form link, then present the email proposal for review.

Before beginning another task, read the checkpoint as a newcomer would. If it does not say where the draft is or which source was checked, add that information. A short, inspectable record is more valuable than a long account that hides the next action.

How to do this with fenbs

1. Create a free account and add the project whose current work needs a shared record.
2. Add the active tasks and the source links that explain them. Record decisions and continuing rules people have already agreed.
3. Read the relevant project context yourself and give Hermes a selected summary for its task. Keep the original references so its conclusions can be checked.
4. Record the checked outcome and Where we left off yourself, or use one of the supported clients on Integrations to update that work record.

fenbs does not list Hermes among its supported setup guides. Use this as an explicit handoff, and do not expect automatic synchronization between Hermes memory and fenbs. The supported connected assistants use MCP, a standard way for an AI app to use an outside tool, with browser sign-in.

fenbs is free for one person, no credit card. It is not the right fit if all you need is a private Hermes memory setup or a searchable document archive. It is useful when tasks, rules, decisions, and progress need a maintained home that other supported assistants can also read.

How do you check the routine in a fresh session?

Ask a fresh Hermes session to find the project overview, identify the confirmed support route, and explain what remains unapproved. Check whether it reads the files and preserves the uncertainty. If it relies on an old assumption, correct the saved note and repeat the test.

Review after a few tasks. Remove notes that do not help, repair broken source links, and replace stale checkpoints. The second-brain topic hub covers adjacent setups; keep this one small until a real work problem calls for more.