Hermes Agent: what it remembers, how it learns and how to start

The second time you ask an assistant to prepare a research brief, you probably want the same standards applied to different material. It should remember that you distinguish plans from completed events, follow the method you corrected last time, and leave yesterday’s facts behind. That combination is the useful question behind Hermes Agent: what can an agent retain without confusing a reusable method with an old answer?

Hermes is an MIT-licensed agent application from Nous Research. It combines a model connection with tools, conversation state, persistent memory and reusable skills, accessible through interfaces including a CLI, desktop app and messaging integrations. The project’s documentation puts repeated use and adaptation at the center of its design. Repository · Documentation

This guide follows official sources checked on 20 October 2026 and refreshed on 27 October 2026. It explains documented behavior and proposes an exercise; it does not report a hands-on installation or benchmark. Living documentation can describe behavior beyond a particular stable build, so the installed version matters.

What you are actually running

Hermes coordinates the work. The underlying language model interprets the request and proposes responses or tool calls; the runtime manages the conversation and executes available tools. Its architecture separates interfaces, model interaction, tools and stored state. A third-party service offering hosted Hermes is an additional deployment arrangement, with its own terms and access. Architecture

The provider documentation describes hosted models, custom OpenAI-compatible endpoints and local model routes. Running Hermes on your laptop does not establish where inference happens. A local runtime can still send prompts to a remote provider; a local model route needs a working local inference service and suitable hardware. Authentication, model availability and billing depend on the selected integration. A consumer subscription should not be assumed to authorize every model route or make every call free. Model providers

For a first attempt, use one model connection whose access and costs you already understand. Keep it unchanged through the exercise. If you change the model, tool permissions and saved procedure together, a better answer gives you little evidence about which change helped.

Three kinds of state

Suppose your recurring task is a brief assembled from a few dated announcements. The conversation contains today’s sources and corrections. A lasting preference might say that you want plans separated from completed events. A reusable skill could describe how to compare the sources and attribute the resulting claims.

These have different jobs:

Conversation and history

An ordinary session holds the current exchange. Hermes also stores session history in a SQLite database and offers ways to search earlier conversations. Stored history is not equivalent to placing every previous message into every model request. Resuming a session, starting another one and compacting an existing conversation are different operations. Sessions

In the briefing example, today’s cards and the correction belong to the working conversation. An old conversation may help explain how a decision was reached, but its product dates should not silently become facts in a new brief.

Durable facts and preferences

The documented built-in memory uses MEMORY.md and USER.md for retained information, including environment facts and user preferences. Their contents are injected as a snapshot at session start. Memory-tool changes persist to storage, subject to configured write approval; the system-prompt snapshot is not continuously rewritten during that session. Persistent memory

For this example, a preference about separating plans from confirmed events is worth retaining. The fictional launch date in a practice card is not a preference about you. Ask to inspect the entry itself and its save state. A conversational assurance that something was remembered is weaker evidence than the stored text.

Reusable procedures

A skill supplies instructions for a kind of task. Hermes documents skills as folders centered on SKILL.md, potentially accompanied by references or helper files. The skill index helps discovery; full instructions and supporting material can be loaded when needed. This reduces how much material must be included up front, but the index still occupies context. Skills system

You can inspect skills and invoke one explicitly, including through its slash command. The practical advantage is that the procedure is readable: check whether it tells the agent to compare dates, identify superseded claims and cite evidence, rather than simply trusting a claim that it has “learned your workflow.” Working with skills

The documented learning mechanism includes creating or revising these retained instructions and context. It does not establish that the underlying model’s weights were retrained, that every correction becomes a good skill, or that later answers will necessarily improve. The distinction matters because a saved mistake can also be reused. Skills system

A manageable first setup

Start with the official installation instructions and platform matrix. The desktop distribution bundles a runtime; CLI installation is another route. Check the specific operating system, architecture and release asset before choosing.

There is a documentation conflict for Intel Macs: the installation page states a broad exclusion, while the platform matrix describes conditional x64 desktop and CLI routes. That is not a reliable basis for saying every Intel Mac is unsupported, or that every release has an Intel desktop download. Follow the platform-specific route and verify the actual release asset.

After an official CLI installation, the quickstart provides these configuration entry points:

hermes setup
hermes model
hermes tools

They cover initial setup, model selection and available tools. The current quickstart requires a model context window of at least 64,000 tokens. A local endpoint therefore needs an appropriate context configuration, not merely a reachable server. Quickstart

The same quickstart offers a Blank Slate setup. It retains File Operations and Terminal while disabling other capabilities initially. It is not a read-only mode or a sandbox. Enable memory and the relevant skill tools before attempting the persistence exercise below; otherwise an absent save may simply reflect the chosen configuration.

Use a dedicated folder containing only the practice inputs, and inspect the available capabilities. A folder is useful organization, but a request to stay inside it is an instruction, not an operating-system boundary. Hermes’ security documentation distinguishes local command execution from sandbox backends. Approvals do not themselves create process isolation, and a container’s access still depends on its mounts and credentials. Security

Keep the first task small enough that you can read both the supplied evidence and the complete answer. There is no need to connect a messaging account or add third-party services to find out whether the basic briefing workflow is useful.

Profiles, Bot Mode and optional connections

Profiles let you keep separate configurations and state for different agents or uses. They are useful for organizing an experiment, but do not by themselves establish a hard security boundary. Be deliberate about the active profile: a result produced in a different profile is not a clean check of what the original one retained. Profiles

Desktop Bot Mode adds a persistence detail that can otherwise confuse testing. In a canonical Bot Chat, /new and /reset are routed to compaction rather than a truly fresh conversation. For the exercise, use ordinary CLI sessions in the same profile and verify their identities. Closing the desktop window also does not necessarily stop the messaging gateway; the documented explicit stop command is hermes gateway stop. Bot Mode

Additional integrations are choices for later. MCP can expose tools through configured local subprocesses or remote HTTP services; adding a server changes the tools available to the agent. Messaging integrations provide another place to interact with it. Neither is needed for the supplied-card task. MCP · Documentation

Scheduled work introduces a separate operational question. Hermes documents cron jobs and execution through the gateway, with run history to inspect. A job definition, an elapsed scheduled time and a successful completed result are different evidence. Establish the interactive workflow first, then decide whether recurring execution is useful. Cron scheduling

Try a brief, then save the method

The following exercise is original fictional material for the reader. We have not run it. It tests whether you can inspect a correction, a saved preference and a reusable procedure. It is not a reliability benchmark.

Before starting, record the Hermes version, model/provider, active profile, enabled tools and first session identifier. Use ordinary sessions, not a canonical Bot Chat. Keep the later correction and reviewer key out of the first input.

1. Supply only the first three cards

Kite Card A — 1 September 2026: The Kite notes app team plans a private beta on 12 September. The beta is expected to support text notes. There is no statement that it has launched.

Kite Card B — 10 September 2026: The planned private beta moves to 19 September. This replaces the earlier planned date. There is still no confirmation of a completed launch.

Kite Card C — 11 September 2026: CSV export is proposed. No delivery date or release is confirmed.

Ask:

Using only these fictional cards, write a short brief with the latest planned beta date, current completion status, CSV-export status and unresolved questions. Attribute factual statements to the cards. Do not browse, contact anyone, publish, install anything or alter the source cards.

Save the answer before correcting it. Check whether it treats a scheduled date as an event that happened. The answer should preserve uncertainty even if the real calendar is already later than the fictional dates.

2. Introduce the correction separately

Kite Card D — 15 September 2026: The private beta is postponed. No replacement date is announced. Text notes remain planned, with no confirmation that the beta has launched.

Ask:

Revise the brief using Card D. Explain which earlier statements change, preserve source attribution and keep unresolved questions explicit. Do not invent a replacement date or treat planned functionality as released. Keep the earlier version available for comparison.

Inspect the revised text. It should withdraw 19 September as the current plan, preserve the lack of launch confirmation, and leave the CSV-export claim at the evidence level supported by Card C. The key observation is an actual correction to the result, not an apology followed by the same answer.

3. Save a small editorial preference

Once you have reviewed the correction, ask:

Remember this editorial preference: when preparing a source-based brief for me, separate confirmed events, plans and unresolved questions. Do not store the fictional product names or dates as facts about me. Show the memory entry you propose and whether it was actually saved or is awaiting approval.

Inspect the real entry. Complete any configured approval yourself if you want it retained. The memory documentation distinguishes write approval from notifications about background review; a notification setting is not proof that a proposed write has been accepted. Persistent memory

Reject an entry that turns Kite’s launch dates into lasting personal knowledge. Retain only the preference you intended. Record whether the write succeeded, remained pending or was unavailable.

4. Turn the method into a skill

Ask:

Create a reusable skill named source-card-brief for briefing from supplied source cards. First inspect whether that name already exists and show any proposed change. The procedure should identify which card supersedes an earlier claim, distinguish scheduled dates from completed events, cite each factual statement and preserve unknowns. Keep fictional project names, dates and answers out of the reusable procedure. Do not browse, send messages, install anything or publish. Show the resulting SKILL.md and whether it was written or is awaiting approval.

Read the actual file. A useful procedure could tell the agent to build a short claim list, resolve later corrections and preserve missing evidence. It should remain useful when every product name and date changes. Remove one-off answers from the procedure, and inspect any referenced files as well.

Hermes documents agent-managed skill creation and updates, with an optional write-approval gate. A draft shown in chat may still be awaiting a real write. Skills system

5. Use a fresh case in a fresh ordinary session

Keep the same profile, but begin a genuinely new ordinary CLI conversation without resume or continue options. Record the new session identifier. Ordinary /new behavior and conversation resumption are documented separately from Bot Mode’s special handling. Sessions

Deliberately invoke source-card-brief, and inspect the evidence that its instructions were loaded. Then supply only these new cards:

Harbor Card 1 — 2 October 2026: The Harbor notes app team plans a public preview on 8 October. Shared folders are expected to be included.

Harbor Card 2 — 7 October 2026: The planned preview moves to 16 October. The announcement contains no confirmation that the preview has launched.

Harbor Card 3 — 9 October 2026: Offline editing is being considered. It has no release date.

Ask:

Use the source-card-brief skill to brief only these Harbor cards. Include the latest planned preview date, completion status, offline-editing status and unresolved questions, with card attribution. Do not browse, send, publish or use facts from the earlier Kite exercise.

Keep the reviewer key separate until the response is saved. It should identify 16 October as the latest planned date, leave completion unconfirmed, describe shared folders as expected and offline editing as under consideration, and contain no Kite facts.

A correct brief does not prove which retained element caused it. The preference and procedure overlap, and the new prompt also asks for careful attribution. Inspecting a loaded skill establishes its use; measuring improvement would require a separate controlled comparison.

When persistence does not help

Inspect configuration and artifacts before concluding that memory “worked” or “failed.” Was the entry actually saved? Were memory and skills enabled? Did the new session use the same profile? Was it new, resumed or compacted? Did the intended skill load?

Then inspect the substance. A perfectly saved procedure can be outdated or wrong. A skill that embeds Kite’s dates may reproduce them confidently in Harbor’s brief. A general preference can be too vague to guide a difficult correction. These are different failures, and each suggests a different repair: configuration, retrieval, procedure editing or better reasoning over the supplied evidence.

There is also a version caveat. The latest listed release observed on 20 October was v0.22.2, dated 15 October. Its notes say v0.22.1 was built from the wrong commit and identify a remaining issue affecting deletion of sessions that ran under the v0.22.1 gateway. Check the installed version and release notes before relying on that behavior. v0.22.2 notes · Release index

At the 27 October refresh, the release index listed v0.22.5 as latest. Its notes name 22 October as the release date; GitHub shows publication on 23 October. The notes also distinguish distribution channels: desktop installations from the installer wait for the next bundled release. Check the update route for your installation rather than assuming every distribution carries the same version. v0.22.5 notes

Hermes is worth investigating when repeated work benefits from inspectable state, reusable procedures and a choice of model. That is a judgment about fit, not a ranking or a measured performance claim. For a single disposable question, maintaining a runtime may add little. For recurring work, the useful outcome is a method you can read, correct and deliberately reuse with new evidence.