Hermes-Wiki: a source-verified documentation set for the Hermes agent

What a wiki of source-verified pages is actually for

The README describes Hermes-Wiki as deep architecture documentation based on the Nous Research Hermes Agent source code, and states that every page has been verified line by line against that source. That claim is the whole product. The repository is a Markdown knowledge base, not a library, not a CLI, not a plugin. There is no build step described, no runtime, and no code to import. If you want to know what Hermes does when it assembles a prompt or dispatches a tool call, this is a reading aid. If you want to install Hermes, this is the wrong document, because nothing in the supplied material covers installation.

The audience is narrow and identifiable: people who have the hermes-agent tree open in another window. The badge row advertises 46 knowledge base pages and 50 changelogs, which tells you the author treats release history as part of the architecture, not as an afterthought. The changelog entries are dated and commit-pinned, for example the 2026-06-21 update describing a single-day sync of 179 commits moving hermes-agent from 5a53e0f0 to 87ab373. That is a maintenance posture, not a one-off writeup.

How the pages are organised and how the source is cited

The table of contents is grouped by subsystem rather than by file. Core architecture covers the agent loop and prompt assembly, the tool registry, model-tools dispatch, the toolsets system, the prompt builder, the auxiliary client router, provider transport, and the provider plugin system. Memory and sessions covers the three-layer memory architecture, session search over SQLite FTS5, the context compressor, and the skills system. Tools and capabilities covers browser automation, web tools, the code execution sandbox, voice mode, context references, fuzzy matching, large tool result handling, LSP integration, and i18n. Performance, security, multi-agent, and platform sections follow the same pattern.

The citation style is the part worth copying. Entries name concrete symbols and line ranges, for instance `agent/context_compressor.py:1935-1950 _effective_protect_first_n()` and `hermes_cli/goals.py:282 migrate_goal_to_session`. A reader can jump straight to the function. The README also records removals rather than quietly dropping them, noting that the `web_crawl` tool was removed on 2026-05-29 under issue 33824. Documentation that tracks deletions is more trustworthy than documentation that only tracks additions, because deletions are where stale pages usually hide.

The architecture the wiki describes, in outline

From the page titles alone, the Hermes agent is a layered system. A central tool registry registers tools declaratively and dispatches them through a single path, with an async bridge, dynamic schema adjustment and argument type coercion handled in the model-tools dispatch layer. Tools are grouped into toolsets that resolve recursively, and the README claims more than 20 platform toolsets. System prompts are assembled modularly by a prompt builder that injects guard text, caches skills and adds model-specific guidance.

Below that sits a provider abstraction. A Provider Transport ABC normalises Anthropic, Chat Completions, Responses API and Bedrock data paths, and since v0.13.0 a ProviderProfile ABC with roughly 30 plugin providers sits on top. Memory is three layers: MemoryStore, MemoryManager and MemoryProvider, with a frozen snapshot pattern that the prompt caching page ties to prefix cache preservation and a stated 75 percent cost saving. Context compression runs as a separate subsystem with its own rotation and protection logic. None of this is verifiable from the wiki alone, but the file and symbol references make it checkable against the upstream tree.

Changelogs as first-class content, and the cost of that choice

Fifty changelog pages, newest first, is an unusual amount of release history for a documentation repository. The 2026-06-21 entry is dense: 179 commits in a roughly 26-hour window, about 70 fixes, 16 features, 13 tests, 6 chores, 16 documentation changes and 23 merges, touching 266 files with +17145 and minus 1079 lines. It then breaks out a nine-commit compression cluster and names individual commits. This is the single most useful part of the repository for anyone tracking upstream, because it converts a commit stream into named clusters.

It is also the part that decays fastest. A page describing the agent loop can stay roughly correct for months. A changelog pinned to a commit hash is only accurate for that hash. The README pins the documented version at v0.17.0 (87ab373) and notes that v0.17.0 was a maintenance release with no new version published, which means the wiki is tracking a branch state rather than a tagged release. Budget for the wiki being behind the upstream default branch between syncs.

Getting it running, and what that phrase even means here

There is no install command in the supplied material. The repository is Markdown, and the README's badge references Obsidian, which suggests the intended reading experience is an Obsidian vault or any Markdown viewer that follows relative links. Practically that means cloning the repository and opening the folder, or reading the files directly on the hosting site. The entry point is `index.md`, which the README names as the full changelog list, and the concept pages live under `concepts/` with filenames such as `agent-loop-and-prompt-assembly.md`, `tool-registry-architecture.md` and `memory-system-architecture.md`. Changelog pages live under `changelog/`.

Because there are no config keys, no environment variables and no CLI flags documented in this repository, anyone expecting a setup section will not find one. The commands you need belong to the hermes-agent project, not to this wiki. That is worth stating plainly rather than dressing up: the only operational instruction this repository supports is opening its own files.

Where this documentation stops being enough

The wiki is a secondary source. Every page is a human reading of someone else's code, and the README's line-by-line verification claim is the author's assertion, not something a reader can confirm without repeating the work. Line numbers are the sharpest failure mode. A citation like `agent/auxiliary_client.py:121` is correct for one commit and misleading for the next, and the changelog entry itself shows files churning by thousands of lines in a day. If you cite a line range from this wiki in a bug report against a newer commit, expect it to be wrong.

The second gap is scope. The README explicitly limits i18n to a thin slice covering Hermes's own static messages and says agent output is untouched. That kind of scoping note is honest, but it also tells you the wiki documents what the author chose to document. There is no stated coverage guarantee, no index of undocumented subsystems, and no indication of what happens when a concept page falls behind. Treat absence of a page as absence of information, not as absence of the feature.

Alternatives and the difference in approach

The obvious alternative is the hermes-agent repository itself: its source, its own documentation and its commit history. The difference is effort and framing. Upstream gives you ground truth with no interpretation and no grouping, so reconstructing how the tool registry, toolsets and dispatch layer interact means reading across many files. Hermes-Wiki gives you the grouping and the named symbols, at the cost of being a snapshot. A second alternative is a general-purpose code intelligence tool that indexes the repository and answers questions on demand. That approach stays current automatically but produces answers with no persistent structure, no curated changelog clusters and nothing you can read end to end before starting work.

A third option, for teams that only need the public surface, is the upstream README and release notes. That is lighter than a 46-page wiki if your questions are about features rather than internals. The wiki earns its place only when your questions are about internals: which layer coerces argument types, where the frozen memory snapshot is taken, how the provider transport normalises four different API shapes.

Licence, maintenance and what to check before relying on it

The README carries an MIT licence badge. The repository metadata supplied here lists no licence, so the badge is the only signal available and it should be confirmed in the repository's licence file before you redistribute or vendor any of the text. Even under MIT, this is documentation about a separate project, and the upstream hermes-agent licence governs the code the pages describe. Nothing here is legal advice; check both licences if you plan to reuse the prose.

Maintenance cost falls on the reader in a specific way. The wiki is only as fresh as its last sync, and the 2026-06-21 entry shows what a sync involves: 179 commits triaged into fix, feature, test, chore, documentation and merge buckets, with named clusters. That is real editorial work, and it is the reason the changelog section is worth reading while the concept pages are worth trusting cautiously. Before adopting it as a reference, open the concept page you need, check the commit it was written against, and confirm the cited file paths still exist at that location in your checkout. If they do not, you are reading history, not architecture.

Editorial conclusion

Adopt Hermes-Wiki if you are reading the hermes-agent source and need the agent loop, tool registry, memory layers or provider transport mapped before you touch code, and if you accept that the pages track a moving target pinned in the README at v0.17.0 (87ab373). Do not adopt it as an end-user manual for installing or configuring Hermes, and do not treat it as a substitute for the upstream repository when behaviour matters. Verify first that the concept page you need exists for your version, that its cited file paths and line ranges still match the commit you have checked out, and that the MIT badge in the README is the licence you are relying on, since the repository metadata itself lists no licence.

Official sources

1. cclank/Hermes-Wiki on GitHub
2. Issues
3. README