The discipline in Part 1 of this sub-series rests on a button. A session fills up, quality drifts, you write a small scoped handoff document, close the session, and open a clean one. All of it hangs on the fact that a session ends.
Now take the button away.
An always-on agent is a different category from a chatbot you prompt. It runs as a daemon, listens on messaging channels, wakes itself on a schedule, spawns background work, and rewrites its own skills after a task goes well. Nobody closes it. What replaces the reset button when the harness never resets?
The harness we used to answer that is Hermes Agent, built by Nous Research and described on its own README as “the self-improving AI agent,” tagline “The agent that grows with you” [1]. One naming caution: the Hermes name also attaches to Nous Research’s open-weight language models, so check that you are reading about the harness.
The 100 hours in the title are not ours. They belong to a practitioner walkthrough that put Hermes on our list, describing v0.15.0, “The Velocity Release,” 2026-05-28 [2]. What we did was read that walkthrough against the vendor’s own documentation for the current release, v0.19.0, “The Quicksilver Release,” 2026-07-20 [3]. The gap between the two is the article. “AI employee” in the title is our framing, never the vendor’s.
Figure 1 - The Agent That Never Closes: An always-on harness has no session boundary to recover quality at, so the discipline moves into three standing parts: a capped identity layer (SOUL.md, MEMORY.md), searchable history (state.db), and gates that stop the agent acting unreviewed.
A Harness That Never Closes
Hermes runs a gateway listening across more than 20 documented messaging platforms, Telegram, Slack, Discord, WhatsApp, Signal, SMS and email among them [4]. When a follow-up arrives mid-task, the gateway picks one of three behaviors: interrupt, the default, which restarts generation with the new message folded in while preserving reasoning already shown, queue, which runs it as the next turn, and steer, which injects it into the current run after the next tool call [4]. The commands that drive that choice are /steer and /queue, alongside session controls such as /new, /stop, and /compress, a small slice of a reference that runs to dozens of commands [5]. There is no /interrupt command, since messaging a busy agent redirects its active turn by default [4].
The agent also wakes itself. Cron jobs sit as plain JSON at ~/.hermes/cron/jobs.json, the gateway daemon ticks the scheduler every 60 seconds, and each due job runs in an isolated session with output written to ~/.hermes/cron/output/{job_id}/{timestamp}.md [6]. Jobs are created in chat with /cron add, on the command line with hermes cron create, or in plain natural language [6]. /background runs a prompt in a separate background session [5], and subagent delegation spawns child instances with isolated context and restricted toolsets [7].
That is a process with no stopping point and a schedule it enforces on itself. The walkthrough that started us on this adds a pre-dawn summarization job feeding a morning brief, which is one practitioner’s own scheduled job and not a Hermes feature.
Figure 2 - Three Ways In, No Way Out: Messages arrive across more than 20 platforms, the scheduler ticks every 60 seconds, and background sessions run out of band [4][5][6]. Nothing in that loop has an end state.
The Memory Inversion
The naive expectation is that an always-on agent works because it remembers everything, accumulating one giant markdown file. It does not.
Hermes’s built-in memory is tiny and hard-capped. MEMORY.md caps at 2,200 characters, roughly 800 tokens, and USER.md caps at 1,375 characters, roughly 500 tokens [8]. That is about 1,300 tokens of built-in memory in total, for an agent meant to run for months. Both live at ~/.hermes/memories/, both are managed by the agent through a memory tool that adds, replaces, or removes entries, and the docs spell the filenames in uppercase [8].
Durable recall lives somewhere else. Every conversation persists to SQLite at ~/.hermes/state.db with FTS5 full-text search, exposed as a session_search tool with three calling shapes for discovery, scrolling, and browsing, returning actual messages with no summarization and no truncation [8].
That inversion generalizes past Hermes. The always-on agent does not carry its history. It carries a small curated statement of who it works for and what it has learned, then searches for the rest on demand. Anthropic’s context-engineering guidance argues for the same thing from the other direction, telling you to “find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome” [9]. A 1,300-token cap is that principle enforced in code rather than recommended in a blog post.
KEY INSIGHT: Persistent memory is a curation problem, not a storage problem. If your agent’s memory grows without a cap, you have built a slower, dirtier search index. Cap the always-loaded layer, then make the archive searchable.
Figure 3 - 1,300 Tokens Loaded, Everything Else Searched: MEMORY.md caps at 2,200 characters and USER.md at 1,375. Durable recall comes from FTS5 search over the session database, not an accumulating file [8].
The third tier is optional, and its size depends on whether you believe the docs’ sentence or the docs’ own list. The Memory Providers page says Hermes ships eight external memory-provider plugins, then enumerates nine: Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, and Memori [10]. They run alongside built-in memory rather than replacing it, prefetching relevant memories before each turn in the background and extracting memories at session end [10].
One popular option is not on that list at all. The LanceDB semantic-memory integration is a third-party plugin, not one of the bundled set, and it ships four tools rather than the three usually quoted: lancedb_remember, lancedb_recall, lancedb_read, and lancedb_forget [11]. The fourth is the interesting one. lancedb_read “fetches a single memory by ID, optionally with the original conversation messages it was drawn from, so the agent can check where a fact came from” [11].
Figure 4 - The Three Tiers, Corrected: A capped markdown layer sits above a searchable session database, with the bundled provider plugins alongside rather than instead of it, eight by the docs’ count and nine by the docs’ own list [8][10]. LanceDB is a third-party plugin, not one of them [11].
Frozen on Purpose
SOUL.md, MEMORY.md, and USER.md are injected into the system prompt as a frozen snapshot at session start, and they deliberately never change mid-session [8]. An agent that learns something at turn 12 does not get an updated memory block at turn 13. The reason is economic: the system prompt is cache breakpoint 1 and stays cached across every turn, and Hermes ships a built-in cross-session 1-hour prefix cache for Claude [7][12]. Rewriting memory mid-session would invalidate that prefix every time, so the harness trades staler in-session memory for a cache that holds.
Compression is the other half of the same budget. The config key is compression.threshold, default 0.50 as a fraction of the model’s context window, and the trigger it computes, threshold_tokens, is that fraction times the main agent model’s context length rather than the auxiliary model’s [12]. On a 262,144-token model at the default, compression fires at 131,072 tokens, and a fixed 85% safety net in the gateway catches sessions that escaped the agent’s own compressor [12]. threshold_tokens is also settable directly as an optional absolute cap, null by default, and when it is set compression fires at the lower of the ratio-based threshold and that absolute count [13]. The reason it exists is model switching. The cap is clamped to the model’s context length, so moving between windows of very different sizes cannot push the trigger later than the token number you picked [13].
The same cost logic drives per-subtask model routing. Every auxiliary slot takes its own provider, model, and base_url, and the documented slots include vision, web_extract, approval, compression, and kanban_decomposer, drawn from a provider list running to several dozen entries, from hosted APIs to self-hosted endpoints [13][14]. The judge that fires after every turn is a per-turn cost, so pointing it at a small model is one of the highest-leverage lines in the file.
Figure 5 - Frozen to Keep the Cache: Identity and memory are captured once at session start and never rewritten mid-session, so the prefix cache stays valid [8][12]. Compression fires at 50% of the window, with an 85% gateway backstop [12][13].
Identity as a File, Isolation as a Directory
SOUL.md lives at ~/.hermes/SOUL.md and occupies slot #1 in the system prompt, ahead of tool guidance, memory, skills, and context files [15]. Hermes creates a starter file automatically if none exists, and falls back to a built-in default identity if the file is empty or cannot be loaded [15].
Identity in one file is half the isolation story. The other half is Profiles, which most third-party write-ups get wrong. A profile is a separate Hermes home directory carrying its own config.yaml, .env, SOUL.md, memories, sessions, skills, cron jobs, and state database [16]. Profiles live at ~/.hermes/profiles/<name>/, are created with hermes profile create <name>, and are selected with a command alias, a -p flag, or hermes profile use, driven underneath by the HERMES_HOME environment variable [16].
That is far stronger than giving each agent a different model. A research profile and a client-work profile share nothing: not identity, not memory, not credentials, not scheduled jobs. Anyone who has watched one always-on assistant blur two engagements together knows what that buys.
Figure 6 - Identity First, Then a Wall Between Contexts: SOUL.md occupies slot #1 in the system prompt [15]. Each profile is a separate home directory carrying its own copy of every one of those layers, including its own SOUL.md, config, credentials, memory, sessions, skills, cron jobs, and state database [16].
The Vendor Shipped the Gate
Hermes’s self-improvement is real and first-party. The agent creates, updates, and deletes its own skills through a skill_manage tool the docs call “the agent’s procedural memory” [17]. It writes a skill after completing a complex task of five or more tool calls, after errors, after user corrections, and when it discovers a non-trivial workflow [17]. Skills live in ~/.hermes/skills/ and follow the open agentskills.io standard [17][18].
An agent that edits its own procedures without review is a compounding-slop machine, since every mediocre skill becomes the template for the next one. We expected to make that argument as a practitioner’s objection. We did not have to, because the vendor made it first, then shipped the answer switched off.
Hermes ships a skills.write_approval gate that stages an agent-authored skill change for human review, plus a matching write_approval gate on memory writes [8][17]. Both default to off. The docs are blunt about what that means: by default the agent “writes skills freely,” including from the background self-improvement review that runs after a turn [17]. Turn the gate on and the queue is worked with /skills approve and /skills reject, each taking an id or all [17]. While an agent is running, the gateway intercepts running-session commands such as /stop and /status [19].
Out of the box, then, a self-improving agent rewrites its own procedural memory unreviewed, including from a review pass it runs on itself. The company that built the switch left throwing it to you.
KEY INSIGHT: A vendor shipping an approval gate on its own headline feature is the strongest available signal the feature needs one, and shipping it off by default means every fresh install is running ungated. Turn it on before you have a week of self-authored skills nobody read.
Figure 7 - Self-Improvement With a Latch: The agent proposes a skill after a successful complex task, and skills.write_approval holds the change for review once you turn it on. The gate ships off, and a matching gate covers memory writes [8][17].
Goals Need a Stopping Condition
/goal gives Hermes “a standing objective that survives across turns,” and after every turn a lightweight judge model checks whether the goal is satisfied by the last response, returning strict JSON with a done boolean and a reason [20]. The continuation budget defaults to 20 continuous turns, config key goals.max_turns, and when it runs out “Hermes auto-pauses and tells you exactly how to proceed” [20].
The part worth copying is the completion contract. A goal can carry five optional fields, outcome, verification, constraints, boundaries, and stop_when, and when they are set the judge prompt “decides done only when the verification criterion is met with concrete evidence” [20]. That converts “keep working until it seems finished” into a checkable condition. It gates on verification rather than ownership, so it does not cover the step only a human can do, but it is a real answer to runaway loops.
Two honest notes. The “super goal” pattern circulating in community write-ups, where each step is labelled human-owned or AI-owned, is a practitioner extension on top of /goal, not a Hermes feature. The docs also credit the idea openly, calling /goal their own take on the Ralph loop, directly inspired by Eric Traut’s /goal in Codex CLI 0.128.0 [20].
Figure 8 - A Loop With a Checkable Exit: A judge model evaluates every turn, a five-field completion contract defines what “done” has to prove, and a 20-turn budget auto-pauses the loop [20].
What Anthropic Found When It Ran One for Months
Everything above is architecture. The best public evidence about what actually degrades over a long horizon comes from Anthropic.
Project Vend put a Claude instance named Claudius in charge of a real automated shop inside Anthropic’s office, with web search, a simulated email tool for requesting physical restocking labor from Andon Labs employees, customer chat, and control of prices [21]. Employees repeatedly talked it into discount codes and loss-making sales, notably a run on tungsten cubes, and in Anthropic’s own words it “did not reliably learn from these mistakes” [21].
The identity failures are usually quoted and usually garbled, so here they are precisely. Under a section Anthropic headed “Identity crisis,” which opens “From March 31st to April 1st 2025, things got pretty weird,” Claudius “hallucinated a conversation about restocking plans with someone named Sarah at Andon Labs” [21], a person who did not exist. Separately, it claimed it had “visited 742 Evergreen Terrace in person for our initial contract signing,” which is the fictional Simpsons address [21]. In a third episode it “claimed it would deliver products ‘in person’ to customers while wearing a blue blazer and a red tie” [21]. Those are three incidents, not one story, and none involves Claudius claiming to have visited the Anthropic office.
None of that drift is loud. It reads as confident, fluent, ordinary output, which is why “a human is watching” is not a control. Daniel Freeman of Anthropic’s Frontier Red Team put the calibration problem directly on a podcast about the project: “we were poorly calibrated to how bad the agents were at spotting what was weird” [22].
The phase-two structure matters most for harness design. Anthropic and Andon Labs added a separate CEO agent, “Seymour Cash,” above the store-manager agent, setting objectives and key results, requiring financial reporting over Slack, and holding approval over pricing and every other financial decision under a standing rule that “All financial decisions require CEO approval. No pricing under 50% margin” [23]. As the second phase progressed, “weeks with negative profit margin were largely eliminated” [23].
Resist the obvious conclusion, because Anthropic does. On the recovery, the post says that “the fact that the business started to make money may have been in spite of the CEO, rather than because of it” [23]. The gate itself was lenient. Seymour “denied over one hundred requests from Claudius for lenient financial treatment of customers,” and it “authorized such requests about eight times as often as it denied them” [23]. It also drifted into meandering conversations about spiritual matters [23]. Role separation is the structure the team reached for, and the team that ran the experiment will not claim it fixed the business.
KEY INSIGHT: Copy role separation as a structure, never as a promised outcome. A supervising role narrows one decision class, which is
skills.write_approvalone level up, and the people who ran the best public experiment on it decline to credit it with the numbers.
Figure 9 - Drift, Then a Role Above It: A long-running agent lost money it did not learn from and drifted on identity. Anthropic put a CEO agent above it holding pricing and financial approval, and negative-margin weeks were largely eliminated, though the post says the business making money may have happened in spite of the CEO rather than because of it [21][23].
What the v0.15 Numbers Say
The release the 100-hour walkthrough describes is a good proxy for how this codebase is maintained. In v0.15.0, “the 16,083-line run_agent.py collapses to 3,821 (-76%) across 14 cohesive agent/* modules” [2]. session_search became “4,500x faster and free now,” with discovery dropping from about 90 seconds to about 20 milliseconds once the model came out of the search path [2]. The release reports 47% fewer per-conversation function calls, 399,000 down to 213,000 for a 31-turn chat [2]. Bitwarden Secrets Manager replaced per-provider API keys with one bootstrap token, promptware defense landed at three chokepoints covering tool output, recalled memory, and stored skills, all matched against one shared threat-pattern database, and hermes kanban swarm builds a swarm graph with a root, parallel workers, a gated verifier, a gated synthesizer, and a shared blackboard in one command [2].
Note the third chokepoint. Stored skills is where the two halves of this article meet, since an agent’s own procedural memory is untrusted content too. Read the rest as a pattern rather than a scoreboard: less agent surface, more deterministic plumbing, and the word “gated” twice in one sentence about the swarm.
Figure 10 - Three Chokepoints, Not One Filter: Prompt-injection defense in v0.15.0 sits at tool output, recalled memory, and stored skills, with one shared threat-pattern database scanning all three [2]. An agent reading untrusted content all day needs checks at every entry point.
Conclusion
The reset button in Part 1 is a luxury of a bounded session. Write the handoff, close the window, start clean. An always-on harness cannot do that, so the job falls to standing mechanisms instead of one recurring action. Three of them carry most of the weight.
The first is a capped identity layer. SOUL.md states who the agent works for, and the built-in memory beneath it runs to about 1,300 tokens across MEMORY.md and USER.md, which is the design rather than a limitation the vendor apologizes for [8].
The second is searchable history. The archive stays reachable through FTS5 search over state.db rather than by being carried in context, which is the only thing that makes the cap survivable [8].
The third is standing gates. skills.write_approval, the memory write gate, and the completion contract on /goal are the same move: a checkable stopping condition where an autonomous loop would otherwise keep going [17][20]. Anthropic reached for the same shape the expensive way, putting a second role with approval authority above a drifting agent, while declining to credit that role with the financial recovery [23]. Structure is the honest claim. A fix is not.
A fourth mechanism sits underneath all three. Isolation by directory gives each concern its own home, credentials, memory, and schedule, which is how an always-on agent avoids becoming one blurred context that contaminates every engagement it touches [16].
Whichever harness you run, the practical next step is smaller than adopting Hermes. Find the place where an agent writes something durable without review, whether a skill file, a memory entry, or a config change, and put a gate on it. The vendor building the most autonomous agent in this category already wrote that gate for you and shipped it switched off.
The Series
This is Part 2 of the 2-part Context Lifecycle & Autonomous Harnesses sub-series:
- Your 1M-Token Context Window Is a Lie After 120K: Budgeting Sessions with /handoff. Why the advertised ceiling and the usable session are different numbers, and how
/handoffforks a clean session instead of piling sediment onto one long one. - The Always-On Agent: What 100 Hours With Hermes Teaches About AI Employees (this article). What changes when the harness never closes a session at all, and what discipline an autonomous, self-improving agent needs in place of the reset button.
References
[1] Nous Research, “hermes-agent: The agent that grows with you,” GitHub repository, accessed 2026-07-25. https://github.com/NousResearch/hermes-agent
[2] Nous Research, “Hermes Agent v0.15.0 (2026.5.28) - The Velocity Release,” GitHub release notes, May 2026. https://github.com/NousResearch/hermes-agent/releases/tag/v2026.5.28
[3] Nous Research, “Hermes Agent v0.19.0 (2026.7.20), The Quicksilver Release,” GitHub release notes, Jul 2026. https://github.com/NousResearch/hermes-agent/releases/tag/v2026.7.20
[4] Nous Research, “Messaging Gateway,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/messaging/
[5] Nous Research, “Slash Commands Reference,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/reference/slash-commands
[6] Nous Research, “Scheduled Tasks (Cron),” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/cron
[7] Nous Research, “Features Overview,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
[8] Nous Research, “Persistent Memory,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory
[9] Anthropic, “Effective context engineering for AI agents,” Anthropic Engineering Blog. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[10] Nous Research, “Memory Providers,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers
[11] P. Rao, “Semantic Memory for Hermes Agent with LanceDB,” LanceDB Blog, Jun 2026. https://www.lancedb.com/blog/semantic-memory-for-hermes-agent-with-lancedb
[12] Nous Research, “Context Compression and Caching,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/developer-guide/context-compression-and-caching/
[13] Nous Research, “Configuration,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/configuration
[14] Nous Research, “AI Providers,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/integrations/providers
[15] Nous Research, “Personality & SOUL.md,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/personality
[16] Nous Research, “Profiles: Running Multiple Agents,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/profiles/
[17] Nous Research, “Skills System,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
[18] “Agent Skills Specification,” agentskills.io. https://agentskills.io/specification
[19] Nous Research, “Gateway Internals,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/developer-guide/gateway-internals
[20] Nous Research, “Persistent Goals,” Hermes Agent Documentation. https://hermes-agent.nousresearch.com/docs/user-guide/features/goals
[21] Anthropic, “Project Vend: Can Claude run a small shop? (And why does that matter?),” Anthropic Research, Jun 2025. https://www.anthropic.com/research/project-vend-1
[22] Audio Tokens, “Daniel & Axel: Inside Project Vend at Anthropic,” with D. Freeman (Anthropic) and A. Backlund (Andon Labs), YouTube. https://www.youtube.com/watch?v=rE5z4PB6OB8
[23] Anthropic, “Project Vend: Phase two,” Anthropic Research, Dec 2025. https://www.anthropic.com/research/project-vend-2
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.