Hermes, Obsidian, and the governance boundary for agent memory

Hermes Agent becomes safer when its long-term context is treated as a governed system instead of a convenient dumping ground. Obsidian notes, curated memory, session history, and reusable SKILL.md files all preserve context, but they should not preserve the same kind of context or carry the same authority. The operational mistake is to let every useful sentence become memory, every repeated workflow become a note, every transcript become policy, and every scheduled task become a background editor. That may feel productive for a week. Over time it creates an agent that is hard to audit because facts, preferences, procedures, and unattended automation are mixed together.

The better model is a boundary model. Use Obsidian or another Markdown vault for human-owned working notes. Use Hermes persistent memory for small, curated facts that should be injected at the start of future sessions. Use session search as an evidence log over past conversations, not as a substitute for deliberate memory. Use Hermes skills for reusable procedures that are long enough, conditional enough, or risky enough to deserve their own governed document. Then place review gates and cron limits around the points where context can become action.

This is not bureaucracy for its own sake. It is how an agent with real tools stays useful without slowly turning every old conversation into hidden policy.

Four context stores, four different jobs

The first governance rule is that storage location determines authority. A note in an Obsidian vault is not the same thing as a memory entry. A session transcript is not the same thing as a skill. A skill is not merely a long memory. Each store should answer a different question.

Notes answer: what is the human thinking about? Obsidian is well suited for drafts, meeting notes, research clippings, project journals, personal reflections, diagrams, and material that is valuable because a person can read and reorganize it. Notes can be speculative. They can contain conflicting ideas. They can be messy. Their governance advantage is that they are visibly owned by the user and edited as documents, not silently injected as agent truth.

Curated memory answers: what should the agent reliably remember before a session starts? The Hermes memory documentation describes built-in memory as bounded and curated. Entries are loaded from disk at session start and rendered into the system prompt as a frozen snapshot. The built-in stores include MEMORY.md for durable operational facts and lessons, and USER.md for user profile information such as preferences, communication style, and expectations. That injection model makes memory powerful, but it also makes over-saving dangerous. Memory should be short, stable, and generally useful.

Session history answers: what actually happened before? Hermes stores CLI and messaging sessions in a local SQLite state database and exposes a session_search tool that can retrieve real past messages. This is evidence, not policy. A transcript may contain mistakes, temporary assumptions, outdated facts, or private details that were needed once. It is valuable because it preserves provenance. It is risky when treated as automatically valid instruction.

Skills answer: what procedure should the agent follow when a recurring task appears? Hermes skills are on-demand knowledge documents under the skills system. They use SKILL.md and can include references, templates, scripts, and assets. The official skills documentation is explicit that memory and skills work together: memory stores small durable facts that should always be in context, while skills store longer procedures that should load only when relevant. That sentence is the governance hinge. If a behavior is long, multi-step, tool-specific, or subject to review, it belongs in a skill, not in always-on memory.

Why Obsidian should not become automatic memory

Obsidian is attractive as an agent memory backend because it is local, Markdown-based, inspectable, and already structured around backlinks and folders. Those are exactly the reasons to keep it human-governed. A vault can contain half-formed ideas, private journals, scratch research, copied quotations, stale decisions, and contradictory project notes. If an agent treats the entire vault as authoritative memory, the user loses the ability to draft safely.

A safer Obsidian pattern is selective promotion. Notes may be source material. They may be searched when the user asks for them. They may be summarized into a proposed memory or converted into a skill after review. But the vault should remain the workspace, not the agent's automatic belief system. This gives the user room to think without every line becoming part of the assistant's identity.

For example, a note that says, "I might move the blog to a different framework," is not a durable fact. It is a working thought. A memory entry might later say, "The user prefers static site deployments with explicit smoke checks," if that preference has been repeatedly confirmed. A skill might say, "When operating this site ecosystem, inspect the relevant app path, validate content schema, preserve unrelated files, and run the app's validation script before reporting." The difference is not semantic trivia. It changes how much authority the future agent assigns to the text.

The promotion ladder: note to memory to skill

A practical governance system needs a promotion ladder. Without one, agents either remember too little or remember everything. The ladder should be conservative.

Start with notes. A note can hold raw observations, decisions under consideration, links, transcripts, user preferences that may not be stable, and project research. The threshold for writing a note is low because notes remain human-readable and human-owned. They do not have to be globally true.

Promote to memory only when a fact is stable, compact, and useful across many future sessions. Good memory entries include preferred communication style, recurring environment facts, stable project paths, known tool quirks, and durable constraints. Bad memory entries include one-off task details, temporary credentials, unreviewed claims, large procedures, scraped text, and anything that requires source context to interpret. Because Hermes injects memory at session start as a frozen block, memory should not be used as a running log. It should be the short set of facts the agent should bet on.

Promote to a skill when the content describes a procedure, not just a fact. A skill can say when it should be loaded, which tools are needed, what commands or API calls work, what pitfalls to avoid, and how to verify success. It can also include scripts and templates. This makes skills the right place for repeatable workflows, review checklists, deployment rituals, research methods, content publishing rules, and troubleshooting playbooks.

Keep session history below all of these. It is the audit trail that helps decide whether promotion is justified. If the agent claims that a preference was confirmed, session search can provide the prior messages. But the transcript itself should not silently become a rule. The transcript is how you check the rule.

Permissions are part of memory design

Hermes has tools that can read files, write files, run commands, search the web, manage skills, search sessions, and schedule work. Memory governance is therefore not just about data quality; it is also about permissions. A memory entry that says "always deploy after validation" is not just a note. It changes future action. A skill that includes a production restart command is not just documentation. It is executable operational knowledge once loaded into an agent with terminal access.

The official Hermes profile model helps here. A profile is a separate Hermes home directory with its own config, API keys, memory, sessions, skills, cron jobs, and state database. Profiles let users separate agents for different purposes without mixing state. That is a governance primitive. A personal research profile should not share the same memory, skills, cron jobs, and gateway state as a production operations profile unless the user deliberately cloned or configured it that way.

Profiles do not replace file permissions or source control. They reduce accidental context bleed. If a research profile learns a speculative workflow, it should not become a production deployment skill by proximity. If a work profile has access to private repositories and cron delivery channels, it should not inherit a hobby profile's experimental skills. When in doubt, use separate profiles for separate trust domains.

Review gates should sit at the write boundary

The right review point is not every read. It is every promotion and every persistent write that will affect future sessions. Hermes supports this directly. The memory documentation describes memory.write_approval, which can require approval before memory writes are saved. With the gate enabled, foreground writes can be reviewed inline in the CLI, while messaging platforms, scripts, and the background self-improvement review can stage writes for review. The user can then inspect pending memory writes and approve or reject them.

Skills have a parallel but stricter need for review. The skills documentation describes skills.write_approval. When enabled, skill writes such as create, edit, patch, file writes, or remove operations are staged under pending skill storage and reviewed with commands such as pending, diff, approve, and reject. This matters because a SKILL.md can be large and operationally powerful. A memory entry might bias the next answer. A skill can bias the next tool sequence.

Review gates should be treated as production controls, not as convenience toggles. If Hermes is used only as a local drafting assistant, free writes may be acceptable. If Hermes is connected to messaging platforms, repositories, deployment credentials, cron jobs, or shared skill directories, write approval becomes much more important. The user should not learn that an unattended background review changed a reusable procedure only after a future task follows it.

The background review is useful, but it needs consent

Hermes' self-improvement loop is one of its strongest features. After difficult or repeated work, the agent can save what it learned as memory or patch a skill. That is how local operational knowledge compounds. The same mechanism is also a governance risk if it quietly converts recent behavior into future authority.

The safest posture is consent-aware learning. Let the background review suggest memory and skill updates. Require approval in environments where the agent has meaningful tool access. Keep the preview short, but make the diff available. Reject changes that are too broad, too specific to a one-off task, or based on unverified facts. Approve changes that capture a stable preference, a verified path, a real command sequence, or a pitfall that was actually encountered.

For skills, prefer patches over whole rewrites when the improvement is narrow. Patches are easier to review and less likely to erase useful constraints. Whole-skill edits should be reserved for major reorganizations. Deletions deserve special scrutiny because a removed skill can take away a safety procedure that future sessions depended on.

Cron changes the threat model

Scheduled tasks are where context governance becomes a security issue. The official Hermes cron documentation says cron jobs can schedule one-shot or recurring tasks, attach zero, one, or multiple skills, run in fresh agent sessions, and optionally run script-only jobs. It also says cron execution is handled by the gateway daemon, which ticks the scheduler, claims due jobs, starts a fresh session for each due job, optionally injects attached skills, records executions, and writes output.

That model is useful because it keeps scheduled work out of the active chat. It is risky because the user may not be present when the job runs. A cron job with web and file access can fetch new information and modify local artifacts. A cron job with terminal access can run commands. A cron job with attached skills can inherit a long procedure. A continuable cron delivery can put the result back into a messaging thread where follow-up replies continue from the job context.

The documentation includes important guardrails. Cron-run sessions cannot recursively create more cron jobs because Hermes disables cron management tools inside cron executions to prevent runaway scheduling loops. Scheduled task prompts are scanned for prompt-injection and credential-exfiltration patterns at creation and update time. Cron jobs can also be configured with limited toolsets, which is essential for cost and risk control. These controls are helpful, but they do not remove the need for human design.

A good cron threat model asks five questions. First, what can this job read? Second, what can it write? Third, which skills does it load? Fourth, where is the output delivered? Fifth, what happens if the prompt or upstream content is malicious? A job that checks a public RSS feed and posts a digest has a different risk profile from a job that reads a private repository, edits files, and sends summaries into a team channel.

Skills attached to cron should be smaller, not larger

It is tempting to attach a broad all-purpose operations skill to a cron job so the scheduled agent has maximum context. That is usually the wrong direction. Cron jobs should load the smallest skill set that explains the task and its verification rules. The prompt should contain everything the job needs that is not already provided by attached skills, but it should not carry general authority to roam.

For a monitoring job, the skill might define the data source, the exact command or API endpoint, the expected output shape, the threshold for waking the model, and the delivery format. It should not include unrelated deployment steps. For a content watch job, the skill might define allowed sources, duplicate-detection rules, citation requirements, and a no-publish-without-review rule. It should not include credentials, destructive commands, or instructions to modify site files unless that is explicitly the job.

Script-only cron jobs can reduce risk when the message is fully determined by code. If the job only needs to run a deterministic check and deliver stdout, skipping the LLM removes a large class of prompt-injection problems. When the LLM is needed, pre-check scripts can decide whether a scheduled run should spend tokens at all. That also reduces the number of unattended model turns exposed to untrusted input.

A concrete governance policy

A workable policy for Hermes plus Obsidian can be short enough to remember:

• Keep Obsidian as the human workspace. Search it when asked, but do not treat the whole vault as always-on memory.
• Save only stable, compact, cross-session facts to Hermes memory.
• Use session search for provenance and reconstruction, not for silent instruction.
• Promote repeatable procedures to SKILL.md, with triggers, exact steps, pitfalls, and verification.
• Enable memory and skill write approval when Hermes has access to repositories, terminals, messaging gateways, cron, shared skill directories, or production systems.
• Separate trust domains with profiles. A profile boundary should map to a real operational boundary.
• For cron, use the narrowest toolset and the smallest relevant skill set. Prefer script-only jobs for deterministic checks.
• Review any skill that can change files, run shell commands, send messages, deploy, delete, or update other persistent context.

This policy is intentionally conservative. The goal is not to stop Hermes from learning. The goal is to make learning inspectable. Notes can be messy. Memory should be compact. Session history should be evidentiary. Skills should be procedural. Cron should be treated as unattended execution.

What belongs where

When deciding where to put a new piece of context, use the failure mode as the test. If the information is wrong in a note, the user may be confused later, but the agent is not automatically biased. If the information is wrong in memory, every future session may start with a false premise. If the information is wrong in a skill, future tool use may follow a broken procedure. If the information is wrong in cron, the mistake can run when no one is watching.

That hierarchy explains why governance should become stricter as context moves from note to memory to skill to scheduled execution. A rough idea belongs in Obsidian. A confirmed preference belongs in memory. A verified workflow belongs in a skill. A recurring workflow belongs in cron only after the skill, prompt, toolset, schedule, and delivery target have been reviewed.

Hermes is powerful precisely because it can remember, search, learn, and act. The boundary discipline is what keeps those verbs from collapsing into one another. A governed Hermes setup does not ask the agent to forget. It asks the agent to remember in the right place, with the right authority, and with review at the points where remembered context becomes future action.