# The Hermes Bible — Generated Local Knowledge Base This local clone does not vendor the full upstream article bodies. It provides a generated one-page knowledge base for all 170 docs and 25 flows using local summaries, metadata, outlines, implementation notes, decision tables, verification checklists, risk notes, and source links. For the upstream verbatim full-text export, use https://www.hermesbible.com/llms-full.txt. Source index: https://agentguide.net/hermes/llms.txt --- # Documentation # Getting Started ## Installation | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/getting-started/installation/ | | Source | https://hermesbible.com/docs/getting-started/installation | | Section | Getting Started | ### Summary Get Hermes Agent up and running in under two minutes! Quick Install With the Hermes Desktop installer on macOS or Windows (recommended) To easily install the co ### Source outline - Quick Install - With the Hermes Desktop installer on macOS or Windows (recommended) - Without Hermes Desktop: - Linux / macOS / WSL2 / Android (Termux) - Windows (native) - What the Installer Does - Install Layout - After Installation - Prerequisites - Manual / Developer Installation - Non-Sudo / System Service User Installs - Troubleshooting - Install method auto-detection ### Section map ### Quick Install Maps quick install to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### With the Hermes Desktop installer on macOS or Windows (recommended) Maps with the hermes desktop installer on macos or windows (recommended) to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Without Hermes Desktop: Maps without hermes desktop: to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### What the Installer Does Maps what the installer does to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### After Installation Maps after installation to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Manual / Developer Installation Maps manual / developer installation to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Non-Sudo / System Service User Installs Maps non-sudo / system service user installs to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Getting Started doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick Install, With the Hermes Desktop installer on macOS or Windows (recommended), Without Hermes Desktop:, What the Installer Does, After Installation. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: installation, running, under, minutes, quick. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Getting Started documentation | Use when you need orientation for installation before applying exact upstream commands. | | Verify first | Quick Install | Open the source anchor for Quick Install and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Getting Started, then open the linked source page for exact current syntax. - Start with the source section for Quick Install; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for With the Hermes Desktop installer on macOS or Windows (recommended) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Quickstart | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/getting-started/quickstart/ | | Source | https://hermesbible.com/docs/getting-started/quickstart | | Section | Getting Started | ### Summary This guide gets you from zero to a working Hermes setup that survives real use. Install, choose a provider, verify a working chat, and know exactly what to do w ### Source outline - Prefer to watch? - Who this is for - The fastest path - 1. Install Hermes Agent - With the Hermes Desktop installer on macOS or Windows (recommended) - Without Hermes Desktop: - Linux / macOS / WSL2 / Android (Termux) - Windows (native) - 2. Choose a Provider - How settings are stored - 3. Run Your First Chat - 4. Verify Sessions Work - 5. Try Key Features - Use the terminal ### Section map ### Prefer to watch? Maps prefer to watch? to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Who this is for Maps who this is for to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### The fastest path Maps the fastest path to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### 1. Install Hermes Agent Maps 1. install hermes agent to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### With the Hermes Desktop installer on macOS or Windows (recommended) Maps with the hermes desktop installer on macos or windows (recommended) to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Without Hermes Desktop: Maps without hermes desktop: to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### 2. Choose a Provider Maps 2. choose a provider to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### How settings are stored Maps how settings are stored to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Getting Started doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prefer to watch?, Who this is for, The fastest path, 1. Install Hermes Agent, With the Hermes Desktop installer on macOS or Windows (recommended). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: quickstart, working, setup, survives, install. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Getting Started documentation | Use when you need orientation for quickstart before applying exact upstream commands. | | Verify first | Prefer to watch? | Open the source anchor for Prefer to watch? and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Getting Started, then open the linked source page for exact current syntax. - Start with the source section for Prefer to watch?; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Who this is for if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Learning Path | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/getting-started/learning-path/ | | Source | https://hermesbible.com/docs/getting-started/learning-path | | Section | Getting Started | ### Summary Hermes Agent can do a lot — CLI assistant, Telegram/Discord bot, task automation, RL training, and more. This page helps you figure out where to start and what ### Source outline - How to Use This Page - By Experience Level - By Use Case - "I want a CLI coding assistant" - "I want a Telegram/Discord bot" - "I want to automate tasks" - "I want to build custom tools/skills" - "I want to train models" - "I want to use it as a Python library" - Key Features at a Glance - What to Read Next ### Section map ### How to Use This Page Maps how to use this page to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### By Experience Level Maps by experience level to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### By Use Case Maps by use case to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### "I want a CLI coding assistant" Maps "i want a cli coding assistant" to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### "I want a Telegram/Discord bot" Maps "i want a telegram/discord bot" to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### "I want to automate tasks" Maps "i want to automate tasks" to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### "I want to build custom tools/skills" Maps "i want to build custom tools/skills" to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### "I want to train models" Maps "i want to train models" to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Getting Started doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How to Use This Page, By Experience Level, By Use Case, "I want a CLI coding assistant", "I want a Telegram/Discord bot". Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: learning, assistant, telegram/discord, automation, training. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Getting Started documentation | Use when you need orientation for learning path before applying exact upstream commands. | | Verify first | How to Use This Page | Open the source anchor for How to Use This Page and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Getting Started, then open the linked source page for exact current syntax. - Start with the source section for How to Use This Page; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for By Experience Level if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Updating & Uninstalling | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/getting-started/updating/ | | Source | https://hermesbible.com/docs/getting-started/updating | | Section | Getting Started | ### Summary Updating Git installs Update to the latest version with a single command: This pulls the latest code from , updates dependencies, and prompts you to configure a ### Source outline - Updating - Git installs - pip installs - What happens during an update (git installs) - Updating against a non-default branch: --branch - Local changes on non-interactive updates - Preview-only: hermes update --check - Full pre-update backup: --backup - Windows: another hermes.exe is running - Recommended Post-Update Validation - If your terminal disconnects mid-update - Checking your current version - Updating from Messaging Platforms - Manual Update ### Section map ### Updating Maps updating to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Git installs Maps git installs to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### pip installs Maps pip installs to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### What happens during an update (git installs) Maps what happens during an update (git installs) to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Updating against a non-default branch: --branch Maps updating against a non-default branch: --branch to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Local changes on non-interactive updates Maps local changes on non-interactive updates to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Preview-only: hermes update --check Maps preview-only: hermes update --check to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Full pre-update backup: --backup Maps full pre-update backup: --backup to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Getting Started doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Updating, Git installs, pip installs, What happens during an update (git installs), Updating against a non-default branch: --branch. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: updating, uninstalling, installs, update, latest. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Getting Started documentation | Use when you need orientation for updating & uninstalling before applying exact upstream commands. | | Verify first | Updating | Open the source anchor for Updating and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Getting Started, then open the linked source page for exact current syntax. - Start with the source section for Updating; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Git installs if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Android / Termux | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/getting-started/termux/ | | Source | https://hermesbible.com/docs/getting-started/termux | | Section | Getting Started | ### Summary Hermes on Android with Termux This is the tested path for running Hermes Agent directly on an Android phone through Termux. It gives you a working local CLI on ### Source outline - What is supported in the tested path? - What is not part of the tested path yet? - Option 1: One-line installer - Option 2: Manual install (fully explicit) - 1. Update Termux and install system packages - 2. Clone Hermes - 3. Create a virtual environment - 4. Install the tested Termux bundle - 5. Put hermes on your Termux PATH - 6. Verify the install - 7. Start Hermes - Recommended follow-up setup - Configure a model - Re-run the full interactive setup wizard later ### Section map ### What is supported in the tested path? Maps what is supported in the tested path? to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### What is not part of the tested path yet? Maps what is not part of the tested path yet? to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Option 1: One-line installer Maps option 1: one-line installer to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Option 2: Manual install (fully explicit) Maps option 2: manual install (fully explicit) to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### 1. Update Termux and install system packages Maps 1. update termux and install system packages to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### 2. Clone Hermes Maps 2. clone hermes to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### 3. Create a virtual environment Maps 3. create a virtual environment to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### 4. Install the tested Termux bundle Maps 4. install the tested termux bundle to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Getting Started doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What is supported in the tested path?, What is not part of the tested path yet?, Option 1: One-line installer, Option 2: Manual install (fully explicit), 1. Update Termux and install system packages. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: android, termux, tested, running, directly. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Getting Started documentation | Use when you need orientation for android / termux before applying exact upstream commands. | | Verify first | What is supported in the tested path? | Open the source anchor for What is supported in the tested path? and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Getting Started, then open the linked source page for exact current syntax. - Start with the source section for What is supported in the tested path?; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What is not part of the tested path yet? if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Nix & NixOS Setup | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/getting-started/nix-setup/ | | Source | https://hermesbible.com/docs/getting-started/nix-setup | | Section | Getting Started | ### Summary Hermes Agent ships a Nix flake with three levels of integration: Level Who it's for What you get / Any Nix user (macOS, Linux) Pre built binary with all deps — ### Source outline - Prerequisites - Quick Start (Any Nix User) - NixOS Module - Add the Flake Input - Minimal Configuration - Container-aware CLI - Verify It Works - Choosing a Deployment Mode - Configuration - Declarative Settings - Escape Hatch: Bring Your Own Config - Customization Cheatsheet - Secrets Management - sops-nix ### Section map ### Prerequisites Maps prerequisites to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Quick Start (Any Nix User) Maps quick start (any nix user) to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### NixOS Module Maps nixos module to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Add the Flake Input Maps add the flake input to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Minimal Configuration Maps minimal configuration to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Container-aware CLI Maps container-aware cli to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Verify It Works Maps verify it works to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Choosing a Deployment Mode Maps choosing a deployment mode to the Getting Started documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Getting Started doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Quick Start (Any Nix User), NixOS Module, Add the Flake Input, Minimal Configuration. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: nixos, setup, ships, flake, three. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Getting Started documentation | Use when you need orientation for nix & nixos setup before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Getting Started, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start (Any Nix User) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Core Features ## Features Overview | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/overview/ | | Source | https://hermesbible.com/docs/user-guide/features/overview | | Section | Core Features | ### Summary Hermes Agent includes a rich set of capabilities that extend far beyond basic chat. From persistent memory and file aware context to browser automation and voic ### Source outline - Core - Automation - Media & Web - Integrations - Customization ### Section map ### Core Maps core to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Automation Maps automation to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Media & Web Maps media & web to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Integrations Maps integrations to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Customization Maps customization to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Core, Automation, Media & Web, Integrations, Customization. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: features, overview, includes, capabilities, extend. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for features overview before applying exact upstream commands. | | Verify first | Core | Open the source anchor for Core and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Core; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Automation if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Tools & Toolsets | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/tools/ | | Source | https://hermesbible.com/docs/user-guide/features/tools | | Section | Core Features | ### Summary Tools are functions that extend the agent's capabilities. They're organized into logical toolsets that can be enabled or disabled per platform. Available Tools ### Source outline - Available Tools - Using Toolsets - Terminal Backends - Configuration - Docker Backend - SSH Backend - Singularity/Apptainer - Modal (Serverless Cloud) - Container Resources - Container Security - Background Process Management - Sudo Support ### Section map ### Available Tools Maps available tools to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Using Toolsets Maps using toolsets to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Terminal Backends Maps terminal backends to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Docker Backend Maps docker backend to the Core Features documentation path, with the source page reserved for exact commands and updates. ### SSH Backend Maps ssh backend to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Singularity/Apptainer Maps singularity/apptainer to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Modal (Serverless Cloud) Maps modal (serverless cloud) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Available Tools, Using Toolsets, Terminal Backends, Configuration, Docker Backend. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: tools, toolsets, functions, extend, capabilities.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for tools & toolsets before applying exact upstream commands. | | Verify first | Available Tools | Open the source anchor for Available Tools and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Available Tools; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Using Toolsets if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Skills System | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/skills/ | | Source | https://hermesbible.com/docs/user-guide/features/skills | | Section | Core Features | ### Summary Skills are on demand knowledge documents the agent can load when needed. They follow a progressive disclosure pattern to minimize token usage and are compatible ### Source outline - Starting with a blank slate - Using Skills - Progressive Disclosure - SKILL.md Format - When to Use - Procedure - Pitfalls - Verification - Platform-Specific Skills - Skill output and media delivery - Forcing document-style delivery: [[as_document]] - Conditional Activation (Fallback Skills) - Secure Setup on Load - Skill Config Settings ### Section map ### Starting with a blank slate Maps starting with a blank slate to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Using Skills Maps using skills to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Progressive Disclosure Maps progressive disclosure to the Core Features documentation path, with the source page reserved for exact commands and updates. ### SKILL.md Format Maps skill.md format to the Core Features documentation path, with the source page reserved for exact commands and updates. ### When to Use Maps when to use to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Procedure Maps procedure to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Pitfalls Maps pitfalls to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Verification Maps verification to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Starting with a blank slate, Using Skills, Progressive Disclosure, SKILL.md Format, When to Use. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: skills, system, demand, knowledge, documents. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for skills system before applying exact upstream commands. | | Verify first | Starting with a blank slate | Open the source anchor for Starting with a blank slate and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Starting with a blank slate; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Using Skills if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Curator | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/curator/ | | Source | https://hermesbible.com/docs/user-guide/features/curator | | Section | Core Features | ### Summary The curator is a background maintenance pass for agent created skills . It tracks how often each skill is viewed, used, and patched, moves long unused skills th ### Source outline - How it runs - Configuration - Running the review on a cheaper aux model - CLI - Backups and rollback - What "agent-created" means - Pinning a skill - Usage telemetry - Per-run reports - Rename map in the summary - Restoring an archived skill - Disabling per environment - See also ### Section map ### How it runs Maps how it runs to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Running the review on a cheaper aux model Maps running the review on a cheaper aux model to the Core Features documentation path, with the source page reserved for exact commands and updates. ### CLI Maps cli to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Backups and rollback Maps backups and rollback to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What "agent-created" means Maps what "agent-created" means to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Pinning a skill Maps pinning a skill to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Usage telemetry Maps usage telemetry to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How it runs, Configuration, Running the review on a cheaper aux model, CLI, Backups and rollback. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: curator, background, maintenance, created, skills. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for curator before applying exact upstream commands. | | Verify first | How it runs | Open the source anchor for How it runs and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How it runs; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Configuration if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Persistent Memory | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/memory/ | | Source | https://hermesbible.com/docs/user-guide/features/memory | | Section | Core Features | ### Summary Hermes Agent has bounded, curated memory that persists across sessions. This lets it remember your preferences, your projects, your environment, and things it h ### Source outline - How It Works - How Memory Appears in the System Prompt - Memory Tool Actions - Substring Matching - Two Targets Explained - memory — Agent's Personal Notes - user — User Profile - What to Save vs Skip - Save These (Proactively) - Skip These - Capacity Management - What Happens When Memory is Full - Practical Examples of Good Memory Entries - Duplicate Prevention ### Section map ### How It Works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### How Memory Appears in the System Prompt Maps how memory appears in the system prompt to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Memory Tool Actions Maps memory tool actions to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Substring Matching Maps substring matching to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Two Targets Explained Maps two targets explained to the Core Features documentation path, with the source page reserved for exact commands and updates. ### memory — Agent's Personal Notes Maps memory — agent's personal notes to the Core Features documentation path, with the source page reserved for exact commands and updates. ### user — User Profile Maps user — user profile to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What to Save vs Skip Maps what to save vs skip to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How It Works, How Memory Appears in the System Prompt, Memory Tool Actions, Substring Matching, Two Targets Explained. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: persistent, memory, bounded, curated, persists. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for persistent memory before applying exact upstream commands. | | Verify first | How It Works | Open the source anchor for How It Works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How It Works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for How Memory Appears in the System Prompt if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Memory Providers | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/memory-providers/ | | Source | https://hermesbible.com/docs/user-guide/features/memory-providers | | Section | Core Features | ### Summary Hermes Agent ships with 8 external memory provider plugins that give the agent persistent, cross session knowledge beyond the built in MEMORY.md and USER.md. On ### Source outline - Quick Start - How It Works - Available Providers - Honcho - New profile, fresh Honcho peer - Existing profiles, backfill Honcho peers - Per-profile observation - Gateway identity mapping - OpenViking - Mem0 - Hindsight - Holographic - RetainDB - ByteRover ### Section map ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### How It Works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Available Providers Maps available providers to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Honcho Maps honcho to the Core Features documentation path, with the source page reserved for exact commands and updates. ### New profile, fresh Honcho peer Maps new profile, fresh honcho peer to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Existing profiles, backfill Honcho peers Maps existing profiles, backfill honcho peers to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Per-profile observation Maps per-profile observation to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Gateway identity mapping Maps gateway identity mapping to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick Start, How It Works, Available Providers, Honcho, New profile, fresh Honcho peer. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: memory, providers, ships, external, provider. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for memory providers before applying exact upstream commands. | | Verify first | Quick Start | Open the source anchor for Quick Start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Quick Start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for How It Works if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Context Files | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/context-files/ | | Source | https://hermesbible.com/docs/user-guide/features/context-files | | Section | Core Features | ### Summary Hermes Agent automatically discovers and loads context files that shape how it behaves. Some are project local and discovered from your working directory. is no ### Source outline - Supported Context Files - AGENTS.md - Progressive Subdirectory Discovery - Example AGENTS.md - Architecture - Conventions - Important Notes - SOUL.md - .cursorrules - How Context Files Are Loaded - At startup (system prompt) - During the session (progressive discovery) - AGENTS.md - .cursorrules ### Section map ### Supported Context Files Maps supported context files to the Core Features documentation path, with the source page reserved for exact commands and updates. ### AGENTS.md Maps agents.md to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Progressive Subdirectory Discovery Maps progressive subdirectory discovery to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Example AGENTS.md Maps example agents.md to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Architecture Maps architecture to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Conventions Maps conventions to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Important Notes Maps important notes to the Core Features documentation path, with the source page reserved for exact commands and updates. ### SOUL.md Maps soul.md to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Supported Context Files, AGENTS.md, Progressive Subdirectory Discovery, Example AGENTS.md, Architecture. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: context, files, automatically, discovers, loads. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for context files before applying exact upstream commands. | | Verify first | Supported Context Files | Open the source anchor for Supported Context Files and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Supported Context Files; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for AGENTS.md if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Context References | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/context-references/ | | Source | https://hermesbible.com/docs/user-guide/features/context-references | | Section | Core Features | ### Summary Type followed by a reference to inject content directly into your message. Hermes expands the reference inline and appends the content under an section. Support ### Source outline - Supported References - Usage Examples - CLI Tab Completion - Line Ranges - Size Limits - Security - Sensitive Path Blocking - Path Traversal Protection - Binary File Detection - Platform Availability - Interaction with Context Compression - Common Patterns - Error Handling ### Section map ### Supported References Maps supported references to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Usage Examples Maps usage examples to the Core Features documentation path, with the source page reserved for exact commands and updates. ### CLI Tab Completion Maps cli tab completion to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Line Ranges Maps line ranges to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Size Limits Maps size limits to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Security Maps security to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Sensitive Path Blocking Maps sensitive path blocking to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Path Traversal Protection Maps path traversal protection to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Supported References, Usage Examples, CLI Tab Completion, Line Ranges, Size Limits. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: context, references, followed, reference, inject. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for context references before applying exact upstream commands. | | Verify first | Supported References | Open the source anchor for Supported References and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Supported References; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Usage Examples if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## How SOUL.md works now | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/personality/ | | Source | https://hermesbible.com/docs/user-guide/features/personality | | Section | Core Features | ### Summary Hermes Agent's personality is fully customizable. is the primary identity — it's the first thing in the system prompt and defines who the agent is. — a durable ### Source outline - How SOUL.md works now - Important behavior - Why this design - Where to edit it - What should go in SOUL.md? - Good SOUL.md content - Example - Style - What to avoid - Technical posture - What Hermes injects into the prompt - Security scanning - SOUL.md vs AGENTS.md - SOUL.md ### Section map ### How SOUL.md works now Maps how soul.md works now to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Important behavior Maps important behavior to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Why this design Maps why this design to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Where to edit it Maps where to edit it to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What should go in SOUL.md? Maps what should go in soul.md? to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Good SOUL.md content Maps good soul.md content to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Example Maps example to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Style Maps style to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How SOUL.md works now, Important behavior, Why this design, Where to edit it, What should go in SOUL.md?. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: soul.md, works, personality, fully, customizable.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for how soul.md works now before applying exact upstream commands. | | Verify first | How SOUL.md works now | Open the source anchor for How SOUL.md works now and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How SOUL.md works now; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Important behavior if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/plugins/ | | Source | https://hermesbible.com/docs/user-guide/features/plugins | | Section | Core Features | ### Summary Hermes has a plugin system for adding custom tools, hooks, and integrations without modifying core code. If you want to create a custom tool for yourself, your ### Source outline - Quick overview - Minimal working example - What plugins can do - Plugin discovery - Plugin sub-categories - Plugins are opt-in (with a few exceptions) - What the allow-list does NOT gate - Migration for existing users - Available hooks - Plugin types - Pluggable interfaces — where to go for each - NixOS declarative plugins - Managing plugins - Interactive UI ### Section map ### Quick overview Maps quick overview to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Minimal working example Maps minimal working example to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What plugins can do Maps what plugins can do to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Plugin discovery Maps plugin discovery to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Plugin sub-categories Maps plugin sub-categories to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Plugins are opt-in (with a few exceptions) Maps plugins are opt-in (with a few exceptions) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What the allow-list does NOT gate Maps what the allow-list does not gate to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Migration for existing users Maps migration for existing users to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick overview, Minimal working example, What plugins can do, Plugin discovery, Plugin sub-categories. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: plugins, plugin, system, adding, custom. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for plugins before applying exact upstream commands. | | Verify first | Quick overview | Open the source anchor for Quick overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Quick overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Minimal working example if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Source authority | Use the upstream source page for exact current behavior before applying configuration changes. | --- ## Built-in Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/built-in-plugins/ | | Source | https://hermesbible.com/docs/user-guide/features/built-in-plugins | | Section | Core Features | ### Summary Hermes ships a small set of plugins bundled with the repository. They live under and load automatically alongside user installed plugins in . They use the same ### Source outline - How discovery works - Bundled plugins are opt-in - Currently shipped - disk-cleanup - security-guidance - observability/langfuse - google_meet - hermes-achievements - Adding a bundled plugin ### Section map ### How discovery works Maps how discovery works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Bundled plugins are opt-in Maps bundled plugins are opt-in to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Currently shipped Maps currently shipped to the Core Features documentation path, with the source page reserved for exact commands and updates. ### disk-cleanup Maps disk-cleanup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### security-guidance Maps security-guidance to the Core Features documentation path, with the source page reserved for exact commands and updates. ### observability/langfuse Maps observability/langfuse to the Core Features documentation path, with the source page reserved for exact commands and updates. ### google_meet Maps google_meet to the Core Features documentation path, with the source page reserved for exact commands and updates. ### hermes-achievements Maps hermes-achievements to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How discovery works, Bundled plugins are opt-in, Currently shipped, disk-cleanup, security-guidance. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: built-in, plugins, ships, small, bundled. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for built-in plugins before applying exact upstream commands. | | Verify first | How discovery works | Open the source anchor for How discovery works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How discovery works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Bundled plugins are opt-in if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Source authority | Use the upstream source page for exact current behavior before applying configuration changes. | --- ## Scheduled Tasks (Cron) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/cron/ | | Source | https://hermesbible.com/docs/user-guide/features/cron | | Section | Core Features | ### Summary Schedule tasks to run automatically with natural language or cron expressions. Hermes exposes cron management through a single tool with action style operations ### Source outline - What cron can do now - Creating scheduled tasks - In chat with /cron - From the standalone CLI - Through natural conversation - Skill-backed cron jobs - Single skill - Multiple skills - Running a job inside a project directory - Editing jobs - Chat - Standalone CLI - Lifecycle actions - Chat ### Section map ### What cron can do now Maps what cron can do now to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Creating scheduled tasks Maps creating scheduled tasks to the Core Features documentation path, with the source page reserved for exact commands and updates. ### In chat with /cron Maps in chat with /cron to the Core Features documentation path, with the source page reserved for exact commands and updates. ### From the standalone CLI Maps from the standalone cli to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Through natural conversation Maps through natural conversation to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Skill-backed cron jobs Maps skill-backed cron jobs to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Single skill Maps single skill to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Multiple skills Maps multiple skills to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What cron can do now, Creating scheduled tasks, In chat with /cron, From the standalone CLI, Through natural conversation. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: scheduled, tasks, schedule, automatically, natural. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for scheduled tasks (cron) before applying exact upstream commands. | | Verify first | What cron can do now | Open the source anchor for What cron can do now and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for What cron can do now; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Creating scheduled tasks if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Subagent Delegation | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/delegation/ | | Source | https://hermesbible.com/docs/user-guide/features/delegation | | Section | Core Features | ### Summary The tool spawns child AIAgent instances with isolated context, restricted toolsets, and their own terminal sessions. Each child gets a fresh conversation and wo ### Source outline - Single Task - Parallel Batch - How Subagent Context Works - Practical Examples - Parallel Research - Code Review + Fix - Multi-File Refactoring - Batch Mode Details - Model Override - Toolset Selection Tips - Max Iterations - Child Timeout - Monitoring Running Subagents (/agents) - Depth Limit and Nested Orchestration ### Section map ### Single Task Maps single task to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Parallel Batch Maps parallel batch to the Core Features documentation path, with the source page reserved for exact commands and updates. ### How Subagent Context Works Maps how subagent context works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Practical Examples Maps practical examples to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Parallel Research Maps parallel research to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Code Review + Fix Maps code review + fix to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Multi-File Refactoring Maps multi-file refactoring to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Batch Mode Details Maps batch mode details to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Single Task, Parallel Batch, How Subagent Context Works, Practical Examples, Parallel Research. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: subagent, delegation, spawns, child, aiagent. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for subagent delegation before applying exact upstream commands. | | Verify first | Single Task | Open the source anchor for Single Task and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Single Task; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Parallel Batch if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Kanban (Multi-Agent Board) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/kanban/ | | Source | https://hermesbible.com/docs/user-guide/features/kanban | | Section | Core Features | ### Summary Kanban — Multi Agent Profile Collaboration Want a walkthrough? Read the Kanban tutorial — four user stories (solo dev, fleet farming, role pipeline with retry, ### Source outline - Two surfaces: the model talks through tools, you talk through the CLI - Kanban vs. delegate_task - Core concepts - Boards (multi-project) - Managing boards from the CLI - Managing boards from the dashboard - File attachments - Quick start - Gateway-embedded dispatcher (default) - Idempotent create (for automation / webhooks) - Bulk CLI verbs - How workers interact with the board - Why tools instead of shelling to hermes kanban - Recommended handoff evidence ### Section map ### Two surfaces: the model talks through tools, you talk through the CLI Maps two surfaces: the model talks through tools, you talk through the cli to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Kanban vs. delegate_task Maps kanban vs. delegate_task to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Core concepts Maps core concepts to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Boards (multi-project) Maps boards (multi-project) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Managing boards from the CLI Maps managing boards from the cli to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Managing boards from the dashboard Maps managing boards from the dashboard to the Core Features documentation path, with the source page reserved for exact commands and updates. ### File attachments Maps file attachments to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Two surfaces: the model talks through tools, you talk through the CLI, Kanban vs. delegate_task, Core concepts, Boards (multi-project), Managing boards from the CLI. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: kanban, multi-agent, board, multi, profile. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for kanban (multi-agent board) before applying exact upstream commands. | | Verify first | Two surfaces: the model talks through tools, you talk through the CLI | Open the source anchor for Two surfaces: the model talks through tools, you talk through the CLI and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Two surfaces: the model talks through tools, you talk through the CLI; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Kanban vs. delegate_task if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Kanban tutorial | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/kanban-tutorial/ | | Source | https://hermesbible.com/docs/user-guide/features/kanban-tutorial | | Section | Core Features | ### Summary Kanban tutorial A walkthrough of the four use cases the Hermes Kanban system was designed for, with the dashboard open in a browser. If you haven't read the Kan ### Source outline - Setup - The board at a glance - Flat view - Story 1 — Solo dev shipping a feature - Story 2 — Fleet farming - Story 3 — Role pipeline with retry - Story 4 — Circuit breaker and crash recovery - Circuit breaker — permanent-looking failure - Crash recovery — worker dies mid-flight - Structured handoff — why summary and metadata matter - Inspecting a task currently running - Next steps ### Section map ### Setup Maps setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### The board at a glance Maps the board at a glance to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Flat view Maps flat view to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Story 1 — Solo dev shipping a feature Maps story 1 — solo dev shipping a feature to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Story 2 — Fleet farming Maps story 2 — fleet farming to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Story 3 — Role pipeline with retry Maps story 3 — role pipeline with retry to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Story 4 — Circuit breaker and crash recovery Maps story 4 — circuit breaker and crash recovery to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Circuit breaker — permanent-looking failure Maps circuit breaker — permanent-looking failure to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Setup, The board at a glance, Flat view, Story 1 — Solo dev shipping a feature, Story 2 — Fleet farming. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: kanban, tutorial, walkthrough, cases, system. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for kanban tutorial before applying exact upstream commands. | | Verify first | Setup | Open the source anchor for Setup and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Setup; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for The board at a glance if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Persistent Goals | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/goals/ | | Source | https://hermesbible.com/docs/user-guide/features/goals | | Section | Core Features | ### Summary Persistent Goals ( ) gives Hermes a standing objective that survives across turns. After every turn a lightweight judge model checks whether the goal is satisfi ### Source outline - When to use it - Quick start - Commands - Adding criteria mid-goal: /subgoal - Behavior details - The judge - Fail-open semantics - Turn budget - User messages always preempt - Mid-run safety (gateway) - Persistence - Prompt cache - Configuration - Choosing the judge model ### Section map ### When to use it Maps when to use it to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Commands Maps commands to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Adding criteria mid-goal: /subgoal Maps adding criteria mid-goal: /subgoal to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Behavior details Maps behavior details to the Core Features documentation path, with the source page reserved for exact commands and updates. ### The judge Maps the judge to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Fail-open semantics Maps fail-open semantics to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Turn budget Maps turn budget to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: When to use it, Quick start, Commands, Adding criteria mid-goal: /subgoal, Behavior details. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: persistent, goals, gives, standing, objective. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for persistent goals before applying exact upstream commands. | | Verify first | When to use it | Open the source anchor for When to use it and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for When to use it; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Code Execution | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/code-execution/ | | Source | https://hermesbible.com/docs/user-guide/features/code-execution | | Section | Core Features | ### Summary Code Execution (Programmatic Tool Calling) The tool lets the agent write Python scripts that call Hermes tools programmatically, collapsing multi step workflows ### Source outline - How It Works - When the Agent Uses This - Practical Examples - Data Processing Pipeline - Multi-Step Web Research - Bulk File Refactoring - Build and Test Pipeline - Execution Mode - Resource Limits - How Tool Calls Work Inside Scripts - Error Handling - Security - Skill Environment Variable Passthrough - HERMES_* variables in the child ### Section map ### How It Works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### When the Agent Uses This Maps when the agent uses this to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Practical Examples Maps practical examples to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Data Processing Pipeline Maps data processing pipeline to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Multi-Step Web Research Maps multi-step web research to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Bulk File Refactoring Maps bulk file refactoring to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Build and Test Pipeline Maps build and test pipeline to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Execution Mode Maps execution mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How It Works, When the Agent Uses This, Practical Examples, Data Processing Pipeline, Multi-Step Web Research. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: execution, programmatic, calling, write, python. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for code execution before applying exact upstream commands. | | Verify first | How It Works | Open the source anchor for How It Works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How It Works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for When the Agent Uses This if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Event Hooks | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/hooks/ | | Source | https://hermesbible.com/docs/user-guide/features/hooks | | Section | Core Features | ### Summary Hermes has three hook systems that run custom code at key lifecycle points: System Registered via Runs in Use case Gateway hooks + in Gateway only Logging, aler ### Source outline - Gateway Event Hooks - Creating a Hook - HOOK.yaml - handler.py - Available Events - Wildcard Matching - Examples - Telegram Alert on Long Tasks - Command Usage Logger - Session Start Webhook - Tutorial: BOOT.md — Run a Startup Checklist on Every Gateway Boot - What we're building - Step 1: Write your checklist - Step 2: Create the hook ### Section map ### Gateway Event Hooks Maps gateway event hooks to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Creating a Hook Maps creating a hook to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Available Events Maps available events to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Examples Maps examples to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Tutorial: BOOT.md — Run a Startup Checklist on Every Gateway Boot Maps tutorial: boot.md — run a startup checklist on every gateway boot to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Gateway Event Hooks, Creating a Hook, Available Events, Examples, Tutorial: BOOT.md — Run a Startup Checklist on Every Gateway Boot. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: event, hooks, three, systems, custom. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for event hooks before applying exact upstream commands. | | Verify first | Gateway Event Hooks | Open the source anchor for Gateway Event Hooks and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Gateway Event Hooks; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Creating a Hook if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | --- ## Batch Processing | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/batch-processing/ | | Source | https://hermesbible.com/docs/user-guide/features/batch-processing | | Section | Core Features | ### Summary Batch processing lets you run the Hermes agent across hundreds or thousands of prompts in parallel, generating structured trajectory data. This is primarily use ### Source outline - Overview - Quick Start - Dataset Format - Configuration Options - Provider Routing (OpenRouter) - Reasoning Control - Advanced Options - Toolset Distributions - Output Format - Trajectory Format - Checkpointing - How Resume Works - Quality Filtering - Statistics ### Section map ### Overview Maps overview to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Dataset Format Maps dataset format to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Options Maps configuration options to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Provider Routing (OpenRouter) Maps provider routing (openrouter) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Reasoning Control Maps reasoning control to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Advanced Options Maps advanced options to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Toolset Distributions Maps toolset distributions to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Quick Start, Dataset Format, Configuration Options, Provider Routing (OpenRouter). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: batch, processing, across, hundreds, thousands. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for batch processing before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Voice Mode | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/voice-mode/ | | Source | https://hermesbible.com/docs/user-guide/features/voice-mode | | Section | Core Features | ### Summary Hermes Agent supports full voice interaction across CLI and messaging platforms. Talk to the agent using your microphone, hear spoken replies, and have live voi ### Source outline - Prerequisites - Overview - Requirements - Python Packages - System Dependencies - API Keys - CLI Voice Mode - Quick Start - How It Works - Silence Detection - Streaming TTS - Hallucination Filter - Gateway Voice Reply (Telegram & Discord) - Discord: Channels vs DMs ### Section map ### Prerequisites Maps prerequisites to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Overview Maps overview to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Requirements Maps requirements to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Python Packages Maps python packages to the Core Features documentation path, with the source page reserved for exact commands and updates. ### System Dependencies Maps system dependencies to the Core Features documentation path, with the source page reserved for exact commands and updates. ### API Keys Maps api keys to the Core Features documentation path, with the source page reserved for exact commands and updates. ### CLI Voice Mode Maps cli voice mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Overview, Requirements, Python Packages, System Dependencies. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: voice, supports, interaction, across, messaging. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for voice mode before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Overview if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Browser Automation | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/browser/ | | Source | https://hermesbible.com/docs/user-guide/features/browser | | Section | Core Features | ### Summary Browser Automation Hermes Agent includes a full browser automation toolset with multiple backend options: Browserbase cloud mode via Browserbase for managed clo ### Source outline - Overview - Setup - Browserbase cloud mode - Browser Use cloud mode - Firecrawl cloud mode - Hybrid routing: cloud for public URLs, local for LAN/localhost - Camofox local mode - Persistent browser sessions - Externally managed Camofox sessions - VNC live view - Local Chromium-family browser via CDP (/browser connect) - WSL2 + Windows Chrome: prefer MCP over /browser connect - Local browser mode - Optional Environment Variables ### Section map ### Overview Maps overview to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Browserbase cloud mode Maps browserbase cloud mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Browser Use cloud mode Maps browser use cloud mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Firecrawl cloud mode Maps firecrawl cloud mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Hybrid routing: cloud for public URLs, local for LAN/localhost Maps hybrid routing: cloud for public urls, local for lan/localhost to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Camofox local mode Maps camofox local mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Local Chromium-family browser via CDP (/browser connect) Maps local chromium-family browser via cdp (/browser connect) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Setup, Browserbase cloud mode, Browser Use cloud mode, Firecrawl cloud mode. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: browser, automation, includes, toolset, multiple. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for browser automation before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Vision & Image Paste | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/vision/ | | Source | https://hermesbible.com/docs/user-guide/features/vision | | Section | Core Features | ### Summary Vision & Image Paste Hermes Agent supports multimodal vision — you can paste images from your clipboard directly into the CLI and ask the agent to analyze, desc ### Source outline - How It Works - Paste Methods - /paste Command - Ctrl+V / Cmd+V - /terminal-setup for VS Code / Cursor / Windsurf - Platform Compatibility - Platform-Specific Setup - macOS - Linux (X11) - Linux (Wayland) - WSL2 - Verify WSL2 clipboard access - SSH & Remote Sessions - Workarounds for SSH ### Section map ### How It Works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Paste Methods Maps paste methods to the Core Features documentation path, with the source page reserved for exact commands and updates. ### /paste Command Maps /paste command to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Ctrl+V / Cmd+V Maps ctrl+v / cmd+v to the Core Features documentation path, with the source page reserved for exact commands and updates. ### /terminal-setup for VS Code / Cursor / Windsurf Maps /terminal-setup for vs code / cursor / windsurf to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Platform Compatibility Maps platform compatibility to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Platform-Specific Setup Maps platform-specific setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### macOS Maps macos to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How It Works, Paste Methods, /paste Command, Ctrl+V / Cmd+V, /terminal-setup for VS Code / Cursor / Windsurf. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: vision, image, paste, supports, multimodal. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for vision & image paste before applying exact upstream commands. | | Verify first | How It Works | Open the source anchor for How It Works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How It Works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Paste Methods if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Image Generation | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/image-generation/ | | Source | https://hermesbible.com/docs/user-guide/features/image-generation | | Section | Core Features | ### Summary Image Generation Hermes Agent generates images from text prompts via FAL.ai. Eleven models are supported out of the box, each with different speed, quality, and ### Source outline - Supported Models - Setup - Get a FAL API Key - Configure and Pick a Model - GPT-Image Quality - Usage - Aspect Ratios - Automatic Upscaling - How It Works Internally - Debugging - Platform Delivery - Limitations ### Section map ### Supported Models Maps supported models to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Get a FAL API Key Maps get a fal api key to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configure and Pick a Model Maps configure and pick a model to the Core Features documentation path, with the source page reserved for exact commands and updates. ### GPT-Image Quality Maps gpt-image quality to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Usage Maps usage to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Aspect Ratios Maps aspect ratios to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Automatic Upscaling Maps automatic upscaling to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Supported Models, Setup, Get a FAL API Key, Configure and Pick a Model, GPT-Image Quality. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: image, generation, generates, images, prompts. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for image generation before applying exact upstream commands. | | Verify first | Supported Models | Open the source anchor for Supported Models and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Supported Models; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Voice & TTS | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/tts/ | | Source | https://hermesbible.com/docs/user-guide/features/tts | | Section | Core Features | ### Summary Hermes Agent supports both text to speech output and voice message transcription across all messaging platforms. TIP — Nous Subscribers If you have a paid Nous ### Source outline - Text-to-Speech - Platform Delivery - Configuration - Gemini Persona Prompts - Gemini Audio Tags - Input length limits - Telegram Voice Bubbles & ffmpeg - xAI Custom Voices (voice cloning) - Piper (local, 44 languages) - Custom command providers - Example: Doubao (Chinese seed-tts-2.0) - Placeholders - Optional keys - Behavior notes ### Section map ### Text-to-Speech Maps text-to-speech to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Platform Delivery Maps platform delivery to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Gemini Persona Prompts Maps gemini persona prompts to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Gemini Audio Tags Maps gemini audio tags to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Input length limits Maps input length limits to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Telegram Voice Bubbles & ffmpeg Maps telegram voice bubbles & ffmpeg to the Core Features documentation path, with the source page reserved for exact commands and updates. ### xAI Custom Voices (voice cloning) Maps xai custom voices (voice cloning) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Text-to-Speech, Platform Delivery, Configuration, Gemini Persona Prompts, Gemini Audio Tags. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: voice, supports, speech, output, message. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for voice & tts before applying exact upstream commands. | | Verify first | Text-to-Speech | Open the source anchor for Text-to-Speech and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Text-to-Speech; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Platform Delivery if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## MCP (Model Context Protocol) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/mcp/ | | Source | https://hermesbible.com/docs/user-guide/features/mcp | | Section | Core Features | ### Summary MCP lets Hermes Agent connect to external tool servers so the agent can use tools that live outside Hermes itself — GitHub, databases, file systems, browser sta ### Source outline - What MCP gives you - Quick start - Catalog: one-click install for Nous-approved MCPs - Tool selection at install time - Trust model - Manifest version compatibility - Runtime ${ENV_VAR} substitution - Updating tool selection later - Updating the catalog manifest - Two kinds of MCP servers - Stdio servers - HTTP servers - OAuth-authenticated HTTP servers - mTLS / client certificates ### Section map ### What MCP gives you Maps what mcp gives you to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Catalog: one-click install for Nous-approved MCPs Maps catalog: one-click install for nous-approved mcps to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Tool selection at install time Maps tool selection at install time to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Trust model Maps trust model to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Manifest version compatibility Maps manifest version compatibility to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Runtime ${ENV_VAR} substitution Maps runtime ${env_var} substitution to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Updating tool selection later Maps updating tool selection later to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What MCP gives you, Quick start, Catalog: one-click install for Nous-approved MCPs, Tool selection at install time, Trust model. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: model, context, protocol, connect, external. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for mcp (model context protocol) before applying exact upstream commands. | | Verify first | What MCP gives you | Open the source anchor for What MCP gives you and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for What MCP gives you; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## ACP Editor Integration | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/acp/ | | Source | https://hermesbible.com/docs/user-guide/features/acp | | Section | Core Features | ### Summary Hermes Agent can run as an ACP server, letting ACP compatible editors talk to Hermes over stdio and render: chat messages tool activity file diffs terminal comm ### Source outline - What Hermes exposes in ACP mode - Installation - Launching the ACP server - Browser tools (optional) - Editor setup - VS Code - Zed - JetBrains - Registry manifest - Configuration and credentials - Session behavior - Working directory behavior - Approvals - Session-scoped edit auto-approval ### Section map ### What Hermes exposes in ACP mode Maps what hermes exposes in acp mode to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Installation Maps installation to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Launching the ACP server Maps launching the acp server to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Browser tools (optional) Maps browser tools (optional) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Editor setup Maps editor setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### VS Code Maps vs code to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Zed Maps zed to the Core Features documentation path, with the source page reserved for exact commands and updates. ### JetBrains Maps jetbrains to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What Hermes exposes in ACP mode, Installation, Launching the ACP server, Browser tools (optional), Editor setup. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: editor, integration, server, letting, compatible. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for acp editor integration before applying exact upstream commands. | | Verify first | What Hermes exposes in ACP mode | Open the source anchor for What Hermes exposes in ACP mode and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for What Hermes exposes in ACP mode; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Installation if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## API Server | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/api-server/ | | Source | https://hermesbible.com/docs/user-guide/features/api-server | | Section | Core Features | ### Summary The API server exposes hermes agent as an OpenAI compatible HTTP endpoint. Any frontend that speaks the OpenAI format — Open WebUI, LobeChat, LibreChat, NextCha ### Source outline - Quick Start - 1. Enable the API server - 2. Start the gateway - 3. Connect a frontend - Endpoints - POST /v1/chat/completions - POST /v1/responses - Multi-turn with previous_response_id - Named conversations - GET /v1/responses/\{id\} - DELETE /v1/responses/\{id\} - GET /v1/models - GET /v1/capabilities - GET /health ### Section map ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 1. Enable the API server Maps 1. enable the api server to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 2. Start the gateway Maps 2. start the gateway to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 3. Connect a frontend Maps 3. connect a frontend to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Endpoints Maps endpoints to the Core Features documentation path, with the source page reserved for exact commands and updates. ### POST /v1/chat/completions Maps post /v1/chat/completions to the Core Features documentation path, with the source page reserved for exact commands and updates. ### POST /v1/responses Maps post /v1/responses to the Core Features documentation path, with the source page reserved for exact commands and updates. ### GET /v1/responses/\{id\} Maps get /v1/responses/\{id\} to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick Start, 1. Enable the API server, 2. Start the gateway, 3. Connect a frontend, Endpoints. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: server, exposes, openai, compatible, endpoint.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for api server before applying exact upstream commands. | | Verify first | Quick Start | Open the source anchor for Quick Start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Quick Start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for 1. Enable the API server if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Honcho Memory | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/honcho/ | | Source | https://hermesbible.com/docs/user-guide/features/honcho | | Section | Core Features | ### Summary Honcho is an AI native memory backend that adds dialectic reasoning and deep user modeling on top of Hermes's built in memory system. Instead of simple key valu ### Source outline - What Honcho Adds - Setup - Architecture - Two-Layer Context Injection - Cold/Warm Prompt Selection - Three Orthogonal Config Knobs - Dialectic Depth (Multi-Pass) - Session-Start Prewarm - Query-Adaptive Reasoning Level - Configuration Options - Self-Hosted Honcho with Authentication - Full Config Reference - Gateway Identity Mapping - Observation (Directional vs. Unified) ### Section map ### What Honcho Adds Maps what honcho adds to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Architecture Maps architecture to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Two-Layer Context Injection Maps two-layer context injection to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Cold/Warm Prompt Selection Maps cold/warm prompt selection to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Three Orthogonal Config Knobs Maps three orthogonal config knobs to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Dialectic Depth (Multi-Pass) Maps dialectic depth (multi-pass) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Session-Start Prewarm Maps session-start prewarm to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What Honcho Adds, Setup, Architecture, Two-Layer Context Injection, Cold/Warm Prompt Selection. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: honcho, memory, native, backend, dialectic. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for honcho memory before applying exact upstream commands. | | Verify first | What Honcho Adds | Open the source anchor for What Honcho Adds and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for What Honcho Adds; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Provider Routing | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/provider-routing/ | | Source | https://hermesbible.com/docs/user-guide/features/provider-routing | | Section | Core Features | ### Summary Provider Routing When using OpenRouter as your LLM provider, Hermes Agent supports provider routing — fine grained control over which underlying AI providers ha ### Source outline - Configuration - Options - sort - only - ignore - order - require_parameters - data_collection - Practical Examples - Optimize for Cost - Optimize for Speed - Optimize for Throughput - Lock to Specific Providers - Avoid Specific Providers ### Section map ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Options Maps options to the Core Features documentation path, with the source page reserved for exact commands and updates. ### sort Maps sort to the Core Features documentation path, with the source page reserved for exact commands and updates. ### only Maps only to the Core Features documentation path, with the source page reserved for exact commands and updates. ### ignore Maps ignore to the Core Features documentation path, with the source page reserved for exact commands and updates. ### order Maps order to the Core Features documentation path, with the source page reserved for exact commands and updates. ### require_parameters Maps require_parameters to the Core Features documentation path, with the source page reserved for exact commands and updates. ### data_collection Maps data_collection to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Configuration, Options, sort, only, ignore. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: provider, routing, openrouter, supports, grained. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for provider routing before applying exact upstream commands. | | Verify first | Configuration | Open the source anchor for Configuration and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Configuration; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Options if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Fallback Providers | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/fallback-providers/ | | Source | https://hermesbible.com/docs/user-guide/features/fallback-providers | | Section | Core Features | ### Summary Fallback Providers Hermes Agent has three layers of resilience that keep your sessions running when providers hit issues: 1. Credential pools — rotate across mu ### Source outline - Primary Model Fallback - Configuration - Supported Providers - Custom Endpoint Fallback - When Fallback Triggers - Examples - Where Fallback Works - Auxiliary Task Fallback - Tasks with Independent Provider Resolution - Auto-Detection Chain - Configuring Auxiliary Providers - Provider Options for Auxiliary Tasks - Direct Endpoint Override - Auxiliary Capacity-Error Fallback ### Section map ### Primary Model Fallback Maps primary model fallback to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Supported Providers Maps supported providers to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Custom Endpoint Fallback Maps custom endpoint fallback to the Core Features documentation path, with the source page reserved for exact commands and updates. ### When Fallback Triggers Maps when fallback triggers to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Examples Maps examples to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Where Fallback Works Maps where fallback works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Auxiliary Task Fallback Maps auxiliary task fallback to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Primary Model Fallback, Configuration, Supported Providers, Custom Endpoint Fallback, When Fallback Triggers. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: fallback, providers, three, layers, resilience. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for fallback providers before applying exact upstream commands. | | Verify first | Primary Model Fallback | Open the source anchor for Primary Model Fallback and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Primary Model Fallback; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Configuration if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Credential Pools | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/credential-pools/ | | Source | https://hermesbible.com/docs/user-guide/features/credential-pools | | Section | Core Features | ### Summary Credential Pools Credential pools let you register multiple API keys or OAuth tokens for the same provider. When one key hits a rate limit or billing quota, Her ### Source outline - How It Works - Quick Start - Interactive Management - CLI Commands - Rotation Strategies - Error Recovery - Custom Endpoint Pools - Auto-Discovery - Delegation & Subagent Sharing - Thread Safety - Architecture - Storage ### Section map ### How It Works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Interactive Management Maps interactive management to the Core Features documentation path, with the source page reserved for exact commands and updates. ### CLI Commands Maps cli commands to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Rotation Strategies Maps rotation strategies to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Error Recovery Maps error recovery to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Custom Endpoint Pools Maps custom endpoint pools to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Auto-Discovery Maps auto-discovery to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How It Works, Quick Start, Interactive Management, CLI Commands, Rotation Strategies. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: credential, pools, register, multiple, oauth. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for credential pools before applying exact upstream commands. | | Verify first | How It Works | Open the source anchor for How It Works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How It Works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Codex App-Server Runtime | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/codex-app-server-runtime/ | | Source | https://hermesbible.com/docs/user-guide/features/codex-app-server-runtime | | Section | Core Features | ### Summary Codex App Server Runtime Hermes can optionally hand and turns to the Codex CLI app server instead of running its own tool loop. When enabled, terminal commands, ### Source outline - Why - What tools the model actually has - 1. Codex's built-in toolset (always on) - 2. Native Codex plugins (auto-migrated from your codex plugin install) - 3. Hermes tool callback (MCP server, registered in ~/.codex/config.toml) - What's NOT available on this runtime - Workflow features (/goal, kanban, cron) - /goal (the Ralph loop) - Kanban (multi-agent worktree dispatch) - Cron jobs - Trade-offs - Prerequisites - Enabling - Self-improvement loop (memory + skill nudges) ### Section map ### Why Maps why to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What tools the model actually has Maps what tools the model actually has to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 1. Codex's built-in toolset (always on) Maps 1. codex's built-in toolset (always on) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 2. Native Codex plugins (auto-migrated from your codex plugin install) Maps 2. native codex plugins (auto-migrated from your codex plugin install) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 3. Hermes tool callback (MCP server, registered in ~/.codex/config.toml) Maps 3. hermes tool callback (mcp server, registered in ~/.codex/config.toml) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What's NOT available on this runtime Maps what's not available on this runtime to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Workflow features (/goal, kanban, cron) Maps workflow features (/goal, kanban, cron) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### /goal (the Ralph loop) Maps /goal (the ralph loop) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Why, What tools the model actually has, 1. Codex's built-in toolset (always on), 2. Native Codex plugins (auto-migrated from your codex plugin install), 3. Hermes tool callback (MCP server, registered in ~/.codex/config.toml). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: codex, app-server, runtime, server, optionally. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for codex app-server runtime before applying exact upstream commands. | | Verify first | Why | Open the source anchor for Why and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Why; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What tools the model actually has if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Computer Use (macOS) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/computer-use/ | | Source | https://hermesbible.com/docs/user-guide/features/computer-use | | Section | Core Features | ### Summary Computer Use (macOS) Hermes Agent can drive your Mac's desktop — clicking, typing, scrolling, dragging — in the background . Your cursor doesn't move, keyboard ### Source outline - How it works - Enabling - Keeping cua-driver up to date - Quick example - Provider compatibility - Safety - Token efficiency - Limitations - Configuration - Troubleshooting - See also ### Section map ### How it works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Enabling Maps enabling to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Keeping cua-driver up to date Maps keeping cua-driver up to date to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick example Maps quick example to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Provider compatibility Maps provider compatibility to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Safety Maps safety to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Token efficiency Maps token efficiency to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Limitations Maps limitations to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How it works, Enabling, Keeping cua-driver up to date, Quick example, Provider compatibility. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: computer, macos, drive, desktop, clicking. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for computer use (macos) before applying exact upstream commands. | | Verify first | How it works | Open the source anchor for How it works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How it works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Enabling if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Deliverable Mode | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/deliverable-mode/ | | Source | https://hermesbible.com/docs/user-guide/features/deliverable-mode | | Section | Core Features | ### Summary Deliverable Mode When Hermes Agent runs inside a messaging gateway (Slack, Discord, Telegram, WhatsApp, Signal, etc.), it can deliver generated files directly i ### Source outline - How it works - Supported file extensions - Encouraging the agent to produce artifacts - Kanban: artifacts ride completion notifications - Connecting more services with MCP - Comparison to Perplexity Computer in Slack ### Section map ### How it works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Supported file extensions Maps supported file extensions to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Encouraging the agent to produce artifacts Maps encouraging the agent to produce artifacts to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Kanban: artifacts ride completion notifications Maps kanban: artifacts ride completion notifications to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Connecting more services with MCP Maps connecting more services with mcp to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Comparison to Perplexity Computer in Slack Maps comparison to perplexity computer in slack to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How it works, Supported file extensions, Encouraging the agent to produce artifacts, Kanban: artifacts ride completion notifications, Connecting more services with MCP. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: deliverable, inside, messaging, gateway, slack. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for deliverable mode before applying exact upstream commands. | | Verify first | How it works | Open the source anchor for How it works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How it works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Supported file extensions if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Extending the Dashboard | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/extending-the-dashboard/ | | Source | https://hermesbible.com/docs/user-guide/features/extending-the-dashboard | | Section | Core Features | ### Summary The Hermes web dashboard ( ) is built to be reskinned and extended without forking the codebase. Three layers are exposed: 1. Themes — YAML files that repaint t ### Source outline - Table of contents - Themes - Quick start — your first theme - Palette, typography, layout - Palette (3-layer) - Typography - Layout - Layout variants - Theme assets (images as CSS vars) - Component chrome overrides - Color overrides - Raw customCSS - Built-in themes - Full theme YAML reference ### Section map ### Table of contents Maps table of contents to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Themes Maps themes to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick start — your first theme Maps quick start — your first theme to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Palette, typography, layout Maps palette, typography, layout to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Layout variants Maps layout variants to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Theme assets (images as CSS vars) Maps theme assets (images as css vars) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Component chrome overrides Maps component chrome overrides to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Color overrides Maps color overrides to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Table of contents, Themes, Quick start — your first theme, Palette, typography, layout, Layout variants. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: extending, dashboard, reskinned, extended, without. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for extending the dashboard before applying exact upstream commands. | | Verify first | Table of contents | Open the source anchor for Table of contents and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Table of contents; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Themes if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Kanban worker lanes | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/kanban-worker-lanes/ | | Source | https://hermesbible.com/docs/user-guide/features/kanban-worker-lanes | | Section | Core Features | ### Summary Kanban worker lanes A worker lane is a class of process that the kanban dispatcher can route tasks to. Each lane has an identity (the assignee string), a spawn ### Source outline - The hierarchy - What a lane provides - 1. An assignee string - 2. A spawn mechanism - 3. A lifecycle terminator - Outputs and the review-required convention - Logs and audit trail - Existing lane shapes - Hermes profile lane (default) - Orchestrator profile lane - Adding an external CLI worker lane - Failure modes the dispatcher handles - Related ### Section map ### The hierarchy Maps the hierarchy to the Core Features documentation path, with the source page reserved for exact commands and updates. ### What a lane provides Maps what a lane provides to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 1. An assignee string Maps 1. an assignee string to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 2. A spawn mechanism Maps 2. a spawn mechanism to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 3. A lifecycle terminator Maps 3. a lifecycle terminator to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Outputs and the review-required convention Maps outputs and the review-required convention to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Logs and audit trail Maps logs and audit trail to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Existing lane shapes Maps existing lane shapes to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: The hierarchy, What a lane provides, 1. An assignee string, 2. A spawn mechanism, 3. A lifecycle terminator. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: kanban, worker, lanes, class, process. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for kanban worker lanes before applying exact upstream commands. | | Verify first | The hierarchy | Open the source anchor for The hierarchy and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for The hierarchy; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What a lane provides if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## LSP — Semantic Diagnostics | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/lsp/ | | Source | https://hermesbible.com/docs/user-guide/features/lsp | | Section | Core Features | ### Summary Language Server Protocol (LSP) Hermes runs full language servers — pyright, gopls, rust analyzer, typescript language server, clangd, and ~20 more — as backgrou ### Source outline - When LSP runs - Supported languages - CLI - Configuration - Per-server keys - Installation locations - Performance characteristics - Disabling - Troubleshooting ### Section map ### When LSP runs Maps when lsp runs to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Supported languages Maps supported languages to the Core Features documentation path, with the source page reserved for exact commands and updates. ### CLI Maps cli to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Per-server keys Maps per-server keys to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Installation locations Maps installation locations to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Performance characteristics Maps performance characteristics to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Disabling Maps disabling to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: When LSP runs, Supported languages, CLI, Configuration, Per-server keys. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: semantic, diagnostics, language, server, protocol. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for lsp — semantic diagnostics before applying exact upstream commands. | | Verify first | When LSP runs | Open the source anchor for When LSP runs and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for When LSP runs; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Supported languages if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Skins & Themes | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/skins/ | | Source | https://hermesbible.com/docs/user-guide/features/skins | | Section | Core Features | ### Summary Skins control the visual presentation of the Hermes CLI: banner colors, spinner faces and verbs, response box labels, branding text, and the tool activity prefi ### Source outline - Change skins - Built-in skins - Complete list of configurable keys - Colors (colors:) - Spinner (spinner:) - Branding (branding:) - Other top-level keys - Custom skins - Full custom skin YAML template - Minimal custom skin example - Hermes Mod — Visual Skin Editor - Install - Usage - Operational notes ### Section map ### Change skins Maps change skins to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Built-in skins Maps built-in skins to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Complete list of configurable keys Maps complete list of configurable keys to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Colors (colors:) Maps colors (colors:) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Spinner (spinner:) Maps spinner (spinner:) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Branding (branding:) Maps branding (branding:) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Other top-level keys Maps other top-level keys to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Custom skins Maps custom skins to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Change skins, Built-in skins, Complete list of configurable keys, Colors (colors:), Spinner (spinner:). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: skins, themes, control, visual, presentation. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for skins & themes before applying exact upstream commands. | | Verify first | Change skins | Open the source anchor for Change skins and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Change skins; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Built-in skins if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Spotify | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/spotify/ | | Source | https://hermesbible.com/docs/user-guide/features/spotify | | Section | Core Features | ### Summary Spotify Hermes can control Spotify directly — playback, queue, search, playlists, saved tracks/albums, and listening history — using Spotify's official Web API ### Source outline - Prerequisites - Setup - One-shot: hermes tools or first-run setup - Two-step flow - 1. Enable the toolset - 2. Run the login wizard - Creating the Spotify app (what the wizard asks for) - Running over SSH / in a headless environment - Verify - Using it - Tool reference - spotify_playback - spotify_devices - Home Assistant-managed speakers ### Section map ### Prerequisites Maps prerequisites to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### One-shot: hermes tools or first-run setup Maps one-shot: hermes tools or first-run setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Two-step flow Maps two-step flow to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Creating the Spotify app (what the wizard asks for) Maps creating the spotify app (what the wizard asks for) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Running over SSH / in a headless environment Maps running over ssh / in a headless environment to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Verify Maps verify to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Using it Maps using it to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Setup, One-shot: hermes tools or first-run setup, Two-step flow, Creating the Spotify app (what the wizard asks for). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: spotify, control, directly, playback, queue. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for spotify before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Subscription Proxy | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/subscription-proxy/ | | Source | https://hermesbible.com/docs/user-guide/features/subscription-proxy | | Section | Core Features | ### Summary The subscription proxy is a local HTTP server that lets external apps — OpenViking, Karakeep, Open WebUI, anything that speaks OpenAI compatible chat completion ### Source outline - Quick Start - 1. Log into your provider (one-time) - 2. Start the proxy - 3. Point your app at it - Available providers - Check status - Allowed paths - Configuring OpenViking to use Portal - Configuring Karakeep (or any bookmark/summarizer app) - Exposing on LAN - Rate limits - Architecture - Future: more OAuth providers ### Section map ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 1. Log into your provider (one-time) Maps 1. log into your provider (one-time) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 2. Start the proxy Maps 2. start the proxy to the Core Features documentation path, with the source page reserved for exact commands and updates. ### 3. Point your app at it Maps 3. point your app at it to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Available providers Maps available providers to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Check status Maps check status to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Allowed paths Maps allowed paths to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuring OpenViking to use Portal Maps configuring openviking to use portal to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick Start, 1. Log into your provider (one-time), 2. Start the proxy, 3. Point your app at it, Available providers. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: subscription, proxy, local, server, external. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for subscription proxy before applying exact upstream commands. | | Verify first | Quick Start | Open the source anchor for Quick Start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Quick Start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for 1. Log into your provider (one-time) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Nous Tool Gateway | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/tool-gateway/ | | Source | https://hermesbible.com/docs/user-guide/features/tool-gateway | | Section | Core Features | ### Summary One subscription. Every tool built in. The Tool Gateway is included with every paid Nous Portal subscription. It routes Hermes' tool calls — web search, image g ### Source outline - What's included - Why it's here - Get started - Eligibility - Mix and match - Using individual image models - Configuration reference - Per-tool use_gateway flag - Disabling the gateway - Self-hosted gateway (advanced) - FAQ - Does it work with Telegram / Discord / the other messaging gateways? - What happens if my subscription expires? - Can I see usage or costs per tool? ### Section map ### What's included Maps what's included to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Why it's here Maps why it's here to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Get started Maps get started to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Eligibility Maps eligibility to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Mix and match Maps mix and match to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Using individual image models Maps using individual image models to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration reference Maps configuration reference to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Per-tool use_gateway flag Maps per-tool use_gateway flag to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What's included, Why it's here, Get started, Eligibility, Mix and match. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: gateway, subscription., every, included, portal. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for nous tool gateway before applying exact upstream commands. | | Verify first | What's included | Open the source anchor for What's included and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for What's included; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Why it's here if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Tool Search | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/tool-search/ | | Source | https://hermesbible.com/docs/user-guide/features/tool-search | | Section | Core Features | ### Summary Tool Search When you have many MCP servers or non core plugin tools attached to a session, their JSON schemas can consume a substantial fraction of the context ### Source outline - How it works - When does it activate? - Configuration - When NOT to use it - Trade-offs that don't go away - Implementation details - See also ### Section map ### How it works Maps how it works to the Core Features documentation path, with the source page reserved for exact commands and updates. ### When does it activate? Maps when does it activate? to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### When NOT to use it Maps when not to use it to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Trade-offs that don't go away Maps trade-offs that don't go away to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation details Maps implementation details to the Core Features documentation path, with the source page reserved for exact commands and updates. ### See also Maps see also to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How it works, When does it activate?, Configuration, When NOT to use it, Trade-offs that don't go away. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: search, servers, plugin, tools, attached. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for tool search before applying exact upstream commands. | | Verify first | How it works | Open the source anchor for How it works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for How it works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for When does it activate? if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Web Dashboard | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/web-dashboard/ | | Source | https://hermesbible.com/docs/user-guide/features/web-dashboard | | Section | Core Features | ### Summary The web dashboard is a browser based UI for managing your Hermes Agent installation. Instead of editing YAML files or running CLI commands, you can configure se ### Source outline - Quick Start - Options - Managing multiple profiles - Prerequisites - Pages - Status - Chat - Connecting Hermes Desktop to a remote backend - Remote dashboard setup - Config - API Keys - Sessions - Logs - Analytics ### Section map ### Quick Start Maps quick start to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Options Maps options to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Managing multiple profiles Maps managing multiple profiles to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Pages Maps pages to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Status Maps status to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Chat Maps chat to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Connecting Hermes Desktop to a remote backend Maps connecting hermes desktop to a remote backend to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick Start, Options, Managing multiple profiles, Prerequisites, Pages. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: dashboard, browser, based, managing, installation.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for web dashboard before applying exact upstream commands. | | Verify first | Quick Start | Open the source anchor for Quick Start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Quick Start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Options if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Web Search & Extract | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/web-search/ | | Source | https://hermesbible.com/docs/user-guide/features/web-search | | Section | Core Features | ### Summary Web Search & Extract Hermes Agent includes two model callable web tools backed by multiple providers: — search the web and return ranked results — fetch and ext ### Source outline - Backends - How web_extract handles long pages - Which model does the summarizing? - When summarization gets in the way - Setup - Quick setup via hermes tools - Firecrawl (default) - SearXNG (free, self-hosted) - Option A — Self-host with Docker (recommended) - Option B — Use a public instance - Pair SearXNG with an extract provider - Tavily - Exa - Parallel ### Section map ### Backends Maps backends to the Core Features documentation path, with the source page reserved for exact commands and updates. ### How web_extract handles long pages Maps how web_extract handles long pages to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Which model does the summarizing? Maps which model does the summarizing? to the Core Features documentation path, with the source page reserved for exact commands and updates. ### When summarization gets in the way Maps when summarization gets in the way to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Quick setup via hermes tools Maps quick setup via hermes tools to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Firecrawl (default) Maps firecrawl (default) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### SearXNG (free, self-hosted) Maps searxng (free, self-hosted) to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Backends, How web_extract handles long pages, Which model does the summarizing?, When summarization gets in the way, Setup. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: search, extract, includes, model, callable. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for web search & extract before applying exact upstream commands. | | Verify first | Backends | Open the source anchor for Backends and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Backends; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for How web_extract handles long pages if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## X (Twitter) Search | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/features/x-search/ | | Source | https://hermesbible.com/docs/user-guide/features/x-search | | Section | Core Features | ### Summary X (Twitter) Search The tool lets the agent search X (Twitter) posts, profiles, and threads directly. It's backed by xAI's built in tool on the Responses API at ### Source outline - Authentication - Enabling the tool - Configuration - Tool parameters - Date validation - Example - Troubleshooting - "No xAI credentials available" - "x_search is not enabled for this model" - Tool doesn't appear in the schema - degraded: true — answer with no citations - See Also ### Section map ### Authentication Maps authentication to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Enabling the tool Maps enabling the tool to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Tool parameters Maps tool parameters to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Date validation Maps date validation to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Example Maps example to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Troubleshooting Maps troubleshooting to the Core Features documentation path, with the source page reserved for exact commands and updates. ### "No xAI credentials available" Maps "no xai credentials available" to the Core Features documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Core Features doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Authentication, Enabling the tool, Configuration, Tool parameters, Date validation. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: twitter, search, posts, profiles, threads. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Core Features documentation | Use when you need orientation for x (twitter) search before applying exact upstream commands. | | Verify first | Authentication | Open the source anchor for Authentication and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Core Features, then open the linked source page for exact current syntax. - Start with the source section for Authentication; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Enabling the tool if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Messaging Platforms ## Messaging Gateway | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/index/ | | Source | https://hermesbible.com/docs/user-guide/messaging/index | | Section | Messaging Platforms | ### Summary Chat with Hermes from Telegram, Discord, Slack, WhatsApp, Signal, SMS, Email, Home Assistant, Mattermost, Matrix, DingTalk, Feishu/Lark, WeCom, Weixin, BlueBubb ### Source outline - Platform Comparison - Architecture - Intentional Silence Tokens - Quick Setup - Gateway Commands - Chat Commands (Inside Messaging) - Session Management - Session Persistence - Reset Policies - Security - DM Pairing (Alternative to Allowlists) - Admins vs Regular Users - Configuration - Inspecting your access ### Section map ### Platform Comparison Maps platform comparison to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Architecture Maps architecture to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Intentional Silence Tokens Maps intentional silence tokens to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Quick Setup Maps quick setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Gateway Commands Maps gateway commands to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Chat Commands (Inside Messaging) Maps chat commands (inside messaging) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Management Maps session management to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Persistence Maps session persistence to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Platform Comparison, Architecture, Intentional Silence Tokens, Quick Setup, Gateway Commands. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: messaging, gateway, telegram, discord, slack. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for messaging gateway before applying exact upstream commands. | | Verify first | Platform Comparison | Open the source anchor for Platform Comparison and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Platform Comparison; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Architecture if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Telegram | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/telegram/ | | Source | https://hermesbible.com/docs/user-guide/messaging/telegram | | Section | Messaging Platforms | ### Summary Telegram Setup Hermes Agent integrates with Telegram as a full featured conversational bot. Once connected, you can chat with your agent from any device, send v ### Source outline - Step 1: Create a Bot via BotFather - Step 2: Customize Your Bot (Optional) - Step 3: Privacy Mode (Critical for Groups) - How to disable privacy mode - Observe group chatter without auto-replying - Step 4: Find Your User ID - Step 5: Configure Hermes - Option A: Interactive Setup (Recommended) - Option B: Manual Configuration - Start the Gateway - Sending Generated Files from Docker-backed Terminals - Supported MEDIA: file extensions - Webhook Mode - Configuration ### Section map ### Step 1: Create a Bot via BotFather Maps step 1: create a bot via botfather to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Customize Your Bot (Optional) Maps step 2: customize your bot (optional) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Privacy Mode (Critical for Groups) Maps step 3: privacy mode (critical for groups) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### How to disable privacy mode Maps how to disable privacy mode to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Observe group chatter without auto-replying Maps observe group chatter without auto-replying to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Find Your User ID Maps step 4: find your user id to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 5: Configure Hermes Maps step 5: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option A: Interactive Setup (Recommended) Maps option a: interactive setup (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Step 1: Create a Bot via BotFather, Step 2: Customize Your Bot (Optional), Step 3: Privacy Mode (Critical for Groups), How to disable privacy mode, Observe group chatter without auto-replying. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: telegram, setup, integrates, featured, conversational. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for telegram before applying exact upstream commands. | | Verify first | Step 1: Create a Bot via BotFather | Open the source anchor for Step 1: Create a Bot via BotFather and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Step 1: Create a Bot via BotFather; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 2: Customize Your Bot (Optional) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Discord | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/discord/ | | Source | https://hermesbible.com/docs/user-guide/messaging/discord | | Section | Messaging Platforms | ### Summary Discord Setup Hermes Agent integrates with Discord as a bot, letting you chat with your AI assistant through direct messages or server channels. The bot receive ### Source outline - How Hermes Behaves - Discord Gateway Model - Session Model in Discord - Interrupts and Concurrency - Step 1: Create a Discord Application - Step 2: Create the Bot - Step 3: Enable Privileged Gateway Intents - Step 4: Get the Bot Token - Step 5: Generate the Invite URL - Option A: Using the Installation Tab (Recommended) - Option B: Manual URL - Required Permissions - Recommended Additional Permissions - Permission Integers ### Section map ### How Hermes Behaves Maps how hermes behaves to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Discord Gateway Model Maps discord gateway model to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Model in Discord Maps session model in discord to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Interrupts and Concurrency Maps interrupts and concurrency to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a Discord Application Maps step 1: create a discord application to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Create the Bot Maps step 2: create the bot to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Enable Privileged Gateway Intents Maps step 3: enable privileged gateway intents to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Get the Bot Token Maps step 4: get the bot token to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Hermes Behaves, Discord Gateway Model, Session Model in Discord, Interrupts and Concurrency, Step 1: Create a Discord Application. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: discord, setup, integrates, letting, assistant. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for discord before applying exact upstream commands. | | Verify first | How Hermes Behaves | Open the source anchor for How Hermes Behaves and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How Hermes Behaves; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Discord Gateway Model if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Slack | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/slack/ | | Source | https://hermesbible.com/docs/user-guide/messaging/slack | | Section | Messaging Platforms | ### Summary Slack Setup Connect Hermes Agent to Slack as a bot using Socket Mode. Socket Mode uses WebSockets instead of public HTTP endpoints, so your Hermes instance does ### Source outline - Overview - Step 1: Create a Slack App - Option A: From a Hermes-generated manifest (recommended) - Option B: From scratch (manual) - Step 2: Configure Bot Token Scopes - Step 3: Enable Socket Mode - Step 4: Subscribe to Events - Step 5: Enable the Messages Tab - Step 6: Install App to Workspace - Step 7: Find User IDs for the Allowlist - Step 8: Configure Hermes - Step 9: Invite the Bot to Channels - Slash Commands - Refreshing slash commands after updates ### Section map ### Overview Maps overview to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a Slack App Maps step 1: create a slack app to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option A: From a Hermes-generated manifest (recommended) Maps option a: from a hermes-generated manifest (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option B: From scratch (manual) Maps option b: from scratch (manual) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Configure Bot Token Scopes Maps step 2: configure bot token scopes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Enable Socket Mode Maps step 3: enable socket mode to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Subscribe to Events Maps step 4: subscribe to events to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 5: Enable the Messages Tab Maps step 5: enable the messages tab to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Step 1: Create a Slack App, Option A: From a Hermes-generated manifest (recommended), Option B: From scratch (manual), Step 2: Configure Bot Token Scopes. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: slack, setup, connect, socket, mode.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for slack before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create a Slack App if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## WhatsApp | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/whatsapp/ | | Source | https://hermesbible.com/docs/user-guide/messaging/whatsapp | | Section | Messaging Platforms | ### Summary WhatsApp Setup Hermes connects to WhatsApp through a built in bridge based on Baileys . This works by emulating a WhatsApp Web session — not through the officia ### Source outline - Two Modes - Prerequisites - Step 1: Run the Setup Wizard - Step 2: Getting a Second Phone Number (Bot Mode) - Step 3: Configure Hermes - Session Persistence - Re-pairing - Voice Messages - Message Formatting & Delivery - Chunking - WhatsApp-Compatible Markdown - Tool Progress - Message Batching (Debounce) - Troubleshooting ### Section map ### Two Modes Maps two modes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Run the Setup Wizard Maps step 1: run the setup wizard to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Getting a Second Phone Number (Bot Mode) Maps step 2: getting a second phone number (bot mode) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Configure Hermes Maps step 3: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Persistence Maps session persistence to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Re-pairing Maps re-pairing to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Voice Messages Maps voice messages to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Two Modes, Prerequisites, Step 1: Run the Setup Wizard, Step 2: Getting a Second Phone Number (Bot Mode), Step 3: Configure Hermes. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: whatsapp, setup, connects, through, bridge. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for whatsapp before applying exact upstream commands. | | Verify first | Two Modes | Open the source anchor for Two Modes and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Two Modes; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Signal | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/signal/ | | Source | https://hermesbible.com/docs/user-guide/messaging/signal | | Section | Messaging Platforms | ### Summary Signal Setup Hermes connects to Signal through the signal cli daemon running in HTTP mode. The adapter streams messages in real time via SSE (Server Sent Events ### Source outline - Prerequisites - Installing signal-cli - Step 1: Link Your Signal Account - Step 2: Start the signal-cli Daemon - Step 3: Configure Hermes - Manual Configuration - Access Control - DM Access - Group Access - Features - Attachments - Native Formatting, Reply Quotes, and Reactions - Typing Indicators - Tool Progress Display ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Installing signal-cli Maps installing signal-cli to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Link Your Signal Account Maps step 1: link your signal account to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Start the signal-cli Daemon Maps step 2: start the signal-cli daemon to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Configure Hermes Maps step 3: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Manual Configuration Maps manual configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Access Control Maps access control to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### DM Access Maps dm access to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Installing signal-cli, Step 1: Link Your Signal Account, Step 2: Start the signal-cli Daemon, Step 3: Configure Hermes. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: signal, setup, connects, through, daemon. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for signal before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Installing signal-cli if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Email | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/email/ | | Source | https://hermesbible.com/docs/user-guide/messaging/email | | Section | Messaging Platforms | ### Summary Email Setup Hermes can receive and reply to emails using standard IMAP and SMTP protocols. Send an email to the agent's address and it replies in thread — no sp ### Source outline - Prerequisites - Gmail Setup - Outlook / Microsoft 365 - Other Providers - Step 1: Configure Hermes - Manual Configuration - Step 2: Start the Gateway - How It Works - Receiving Messages - Sending Replies - File Attachments - Skipping Attachments - Access Control - Troubleshooting ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Gmail Setup Maps gmail setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Outlook / Microsoft 365 Maps outlook / microsoft 365 to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Other Providers Maps other providers to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Configure Hermes Maps step 1: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Manual Configuration Maps manual configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Start the Gateway Maps step 2: start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### How It Works Maps how it works to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Gmail Setup, Outlook / Microsoft 365, Other Providers, Step 1: Configure Hermes. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: email, setup, receive, reply, emails. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for email before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Gmail Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## SMS (Twilio) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/sms/ | | Source | https://hermesbible.com/docs/user-guide/messaging/sms | | Section | Messaging Platforms | ### Summary SMS Setup (Twilio) Hermes connects to SMS through the Twilio API. People text your Twilio phone number and get AI responses back — same conversational experienc ### Source outline - Prerequisites - Step 1: Get Your Twilio Credentials - Step 2: Configure Hermes - Interactive setup (recommended) - Manual setup - Step 3: Configure Twilio Webhook - Step 4: Start the Gateway - Environment Variables - SMS-Specific Behavior - Security - Webhook signature validation - User allowlists - Troubleshooting - Messages not arriving ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Get Your Twilio Credentials Maps step 1: get your twilio credentials to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Configure Hermes Maps step 2: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Interactive setup (recommended) Maps interactive setup (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Manual setup Maps manual setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Configure Twilio Webhook Maps step 3: configure twilio webhook to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Start the Gateway Maps step 4: start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Environment Variables Maps environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Step 1: Get Your Twilio Credentials, Step 2: Configure Hermes, Interactive setup (recommended), Manual setup. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: twilio, setup, connects, through, people. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for sms (twilio) before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Get Your Twilio Credentials if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Matrix | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/matrix/ | | Source | https://hermesbible.com/docs/user-guide/messaging/matrix | | Section | Messaging Platforms | ### Summary Matrix Setup Hermes Agent integrates with Matrix, the open, federated messaging protocol. Matrix lets you run your own homeserver or use a public one like matri ### Source outline - How Hermes Behaves - Capability Matrix - Session Model in Matrix - Mention and Threading Configuration - Project Room Isolation - Step 1: Create a Bot Account - Option A: Register on Your Homeserver (Recommended) - Option B: Use matrix.org or Another Public Homeserver - Option C: Use Your Own Account - Step 2: Get an Access Token - Option A: Access Token (Recommended) - Option B: Password Login - Step 3: Find Your Matrix User ID - Step 4: Configure Hermes Agent ### Section map ### How Hermes Behaves Maps how hermes behaves to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Capability Matrix Maps capability matrix to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Model in Matrix Maps session model in matrix to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Mention and Threading Configuration Maps mention and threading configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Project Room Isolation Maps project room isolation to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a Bot Account Maps step 1: create a bot account to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option A: Register on Your Homeserver (Recommended) Maps option a: register on your homeserver (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option B: Use matrix.org or Another Public Homeserver Maps option b: use matrix.org or another public homeserver to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Hermes Behaves, Capability Matrix, Session Model in Matrix, Mention and Threading Configuration, Project Room Isolation. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: matrix, setup, integrates, federated, messaging. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for matrix before applying exact upstream commands. | | Verify first | How Hermes Behaves | Open the source anchor for How Hermes Behaves and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How Hermes Behaves; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Capability Matrix if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Mattermost | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/mattermost/ | | Source | https://hermesbible.com/docs/user-guide/messaging/mattermost | | Section | Messaging Platforms | ### Summary Mattermost Setup Hermes Agent integrates with Mattermost as a bot, letting you chat with your AI assistant through direct messages or team channels. Mattermost ### Source outline - How Hermes Behaves - Session Model in Mattermost - Step 1: Enable Bot Accounts - Step 2: Create a Bot Account - Step 3: Add the Bot to Channels - Step 4: Find Your Mattermost User ID - Step 5: Configure Hermes Agent - Option A: Interactive Setup (Recommended) - Option B: Manual Configuration - Start the Gateway - Home Channel - Using the Slash Command - Manual Configuration - Reply Mode ### Section map ### How Hermes Behaves Maps how hermes behaves to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Model in Mattermost Maps session model in mattermost to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Enable Bot Accounts Maps step 1: enable bot accounts to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Create a Bot Account Maps step 2: create a bot account to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Add the Bot to Channels Maps step 3: add the bot to channels to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Find Your Mattermost User ID Maps step 4: find your mattermost user id to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 5: Configure Hermes Agent Maps step 5: configure hermes agent to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option A: Interactive Setup (Recommended) Maps option a: interactive setup (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Hermes Behaves, Session Model in Mattermost, Step 1: Enable Bot Accounts, Step 2: Create a Bot Account, Step 3: Add the Bot to Channels. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: mattermost, setup, integrates, letting, assistant. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for mattermost before applying exact upstream commands. | | Verify first | How Hermes Behaves | Open the source anchor for How Hermes Behaves and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How Hermes Behaves; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Session Model in Mattermost if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Home Assistant Integration | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/homeassistant/ | | Source | https://hermesbible.com/docs/user-guide/messaging/homeassistant | | Section | Messaging Platforms | ### Summary Home Assistant Integration Hermes Agent integrates with Home Assistant in two ways: 1. Gateway platform — subscribes to real time state changes via WebSocket an ### Source outline - Setup - 1. Create a Long-Lived Access Token - 2. Configure Environment Variables - 3. Start the Gateway - Available Tools - ha_list_entities - ha_get_state - ha_list_services - ha_call_service - Gateway Platform: Real-Time Events - Event Filtering - Event Formatting - Agent Responses - Connection Management ### Section map ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 1. Create a Long-Lived Access Token Maps 1. create a long-lived access token to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 2. Configure Environment Variables Maps 2. configure environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 3. Start the Gateway Maps 3. start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Available Tools Maps available tools to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### ha_list_entities Maps ha_list_entities to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### ha_get_state Maps ha_get_state to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### ha_list_services Maps ha_list_services to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Setup, 1. Create a Long-Lived Access Token, 2. Configure Environment Variables, 3. Start the Gateway, Available Tools. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: assistant, integration, integrates, gateway, platform. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for home assistant integration before applying exact upstream commands. | | Verify first | Setup | Open the source anchor for Setup and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Setup; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for 1. Create a Long-Lived Access Token if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Webhooks | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/webhooks/ | | Source | https://hermesbible.com/docs/user-guide/messaging/webhooks | | Section | Messaging Platforms | ### Summary Receive events from external services (GitHub, GitLab, JIRA, Stripe, etc.) and trigger Hermes agent runs automatically. The webhook adapter runs an HTTP server ### Source outline - Video Tutorial - Quick Start - Setup - Via setup wizard - Via environment variables - Verify the server - Configuring Routes {#configuring-routes} - Route properties - Full example - Prompt Templates - Forum Topic Delivery - GitHub PR Review (Step by Step) {#github-pr-review} - 1. Create the webhook in GitHub - 2. Add the route config ### Section map ### Video Tutorial Maps video tutorial to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Via setup wizard Maps via setup wizard to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Via environment variables Maps via environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Verify the server Maps verify the server to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuring Routes {#configuring-routes} Maps configuring routes {#configuring-routes} to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Route properties Maps route properties to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Video Tutorial, Quick Start, Setup, Via setup wizard, Via environment variables. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: webhooks, receive, events, external, services. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for webhooks before applying exact upstream commands. | | Verify first | Video Tutorial | Open the source anchor for Video Tutorial and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Video Tutorial; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## BlueBubbles (iMessage) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/bluebubbles/ | | Source | https://hermesbible.com/docs/user-guide/messaging/bluebubbles | | Section | Messaging Platforms | ### Summary BlueBubbles (iMessage) Connect Hermes to Apple iMessage via BlueBubbles — a free, open source macOS server that bridges iMessage to any device. Prerequisites A ### Source outline - Prerequisites - Setup - 1. Install BlueBubbles Server - 2. Get your Server URL and Password - 3. Configure Hermes - Optional: Require mentions in group chats - 4. Authorize Users - 5. Start the Gateway - How It Works - Environment Variables - Features - Text Messaging - Rich Media - Tapback Reactions ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 1. Install BlueBubbles Server Maps 1. install bluebubbles server to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 2. Get your Server URL and Password Maps 2. get your server url and password to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 3. Configure Hermes Maps 3. configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 4. Authorize Users Maps 4. authorize users to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 5. Start the Gateway Maps 5. start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### How It Works Maps how it works to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Setup, 1. Install BlueBubbles Server, 2. Get your Server URL and Password, 3. Configure Hermes. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: bluebubbles, imessage, connect, apple, source. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for bluebubbles (imessage) before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## DingTalk | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/dingtalk/ | | Source | https://hermesbible.com/docs/user-guide/messaging/dingtalk | | Section | Messaging Platforms | ### Summary DingTalk Setup Hermes Agent integrates with DingTalk (钉钉) as a chatbot, letting you chat with your AI assistant through direct messages or group chats. The bot ### Source outline - How Hermes Behaves - Session Model in DingTalk - Prerequisites - Step 1: Create a DingTalk App - Step 2: Enable the Robot Capability - Step 3: Find Your DingTalk User ID - Step 4: Configure Hermes Agent - Option A: Interactive Setup (Recommended) - Option B: Manual Configuration - Start the Gateway - Features - AI Cards - Emoji Reactions - Display Settings ### Section map ### How Hermes Behaves Maps how hermes behaves to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Session Model in DingTalk Maps session model in dingtalk to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a DingTalk App Maps step 1: create a dingtalk app to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Enable the Robot Capability Maps step 2: enable the robot capability to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Find Your DingTalk User ID Maps step 3: find your dingtalk user id to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Configure Hermes Agent Maps step 4: configure hermes agent to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Option A: Interactive Setup (Recommended) Maps option a: interactive setup (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Hermes Behaves, Session Model in DingTalk, Prerequisites, Step 1: Create a DingTalk App, Step 2: Enable the Robot Capability. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: dingtalk, setup, integrates, chatbot, letting. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for dingtalk before applying exact upstream commands. | | Verify first | How Hermes Behaves | Open the source anchor for How Hermes Behaves and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How Hermes Behaves; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Session Model in DingTalk if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Feishu / Lark | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/feishu/ | | Source | https://hermesbible.com/docs/user-guide/messaging/feishu | | Section | Messaging Platforms | ### Summary Feishu / Lark Setup Hermes Agent integrates with Feishu and Lark as a full featured bot. Once connected, you can chat with the agent in direct messages or group ### Source outline - How Hermes Behaves - Step 1: Create a Feishu / Lark App - Recommended: Scan-to-Create (one command) - Alternative: Manual Setup - Configure Permissions - Configure Events - Publish the App - Step 2: Choose a Connection Mode - Recommended: WebSocket mode - Optional: Webhook mode - Step 3: Configure Hermes - Option A: Interactive Setup - Option B: Manual Configuration - Step 4: Start the Gateway ### Section map ### How Hermes Behaves Maps how hermes behaves to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a Feishu / Lark App Maps step 1: create a feishu / lark app to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Recommended: Scan-to-Create (one command) Maps recommended: scan-to-create (one command) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Alternative: Manual Setup Maps alternative: manual setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configure Permissions Maps configure permissions to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configure Events Maps configure events to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Publish the App Maps publish the app to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Choose a Connection Mode Maps step 2: choose a connection mode to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Hermes Behaves, Step 1: Create a Feishu / Lark App, Recommended: Scan-to-Create (one command), Alternative: Manual Setup, Configure Permissions. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: feishu, setup, integrates, featured, connected. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for feishu / lark before applying exact upstream commands. | | Verify first | How Hermes Behaves | Open the source anchor for How Hermes Behaves and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How Hermes Behaves; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create a Feishu / Lark App if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | --- ## Google Chat | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/google_chat/ | | Source | https://hermesbible.com/docs/user-guide/messaging/google_chat | | Section | Messaging Platforms | ### Summary Google Chat Setup Connect Hermes Agent to Google Chat as a bot. The integration uses Cloud Pub/Sub pull subscriptions for inbound events and the Chat REST API f ### Source outline - Overview - Step 1: Create or pick a GCP project - Step 2: Enable two APIs - Step 3: Create a Service Account - Step 4: Create the Pub/Sub topic and subscription - Step 5: IAM binding on the topic (critical) - Step 6: IAM binding on the subscription - Step 7: Configure the Chat app - Step 8: Install the bot in a test space - Step 9: Configure Hermes - Formatting and capabilities - Step 10: Native attachment delivery (optional) - Why a separate flow - One-time setup (per profile) ### Section map ### Overview Maps overview to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create or pick a GCP project Maps step 1: create or pick a gcp project to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Enable two APIs Maps step 2: enable two apis to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Create a Service Account Maps step 3: create a service account to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Create the Pub/Sub topic and subscription Maps step 4: create the pub/sub topic and subscription to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 5: IAM binding on the topic (critical) Maps step 5: iam binding on the topic (critical) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 6: IAM binding on the subscription Maps step 6: iam binding on the subscription to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 7: Configure the Chat app Maps step 7: configure the chat app to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Step 1: Create or pick a GCP project, Step 2: Enable two APIs, Step 3: Create a Service Account, Step 4: Create the Pub/Sub topic and subscription. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: google, setup, connect, integration, cloud. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for google chat before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create or pick a GCP project if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## LINE | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/line/ | | Source | https://hermesbible.com/docs/user-guide/messaging/line | | Section | Messaging Platforms | ### Summary LINE Setup Run Hermes Agent as a LINE bot via the official LINE Messaging API. The adapter lives as a bundled platform plugin under — no core edits, just enable ### Source outline - How the bot responds - Step 1: Create a LINE Messaging API channel - Step 2: Expose the webhook port - Step 3: Configure Hermes - Step 4: Set the webhook URL - Step 5: Run the gateway - Slow LLM responses - Cron / notification delivery - Environment variable reference - Troubleshooting - Limitations ### Section map ### How the bot responds Maps how the bot responds to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a LINE Messaging API channel Maps step 1: create a line messaging api channel to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Expose the webhook port Maps step 2: expose the webhook port to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Configure Hermes Maps step 3: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Set the webhook URL Maps step 4: set the webhook url to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 5: Run the gateway Maps step 5: run the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Slow LLM responses Maps slow llm responses to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Cron / notification delivery Maps cron / notification delivery to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How the bot responds, Step 1: Create a LINE Messaging API channel, Step 2: Expose the webhook port, Step 3: Configure Hermes, Step 4: Set the webhook URL. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: setup, official, messaging, adapter, lives. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for line before applying exact upstream commands. | | Verify first | How the bot responds | Open the source anchor for How the bot responds and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How the bot responds; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create a LINE Messaging API channel if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Microsoft Graph Webhook Listener | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/msgraph-webhook/ | | Source | https://hermesbible.com/docs/user-guide/messaging/msgraph-webhook | | Section | Messaging Platforms | ### Summary The gateway platform is an inbound event listener. It's how Hermes receives change notifications from Microsoft Graph — "a Teams meeting ended," "a new message ### Source outline - Prerequisites - Quick Start - Configuration - Security Hardening - clientState is the primary auth check - Source-IP allowlisting (production deployments) - HTTPS termination - Response hygiene - Troubleshooting - Related Docs ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Security Hardening Maps security hardening to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### clientState is the primary auth check Maps clientstate is the primary auth check to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Source-IP allowlisting (production deployments) Maps source-ip allowlisting (production deployments) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### HTTPS termination Maps https termination to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Response hygiene Maps response hygiene to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Quick Start, Configuration, Security Hardening, clientState is the primary auth check. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: microsoft, graph, webhook, listener, gateway. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for microsoft graph webhook listener before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## ntfy | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/ntfy/ | | Source | https://hermesbible.com/docs/user-guide/messaging/ntfy | | Section | Messaging Platforms | ### Summary ntfy ntfy is a simple HTTP based pub sub notification service. It works with the free public server at or any self hosted instance, and supports any client that ### Source outline - Prerequisites - Configure Hermes - Via setup wizard - Via environment variables - Identity model — read this before deploying - Quick start — talk to your agent from your phone - Using ntfy with cron jobs - Self-hosting ntfy - Markdown formatting - Outgoing-only setup (notifications without inbound) - Limits - Troubleshooting ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configure Hermes Maps configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Via setup wizard Maps via setup wizard to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Via environment variables Maps via environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Identity model — read this before deploying Maps identity model — read this before deploying to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Quick start — talk to your agent from your phone Maps quick start — talk to your agent from your phone to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Using ntfy with cron jobs Maps using ntfy with cron jobs to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Self-hosting ntfy Maps self-hosting ntfy to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Configure Hermes, Via setup wizard, Via environment variables, Identity model — read this before deploying. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: simple, based, notification, service., works. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for ntfy before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Configure Hermes if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Open WebUI | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/open-webui/ | | Source | https://hermesbible.com/docs/user-guide/messaging/open-webui | | Section | Messaging Platforms | ### Summary Open WebUI Integration Open WebUI (126k★) is the most popular self hosted chat interface for AI. With Hermes Agent's built in API server, you can use Open WebUI ### Source outline - Architecture - Quick Setup - One-command local bootstrap (macOS/Linux, no Docker) - 1. Enable the API server - 2. Start Hermes Agent gateway - 3. Verify the API server is reachable - 4. Start Open WebUI - 5. Open the UI - Docker Compose Setup - Configuring via the Admin UI - API Type: Chat Completions vs Responses - Using Chat Completions (recommended) - Using Responses API - How It Works ### Section map ### Architecture Maps architecture to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Quick Setup Maps quick setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### One-command local bootstrap (macOS/Linux, no Docker) Maps one-command local bootstrap (macos/linux, no docker) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 1. Enable the API server Maps 1. enable the api server to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 2. Start Hermes Agent gateway Maps 2. start hermes agent gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 3. Verify the API server is reachable Maps 3. verify the api server is reachable to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 4. Start Open WebUI Maps 4. start open webui to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 5. Open the UI Maps 5. open the ui to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Architecture, Quick Setup, One-command local bootstrap (macOS/Linux, no Docker), 1. Enable the API server, 2. Start Hermes Agent gateway. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: webui, integration, popular, hosted, interface. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for open webui before applying exact upstream commands. | | Verify first | Architecture | Open the source anchor for Architecture and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Architecture; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Photon iMessage | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/photon/ | | Source | https://hermesbible.com/docs/user-guide/messaging/photon | | Section | Messaging Platforms | ### Summary Photon iMessage Connect Hermes to iMessage through [Photon][photon], a managed service that handles the Apple line allocation and abuse prevention layer so you ### Source outline - Architecture - Prerequisites - First-time setup - Authorizing users - Require mentions in group chats - Start the gateway - Status & troubleshooting - Limits today - Env vars ### Section map ### Architecture Maps architecture to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### First-time setup Maps first-time setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Authorizing users Maps authorizing users to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Require mentions in group chats Maps require mentions in group chats to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Start the gateway Maps start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Status & troubleshooting Maps status & troubleshooting to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Limits today Maps limits today to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Architecture, Prerequisites, First-time setup, Authorizing users, Require mentions in group chats. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: photon, imessage, connect, through, managed. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for photon imessage before applying exact upstream commands. | | Verify first | Architecture | Open the source anchor for Architecture and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Architecture; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## QQ Bot | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/qqbot/ | | Source | https://hermesbible.com/docs/user-guide/messaging/qqbot | | Section | Messaging Platforms | ### Summary QQ Bot Connect Hermes to QQ via the Official QQ Bot API (v2) — supporting private (C2C), group @ mentions, guild, and direct messages with voice transcription. ### Source outline - Overview - Prerequisites - Configuration - Interactive setup - Manual configuration - Environment Variables - Advanced Configuration - Voice Messages (STT) - Troubleshooting - Bot disconnects immediately (quick disconnect) - Voice messages not transcribed - Messages not delivered - Connection errors ### Section map ### Overview Maps overview to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Interactive setup Maps interactive setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Manual configuration Maps manual configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Environment Variables Maps environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Advanced Configuration Maps advanced configuration to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Voice Messages (STT) Maps voice messages (stt) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Prerequisites, Configuration, Interactive setup, Manual configuration. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: connect, official, supporting, private, group. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for qq bot before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## SimpleX Chat | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/simplex/ | | Source | https://hermesbible.com/docs/user-guide/messaging/simplex | | Section | Messaging Platforms | ### Summary SimpleX Chat SimpleX Chat is a private, decentralised messaging platform where users own their contacts and groups. Unlike other platforms, SimpleX assigns no p ### Source outline - Prerequisites - Install simplex-chat - Start the daemon - Configure Hermes - Via setup wizard - Via environment variables - Find your contact ID or display name - Authorization - Group chats - Attachments - Using SimpleX with cron jobs - Privacy notes - Troubleshooting ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Install simplex-chat Maps install simplex-chat to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Start the daemon Maps start the daemon to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configure Hermes Maps configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Via setup wizard Maps via setup wizard to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Via environment variables Maps via environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Find your contact ID or display name Maps find your contact id or display name to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Authorization Maps authorization to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Install simplex-chat, Start the daemon, Configure Hermes, Via setup wizard. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: simplex, private, decentralised, messaging, platform. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for simplex chat before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Install simplex-chat if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Teams Meetings | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/teams-meetings/ | | Source | https://hermesbible.com/docs/user-guide/messaging/teams-meetings | | Section | Messaging Platforms | ### Summary Microsoft Teams Meetings Use the Teams meeting pipeline when you want Hermes to ingest Microsoft Graph meeting events, fetch transcripts first, fall back to rec ### Source outline - What This Feature Does - Prerequisites - Step 1: Add Microsoft Graph Credentials - Step 2: Enable the Graph Webhook Listener - Step 3: Configure Teams Delivery and Pipeline Behavior - Teams Delivery Modes - incoming_webhook - graph - Step 4: Start the Gateway - Step 5: Create Graph Subscriptions - Validation - Troubleshooting - Related Docs ### Section map ### What This Feature Does Maps what this feature does to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Add Microsoft Graph Credentials Maps step 1: add microsoft graph credentials to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Enable the Graph Webhook Listener Maps step 2: enable the graph webhook listener to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Configure Teams Delivery and Pipeline Behavior Maps step 3: configure teams delivery and pipeline behavior to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Teams Delivery Modes Maps teams delivery modes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### incoming_webhook Maps incoming_webhook to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### graph Maps graph to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What This Feature Does, Prerequisites, Step 1: Add Microsoft Graph Credentials, Step 2: Enable the Graph Webhook Listener, Step 3: Configure Teams Delivery and Pipeline Behavior. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: teams, meetings, microsoft, meeting, pipeline. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for teams meetings before applying exact upstream commands. | | Verify first | What This Feature Does | Open the source anchor for What This Feature Does and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for What This Feature Does; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Microsoft Teams | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/teams/ | | Source | https://hermesbible.com/docs/user-guide/messaging/teams | | Section | Messaging Platforms | ### Summary Microsoft Teams Setup Connect Hermes Agent to Microsoft Teams as a bot. Unlike Slack's Socket Mode, Teams delivers messages by calling a public HTTPS webhook , ### Source outline - How the Bot Responds - Step 1: Install the Teams CLI - Step 2: Expose the Webhook Port - Step 3: Create the Bot - Step 4: Configure Environment Variables - Step 5: Start the Gateway - Step 6: Install the App in Teams - Configuration Reference - Environment Variables - config.yaml - Features - Interactive Approval Cards - Meeting Summary Delivery (Teams Meeting Pipeline) - Production Deployment ### Section map ### How the Bot Responds Maps how the bot responds to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Install the Teams CLI Maps step 1: install the teams cli to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Expose the Webhook Port Maps step 2: expose the webhook port to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Create the Bot Maps step 3: create the bot to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 4: Configure Environment Variables Maps step 4: configure environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 5: Start the Gateway Maps step 5: start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 6: Install the App in Teams Maps step 6: install the app in teams to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Reference Maps configuration reference to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How the Bot Responds, Step 1: Install the Teams CLI, Step 2: Expose the Webhook Port, Step 3: Create the Bot, Step 4: Configure Environment Variables. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: microsoft, teams, setup, connect, unlike. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for microsoft teams before applying exact upstream commands. | | Verify first | How the Bot Responds | Open the source anchor for How the Bot Responds and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How the Bot Responds; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Install the Teams CLI if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## WeCom Callback (Self-Built App) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/wecom-callback/ | | Source | https://hermesbible.com/docs/user-guide/messaging/wecom-callback | | Section | Messaging Platforms | ### Summary WeCom Callback (Self Built App) Connect Hermes to WeCom (Enterprise WeChat) as a self built enterprise application using the callback/webhook model. INFO — WeCo ### Source outline - How It Works - Prerequisites - Setup - 1. Create a Self-Built App in WeCom - 2. Configure Environment Variables - 3. Start the Gateway - Configuration Reference - Multi-App Routing - Access Control - Endpoints - Encryption - Limitations - Troubleshooting ### Section map ### How It Works Maps how it works to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 1. Create a Self-Built App in WeCom Maps 1. create a self-built app in wecom to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 2. Configure Environment Variables Maps 2. configure environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 3. Start the Gateway Maps 3. start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Reference Maps configuration reference to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Multi-App Routing Maps multi-app routing to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How It Works, Prerequisites, Setup, 1. Create a Self-Built App in WeCom, 2. Configure Environment Variables. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: wecom, callback, self-built, connect, enterprise. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for wecom callback (self-built app) before applying exact upstream commands. | | Verify first | How It Works | Open the source anchor for How It Works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for How It Works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## WeCom (Enterprise WeChat) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/wecom/ | | Source | https://hermesbible.com/docs/user-guide/messaging/wecom | | Section | Messaging Platforms | ### Summary Connect Hermes to WeCom (企业微信), Tencent's enterprise messaging platform. The adapter uses WeCom's AI Bot WebSocket gateway for real time bidirectional communica ### Source outline - Prerequisites - Setup - Step 1: Create an AI Bot - Recommended: Scan-to-Create (one command) - Alternative: Manual Setup - Step 2: Configure Hermes - Option A: Interactive Setup (Recommended) - Option B: Manual Configuration - Step 3: Start the gateway - Features - Configuration Options - Access Policies - DM Policy - Group Policy ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create an AI Bot Maps step 1: create an ai bot to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 2: Configure Hermes Maps step 2: configure hermes to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Step 3: Start the gateway Maps step 3: start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Features Maps features to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Options Maps configuration options to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Access Policies Maps access policies to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Setup, Step 1: Create an AI Bot, Step 2: Configure Hermes, Step 3: Start the gateway. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: wecom, enterprise, wechat, connect, tencent. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for wecom (enterprise wechat) before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Weixin (WeChat) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/weixin/ | | Source | https://hermesbible.com/docs/user-guide/messaging/weixin | | Section | Messaging Platforms | ### Summary Connect Hermes to WeChat (微信), Tencent's personal messaging platform. The adapter uses Tencent's iLink Bot API for personal WeChat accounts — this is distinct f ### Source outline - Prerequisites - Setup - 1. Run the Setup Wizard - 2. Configure Environment Variables - 3. Start the Gateway - Features - Configuration Options - Access Policies - DM Policy - Group Policy - Media Support - Inbound (receiving) - AES-128-ECB Encrypted CDN - Outbound (sending) ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 1. Run the Setup Wizard Maps 1. run the setup wizard to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 2. Configure Environment Variables Maps 2. configure environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 3. Start the Gateway Maps 3. start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Features Maps features to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Options Maps configuration options to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Access Policies Maps access policies to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Setup, 1. Run the Setup Wizard, 2. Configure Environment Variables, 3. Start the Gateway. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: weixin, wechat, connect, tencent, personal. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for weixin (wechat) before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## WhatsApp Business (Cloud API) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/whatsapp-cloud/ | | Source | https://hermesbible.com/docs/user-guide/messaging/whatsapp-cloud | | Section | Messaging Platforms | ### Summary WhatsApp Business Cloud API Setup Hermes can connect to WhatsApp through Meta's official WhatsApp Business Cloud API. This is the production grade path: no Node ### Source outline - Quick start - Prerequisites - Creating the Meta app - Permanent token (production) - Exposing Hermes to the internet - Cloudflare Tunnel (recommended) - ngrok - Your own domain + reverse proxy - Configuring the webhook on Meta's side - Recipient whitelist (Meta-side) - Allowlist (Hermes-side) - Polishing your bot's WhatsApp profile - Configuration reference - Features ### Section map ### Quick start Maps quick start to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Creating the Meta app Maps creating the meta app to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Permanent token (production) Maps permanent token (production) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Exposing Hermes to the internet Maps exposing hermes to the internet to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Cloudflare Tunnel (recommended) Maps cloudflare tunnel (recommended) to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### ngrok Maps ngrok to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Your own domain + reverse proxy Maps your own domain + reverse proxy to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick start, Prerequisites, Creating the Meta app, Permanent token (production), Exposing Hermes to the internet. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: whatsapp, business, cloud, setup, connect. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for whatsapp business (cloud api) before applying exact upstream commands. | | Verify first | Quick start | Open the source anchor for Quick start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Quick start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Yuanbao | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/messaging/yuanbao/ | | Source | https://hermesbible.com/docs/user-guide/messaging/yuanbao | | Section | Messaging Platforms | ### Summary Connect Hermes to Yuanbao, Tencent's enterprise messaging platform. The adapter uses a WebSocket gateway for real time message delivery and supports both direct ### Source outline - Prerequisites - Setup - 1. Create a Bot in Yuanbao - 2. Run the Setup Wizard - 3. Configure Environment Variables - 4. Start the Gateway - Features - Configuration Options - Chat ID Formats - Media Uploads - Home Channel - Example: Set Home Channel - Example: Cron Job Delivery - Usage Tips ### Section map ### Prerequisites Maps prerequisites to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 1. Create a Bot in Yuanbao Maps 1. create a bot in yuanbao to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 2. Run the Setup Wizard Maps 2. run the setup wizard to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 3. Configure Environment Variables Maps 3. configure environment variables to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### 4. Start the Gateway Maps 4. start the gateway to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Features Maps features to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Configuration Options Maps configuration options to the Messaging Platforms documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Messaging Platforms doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Setup, 1. Create a Bot in Yuanbao, 2. Run the Setup Wizard, 3. Configure Environment Variables. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: yuanbao, connect, tencent, enterprise, messaging. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Messaging Platforms documentation | Use when you need orientation for yuanbao before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Messaging Platforms, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Secrets ## Bitwarden Secrets Manager | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/secrets/bitwarden/ | | Source | https://hermesbible.com/docs/user-guide/secrets/bitwarden | | Section | Secrets | ### Summary Bitwarden Secrets Manager Pull API keys from Bitwarden Secrets Manager at process startup instead of storing them in plaintext inside . One bootstrap secret (a ### Source outline - How it works - Why machine accounts (and why no 2FA prompt) - Setup - 1. Create a machine account and access token - 2. Run the wizard - 3. Confirm - CLI - Configuration - Failure modes - Security notes - When NOT to use this ### Section map ### How it works Maps how it works to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Why machine accounts (and why no 2FA prompt) Maps why machine accounts (and why no 2fa prompt) to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Secrets documentation path, with the source page reserved for exact commands and updates. ### 1. Create a machine account and access token Maps 1. create a machine account and access token to the Secrets documentation path, with the source page reserved for exact commands and updates. ### 2. Run the wizard Maps 2. run the wizard to the Secrets documentation path, with the source page reserved for exact commands and updates. ### 3. Confirm Maps 3. confirm to the Secrets documentation path, with the source page reserved for exact commands and updates. ### CLI Maps cli to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Secrets doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How it works, Why machine accounts (and why no 2FA prompt), Setup, 1. Create a machine account and access token, 2. Run the wizard. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: bitwarden, secrets, manager, process, startup. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Secrets documentation | Use when you need orientation for bitwarden secrets manager before applying exact upstream commands. | | Verify first | How it works | Open the source anchor for How it works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Secrets, then open the linked source page for exact current syntax. - Start with the source section for How it works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Why machine accounts (and why no 2FA prompt) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Secrets | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/secrets/index/ | | Source | https://hermesbible.com/docs/user-guide/secrets/index | | Section | Secrets | ### Summary Secrets Hermes can pull API keys from external secret managers at process startup instead of storing them in . The bootstrap token for the secret manager lives ### Section map ### Secrets Maps secrets to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Setup context Maps setup context to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Operational notes Maps operational notes to the Secrets documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Secrets doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Secrets. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: secrets, external, secret, managers, process. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Secrets documentation | Use when you need orientation for secrets before applying exact upstream commands. | | Verify first | Secrets | Open the source anchor for Secrets and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Secrets, then open the linked source page for exact current syntax. - Start with the source section for Secrets; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for source details if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Skills ## Google Workspace — Gmail, Calendar, Drive, Sheets & Docs | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/skills/google-workspace/ | | Source | https://hermesbible.com/docs/user-guide/skills/google-workspace | | Section | Skills | ### Summary Google Workspace Skill Gmail, Calendar, Drive, Contacts, Sheets, and Docs integration for Hermes. Uses OAuth2 with automatic token refresh. Prefers the Google W ### Source outline - Setup - Gmail - Searching - Reading - Sending - Custom From Header - Replying - Labels - Calendar - Drive - Sheets - Docs - Contacts - Output Format ### Section map ### Setup Maps setup to the Skills documentation path, with the source page reserved for exact commands and updates. ### Gmail Maps gmail to the Skills documentation path, with the source page reserved for exact commands and updates. ### Searching Maps searching to the Skills documentation path, with the source page reserved for exact commands and updates. ### Reading Maps reading to the Skills documentation path, with the source page reserved for exact commands and updates. ### Sending Maps sending to the Skills documentation path, with the source page reserved for exact commands and updates. ### Custom From Header Maps custom from header to the Skills documentation path, with the source page reserved for exact commands and updates. ### Replying Maps replying to the Skills documentation path, with the source page reserved for exact commands and updates. ### Labels Maps labels to the Skills documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Skills doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Setup, Gmail, Searching, Reading, Sending. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: google, workspace, gmail, calendar, drive. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Skills documentation | Use when you need orientation for google workspace — gmail, calendar, drive, sheets & docs before applying exact upstream commands. | | Verify first | Setup | Open the source anchor for Setup and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Skills, then open the linked source page for exact current syntax. - Start with the source section for Setup; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Gmail if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Using Hermes ## CLI Interface | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/cli/ | | Source | https://hermesbible.com/docs/user-guide/cli | | Section | Using Hermes | ### Summary Hermes Agent's CLI is a full terminal user interface (TUI) — not a web UI. It features multiline editing, slash command autocomplete, conversation history, inte ### Source outline - Running the CLI - Interface Layout - Status Bar - Session Resume Display - Keybindings - Slash Commands - Quick Commands - Preloading Skills at Launch - Skill Slash Commands - Personalities - Multi-line Input - Shift+Enter compatibility - Interrupting the Agent - Busy Input Mode ### Section map ### Running the CLI Maps running the cli to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Interface Layout Maps interface layout to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Status Bar Maps status bar to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Session Resume Display Maps session resume display to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Keybindings Maps keybindings to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Slash Commands Maps slash commands to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Quick Commands Maps quick commands to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Preloading Skills at Launch Maps preloading skills at launch to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Running the CLI, Interface Layout, Status Bar, Session Resume Display, Keybindings. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: interface, terminal, features, multiline, editing. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for cli interface before applying exact upstream commands. | | Verify first | Running the CLI | Open the source anchor for Running the CLI and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Running the CLI; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Interface Layout if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## TUI | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/tui/ | | Source | https://hermesbible.com/docs/user-guide/tui | | Section | Using Hermes | ### Summary The TUI is the modern front end for Hermes — a terminal UI backed by the same Python runtime as the Classic CLI. Same agent, same sessions, same slash commands; ### Source outline - Launch - Why the TUI - Collapsible banner sections - Requirements - External prebuild - Keybindings - Slash commands - Live session switcher - LaTeX math rendering - Light-terminal detection - Busy indicator styles - Auto-resume - Status line - Configuration ### Section map ### Launch Maps launch to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Why the TUI Maps why the tui to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Collapsible banner sections Maps collapsible banner sections to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Requirements Maps requirements to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### External prebuild Maps external prebuild to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Keybindings Maps keybindings to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Slash commands Maps slash commands to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Live session switcher Maps live session switcher to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Launch, Why the TUI, Collapsible banner sections, Requirements, External prebuild. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: modern, front, terminal, backed, python. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for tui before applying exact upstream commands. | | Verify first | Launch | Open the source anchor for Launch and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Launch; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Why the TUI if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Configuration | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/configuration/ | | Source | https://hermesbible.com/docs/user-guide/configuration | | Section | Using Hermes | ### Summary All settings are stored in the directory for easy access. TIP — Easiest path to a working Run — one OAuth gets you a model provider and all four Tool Gateway to ### Source outline - Directory Structure - Managing Configuration - Configuration Precedence - Environment Variable Substitution - Provider Timeouts - Update Behavior - Terminal Backend Configuration - Backend Overview - Local Backend - terminal.home_mode - Docker Backend - Container lifecycle - Environment variable overrides - SSH Backend ### Section map ### Directory Structure Maps directory structure to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Managing Configuration Maps managing configuration to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Configuration Precedence Maps configuration precedence to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Environment Variable Substitution Maps environment variable substitution to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Provider Timeouts Maps provider timeouts to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Update Behavior Maps update behavior to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Terminal Backend Configuration Maps terminal backend configuration to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Backend Overview Maps backend overview to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Directory Structure, Managing Configuration, Configuration Precedence, Environment Variable Substitution, Provider Timeouts. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: configuration, settings, stored, directory, access.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for configuration before applying exact upstream commands. | | Verify first | Directory Structure | Open the source anchor for Directory Structure and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Directory Structure; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Managing Configuration if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Configuring Models | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/configuring-models/ | | Source | https://hermesbible.com/docs/user-guide/configuring-models | | Section | Using Hermes | ### Summary Configuring Models Hermes uses two kinds of model slots: Main model — what the agent thinks with. Every user message, every tool call loop, every streamed respo ### Source outline - The Models page - Setting the main model - Setting auxiliary models - Common override patterns - Per-task override - Reset all to auto - The "Use as" shortcut - What gets written to config.yaml - When does it take effect? - Troubleshooting - "No authenticated providers" in the picker - Main model didn't change in my running chat - Auxiliary override "didn't take effect" - I picked a model but Hermes switched providers on me ### Section map ### The Models page Maps the models page to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Setting the main model Maps setting the main model to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Setting auxiliary models Maps setting auxiliary models to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Common override patterns Maps common override patterns to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Per-task override Maps per-task override to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Reset all to auto Maps reset all to auto to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### The "Use as" shortcut Maps the "use as" shortcut to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### What gets written to config.yaml Maps what gets written to config.yaml to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: The Models page, Setting the main model, Setting auxiliary models, Common override patterns, Per-task override. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: configuring, models, kinds, model, slots. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for configuring models before applying exact upstream commands. | | Verify first | The Models page | Open the source anchor for The Models page and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for The Models page; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Setting the main model if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Sessions | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/sessions/ | | Source | https://hermesbible.com/docs/user-guide/sessions | | Section | Using Hermes | ### Summary Hermes Agent automatically saves every conversation as a session. Sessions enable conversation resume, cross session search, and full conversation history manag ### Source outline - How Sessions Work - What Counts Toward Context - Session Sources - CLI Session Resume - Continue Last Session - Resume by Name - Resume Specific Session - Conversation Recap on Resume - Cross-Platform Handoff - Session Naming - Auto-Generated Titles - Setting a Title Manually - Title Rules - Auto-Lineage on Compression ### Section map ### How Sessions Work Maps how sessions work to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### What Counts Toward Context Maps what counts toward context to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Session Sources Maps session sources to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### CLI Session Resume Maps cli session resume to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Continue Last Session Maps continue last session to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Resume by Name Maps resume by name to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Resume Specific Session Maps resume specific session to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Conversation Recap on Resume Maps conversation recap on resume to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Sessions Work, What Counts Toward Context, Session Sources, CLI Session Resume, Continue Last Session. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: sessions, automatically, saves, every, conversation. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for sessions before applying exact upstream commands. | | Verify first | How Sessions Work | Open the source anchor for How Sessions Work and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for How Sessions Work; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What Counts Toward Context if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Profiles: Running Multiple Agents | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/profiles/ | | Source | https://hermesbible.com/docs/user-guide/profiles | | Section | Using Hermes | ### Summary Profiles: Running Multiple Agents Run multiple independent Hermes agents on the same machine — each with its own config, API keys, memory, sessions, skills, and ### Source outline - What are profiles? - Quick start - Creating a profile - Blank profile - Clone config only (--clone) - Clone everything (--clone-all) - Clone from a specific profile - Using profiles - Command aliases - The -p flag - Sticky default (hermes profile use) - Knowing where you are - Profiles vs workspaces vs sandboxing - Running gateways ### Section map ### What are profiles? Maps what are profiles? to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Quick start Maps quick start to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Creating a profile Maps creating a profile to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Blank profile Maps blank profile to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Clone config only (--clone) Maps clone config only (--clone) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Clone everything (--clone-all) Maps clone everything (--clone-all) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Clone from a specific profile Maps clone from a specific profile to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Using profiles Maps using profiles to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What are profiles?, Quick start, Creating a profile, Blank profile, Clone config only (--clone). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: profiles, running, multiple, agents, independent. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for profiles: running multiple agents before applying exact upstream commands. | | Verify first | What are profiles? | Open the source anchor for What are profiles? and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for What are profiles?; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Git Worktrees | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/git-worktrees/ | | Source | https://hermesbible.com/docs/user-guide/git-worktrees | | Section | Using Hermes | ### Summary Hermes Agent is often used on large, long‑lived repositories. When you want to: Run multiple agents in parallel on the same project, or Keep experimental refact ### Source outline - Why Use Worktrees with Hermes? - Quick Start: Creating a Worktree - Running Multiple Agents in Parallel - Cleaning Up Worktrees Safely - Best Practices - Using hermes -w (Automatic Worktree Mode) - Putting It All Together ### Section map ### Why Use Worktrees with Hermes? Maps why use worktrees with hermes? to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Quick Start: Creating a Worktree Maps quick start: creating a worktree to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Running Multiple Agents in Parallel Maps running multiple agents in parallel to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Cleaning Up Worktrees Safely Maps cleaning up worktrees safely to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Best Practices Maps best practices to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Using hermes -w (Automatic Worktree Mode) Maps using hermes -w (automatic worktree mode) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Putting It All Together Maps putting it all together to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Why Use Worktrees with Hermes?, Quick Start: Creating a Worktree, Running Multiple Agents in Parallel, Cleaning Up Worktrees Safely, Best Practices. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: worktrees, often, large, lived, repositories.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for git worktrees before applying exact upstream commands. | | Verify first | Why Use Worktrees with Hermes? | Open the source anchor for Why Use Worktrees with Hermes? and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Why Use Worktrees with Hermes?; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start: Creating a Worktree if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Docker | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/docker/ | | Source | https://hermesbible.com/docs/user-guide/docker | | Section | Using Hermes | ### Summary Hermes Agent — Docker There are two distinct ways Docker intersects with Hermes Agent: 1. Running Hermes IN Docker — the agent itself runs inside a container (t ### Source outline - Quick start - Running in gateway mode - Running the dashboard - Running interactively (CLI chat) - Persistent volumes - Multi-profile support - Reaching more than one profile from outside the container - Why one container with many profiles, not many containers - When you DO want a separate container - Where the logs go - Environment variable forwarding - Docker Compose example - Optional: Linux desktop audio bridge - Resource limits ### Section map ### Quick start Maps quick start to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Running in gateway mode Maps running in gateway mode to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Running the dashboard Maps running the dashboard to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Running interactively (CLI chat) Maps running interactively (cli chat) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Persistent volumes Maps persistent volumes to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Multi-profile support Maps multi-profile support to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Reaching more than one profile from outside the container Maps reaching more than one profile from outside the container to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Why one container with many profiles, not many containers Maps why one container with many profiles, not many containers to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick start, Running in gateway mode, Running the dashboard, Running interactively (CLI chat), Persistent volumes. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: docker, there, distinct, intersects, running. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for docker before applying exact upstream commands. | | Verify first | Quick start | Open the source anchor for Quick start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Quick start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Running in gateway mode if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Security | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/security/ | | Source | https://hermesbible.com/docs/user-guide/security | | Section | Using Hermes | ### Summary Hermes Agent is designed with a defense in depth security model. This page covers every security boundary — from command approval to container isolation to user ### Source outline - Overview - Dangerous Command Approval - Approval Modes - YOLO Mode - Hardline Blocklist (Always-On Floor) - Approval Timeout - What Triggers Approval - Approval Flow (CLI) - Approval Flow (Gateway/Messaging) - Permanent Allowlist - User Authorization (Gateway) - Authorization Check Order - Platform Allowlists - DM Pairing System ### Section map ### Overview Maps overview to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Dangerous Command Approval Maps dangerous command approval to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Approval Modes Maps approval modes to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### YOLO Mode Maps yolo mode to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Hardline Blocklist (Always-On Floor) Maps hardline blocklist (always-on floor) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Approval Timeout Maps approval timeout to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### What Triggers Approval Maps what triggers approval to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Approval Flow (CLI) Maps approval flow (cli) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Dangerous Command Approval, Approval Modes, YOLO Mode, Hardline Blocklist (Always-On Floor). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: security, designed, defense, depth, model.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for security before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Dangerous Command Approval if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Checkpoints and /rollback | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/checkpoints-and-rollback/ | | Source | https://hermesbible.com/docs/user-guide/checkpoints-and-rollback | | Section | Using Hermes | ### Summary Checkpoints and Hermes Agent can automatically snapshot your project before destructive operations and restore it with a single command. Checkpoints are opt in ### Source outline - What Triggers a Checkpoint - Quick Reference - How Checkpoints Work - Configuration - Listing Checkpoints - Inspecting the Store from the Shell - Previewing Changes with /rollback diff - Restoring with /rollback - Single-File Restore - Safety and Performance Guards - Where Checkpoints Live - Migration from v1 - Best Practices ### Section map ### What Triggers a Checkpoint Maps what triggers a checkpoint to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Quick Reference Maps quick reference to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### How Checkpoints Work Maps how checkpoints work to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Listing Checkpoints Maps listing checkpoints to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Inspecting the Store from the Shell Maps inspecting the store from the shell to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Previewing Changes with /rollback diff Maps previewing changes with /rollback diff to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Restoring with /rollback Maps restoring with /rollback to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What Triggers a Checkpoint, Quick Reference, How Checkpoints Work, Configuration, Listing Checkpoints. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: checkpoints, /rollback, automatically, snapshot, project. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for checkpoints and /rollback before applying exact upstream commands. | | Verify first | What Triggers a Checkpoint | Open the source anchor for What Triggers a Checkpoint and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for What Triggers a Checkpoint; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Reference if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Desktop App | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/desktop/ | | Source | https://hermesbible.com/docs/user-guide/desktop | | Section | Using Hermes | ### Summary The Hermes desktop app is a native app built around the same agent you get from the CLI and the gateway — same config, same API keys, same sessions, same skills ### Source outline - Install - What's in the app - Chat - Status bar - Choosing a model - File browser - Voice - Settings & onboarding - Management panes - Keyboard & navigation - Sessions & profiles - Updating - Uninstalling - CLI reference: hermes desktop ### Section map ### Install Maps install to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### What's in the app Maps what's in the app to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Chat Maps chat to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### File browser Maps file browser to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Voice Maps voice to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Settings & onboarding Maps settings & onboarding to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Management panes Maps management panes to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Keyboard & navigation Maps keyboard & navigation to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Install, What's in the app, Chat, File browser, Voice. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: desktop, native, around, gateway, config. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for desktop app before applying exact upstream commands. | | Verify first | Install | Open the source anchor for Install and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Install; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What's in the app if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Running Many Gateways at Once | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/multi-profile-gateways/ | | Source | https://hermesbible.com/docs/user-guide/multi-profile-gateways | | Section | Using Hermes | ### Summary Running Many Gateways at Once Operate multiple profiles — each with its own bot tokens, sessions, and memory — as managed services on a single machine. This pag ### Source outline - When to use this - Quick start - Start, stop, or restart all gateways at once - Manage one profile - Service files - Viewing logs - Identify what's actually running - Editing configuration - Keeping the host awake - macOS — caffeinate - Linux — systemd-inhibit or loginctl - Token-conflict safety - Updating the code - Troubleshooting ### Section map ### When to use this Maps when to use this to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Quick start Maps quick start to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Start, stop, or restart all gateways at once Maps start, stop, or restart all gateways at once to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Manage one profile Maps manage one profile to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Service files Maps service files to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Viewing logs Maps viewing logs to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Identify what's actually running Maps identify what's actually running to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Editing configuration Maps editing configuration to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: When to use this, Quick start, Start, stop, or restart all gateways at once, Manage one profile, Service files. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: running, gateways, operate, multiple, profiles. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for running many gateways at once before applying exact upstream commands. | | Verify first | When to use this | Open the source anchor for When to use this and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for When to use this; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Profile Distributions: Share a Whole Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/profile-distributions/ | | Source | https://hermesbible.com/docs/user-guide/profile-distributions | | Section | Using Hermes | ### Summary Profile Distributions: Share a Whole Agent A profile distribution packages a complete Hermes agent — personality, skills, cron jobs, MCP connections, config — a ### Source outline - What this means - Why git? - When should you use a distribution? - The lifecycle: author to installer to update - For authors: publishing a distribution - Step 1 — Start from a working profile - Step 2 — Add a distribution.yaml - Step 3 — Push to a git repo - Step 4 — Tag versioned releases - What the repo looks like - Distribution-owned vs user-owned - For installers: using a distribution - Install - Source types ### Section map ### What this means Maps what this means to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Why git? Maps why git? to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### When should you use a distribution? Maps when should you use a distribution? to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### The lifecycle: author to installer to update Maps the lifecycle: author to installer to update to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### For authors: publishing a distribution Maps for authors: publishing a distribution to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Step 1 — Start from a working profile Maps step 1 — start from a working profile to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Step 2 — Add a distribution.yaml Maps step 2 — add a distribution.yaml to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Step 3 — Push to a git repo Maps step 3 — push to a git repo to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What this means, Why git?, When should you use a distribution?, The lifecycle: author to installer to update, For authors: publishing a distribution. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: profile, distributions, share, whole, distribution. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for profile distributions: share a whole agent before applying exact upstream commands. | | Verify first | What this means | Open the source anchor for What this means and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for What this means; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Why git? if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Windows (Native) Guide | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/windows-native/ | | Source | https://hermesbible.com/docs/user-guide/windows-native | | Section | Using Hermes | ### Summary Hermes runs natively on Windows 10 and Windows 11 — no WSL, no Cygwin, no Docker. This page is the deep dive: what works natively, what's WSL only, what the ins ### Source outline - Quick install - Desktop installer (alternative) - Dependency bootstrap (dep_ensure) - What the installer actually does - Feature matrix - How Hermes runs shell commands on Windows - UTF-8 console on Windows - The editor (Ctrl-X Ctrl-E, /edit) - Ctrl+Enter for newline in the CLI - Running the gateway at Windows login - Install - Manage - Why not a Windows Service? - Data layout ### Section map ### Quick install Maps quick install to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Desktop installer (alternative) Maps desktop installer (alternative) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Dependency bootstrap (dep_ensure) Maps dependency bootstrap (dep_ensure) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### What the installer actually does Maps what the installer actually does to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Feature matrix Maps feature matrix to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### How Hermes runs shell commands on Windows Maps how hermes runs shell commands on windows to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### UTF-8 console on Windows Maps utf-8 console on windows to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### The editor (Ctrl-X Ctrl-E, /edit) Maps the editor (ctrl-x ctrl-e, /edit) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick install, Desktop installer (alternative), Dependency bootstrap (dep_ensure), What the installer actually does, Feature matrix. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: windows, native, natively, cygwin, docker.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for windows (native) guide before applying exact upstream commands. | | Verify first | Quick install | Open the source anchor for Quick install and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Quick install; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Desktop installer (alternative) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Windows (WSL2) Guide | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/user-guide/windows-wsl-quickstart/ | | Source | https://hermesbible.com/docs/user-guide/windows-wsl-quickstart | | Section | Using Hermes | ### Summary Hermes Agent now supports both native Windows and WSL2. This page covers the WSL2 path; for the native PowerShell install see the dedicated Windows (Native) Gui ### Source outline - Why WSL2 (vs. native Windows) - Install WSL2 - Distro choice - Enable systemd (recommended) - Install Hermes inside WSL - Filesystem: crossing the Windows ↔ WSL2 boundary - The two directions - Where to put Hermes and your projects - Getting files back and forth - Line endings, BOMs, and git - "Clone inside WSL or on /mnt/c?" - Networking: WSL ↔ Windows - Case 1 — Hermes in WSL talks to a service on Windows - Case 2 — Something on Windows (or your LAN) talks to Hermes in WSL ### Section map ### Why WSL2 (vs. native Windows) Maps why wsl2 (vs. native windows) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Install WSL2 Maps install wsl2 to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Distro choice Maps distro choice to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Enable systemd (recommended) Maps enable systemd (recommended) to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Install Hermes inside WSL Maps install hermes inside wsl to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Filesystem: crossing the Windows ↔ WSL2 boundary Maps filesystem: crossing the windows ↔ wsl2 boundary to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### The two directions Maps the two directions to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Where to put Hermes and your projects Maps where to put hermes and your projects to the Using Hermes documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Using Hermes doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Why WSL2 (vs. native Windows), Install WSL2, Distro choice, Enable systemd (recommended), Install Hermes inside WSL. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: windows, supports, native, wsl2., covers. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Using Hermes documentation | Use when you need orientation for windows (wsl2) guide before applying exact upstream commands. | | Verify first | Why WSL2 (vs. native Windows) | Open the source anchor for Why WSL2 (vs. native Windows) and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Using Hermes, then open the linked source page for exact current syntax. - Start with the source section for Why WSL2 (vs. native Windows); do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Install WSL2 if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Integrations ## Integrations | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/integrations/index/ | | Source | https://hermesbible.com/docs/integrations/index | | Section | Integrations | ### Summary Hermes Agent connects to external systems for AI inference, tool servers, IDE workflows, programmatic access, and more. These integrations extend what Hermes ca ### Source outline - AI Providers & Routing - Tool Servers (MCP) - Web Search Backends - Browser Automation - Voice & TTS Providers - IDE & Editor Integration - Programmatic Access - Memory & Personalization - Messaging Platforms - Home Automation - Plugins - Training & Evaluation ### Section map ### AI Providers & Routing Maps ai providers & routing to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Tool Servers (MCP) Maps tool servers (mcp) to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Web Search Backends Maps web search backends to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Browser Automation Maps browser automation to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Voice & TTS Providers Maps voice & tts providers to the Integrations documentation path, with the source page reserved for exact commands and updates. ### IDE & Editor Integration Maps ide & editor integration to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Programmatic Access Maps programmatic access to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Memory & Personalization Maps memory & personalization to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Integrations doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: AI Providers & Routing, Tool Servers (MCP), Web Search Backends, Browser Automation, Voice & TTS Providers. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: integrations, connects, external, systems, inference. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Integrations documentation | Use when you need orientation for integrations before applying exact upstream commands. | | Verify first | AI Providers & Routing | Open the source anchor for AI Providers & Routing and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Integrations, then open the linked source page for exact current syntax. - Start with the source section for AI Providers & Routing; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Tool Servers (MCP) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## AI Providers | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/integrations/providers/ | | Source | https://hermesbible.com/docs/integrations/providers | | Section | Integrations | ### Summary This page covers setting up inference providers for Hermes Agent — from cloud APIs like OpenRouter and Anthropic, to self hosted endpoints like Ollama and vLLM, ### Source outline - Inference Providers - Nous Portal - Two Commands for Model Management - Anthropic (Native) - GitHub Copilot - First-Class API-Key Providers - xAI (Grok) — Responses API + Prompt Caching - NovitaAI - Ollama Cloud — Managed Ollama Models, OAuth + API Key - AWS Bedrock - Qwen Portal (OAuth) - Alibaba Cloud (Coding Plan) - MiniMax (OAuth) - NVIDIA NIM ### Section map ### Inference Providers Maps inference providers to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Nous Portal Maps nous portal to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Two Commands for Model Management Maps two commands for model management to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Anthropic (Native) Maps anthropic (native) to the Integrations documentation path, with the source page reserved for exact commands and updates. ### GitHub Copilot Maps github copilot to the Integrations documentation path, with the source page reserved for exact commands and updates. ### First-Class API-Key Providers Maps first-class api-key providers to the Integrations documentation path, with the source page reserved for exact commands and updates. ### xAI (Grok) — Responses API + Prompt Caching Maps xai (grok) — responses api + prompt caching to the Integrations documentation path, with the source page reserved for exact commands and updates. ### NovitaAI Maps novitaai to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Integrations doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Inference Providers, Nous Portal, Two Commands for Model Management, Anthropic (Native), GitHub Copilot. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: providers, covers, setting, inference, cloud. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Integrations documentation | Use when you need orientation for ai providers before applying exact upstream commands. | | Verify first | Inference Providers | Open the source anchor for Inference Providers and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Integrations, then open the linked source page for exact current syntax. - Start with the source section for Inference Providers; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Nous Portal if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Nous Portal | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/integrations/nous-portal/ | | Source | https://hermesbible.com/docs/integrations/nous-portal | | Section | Integrations | ### Summary Nous Portal is Nous Research's unified subscription gateway and the recommended way to run Hermes Agent . One OAuth login replaces the juggling act of separate ### Source outline - What's in the subscription - 300+ frontier models, one bill - The Nous Tool Gateway - Nous Chat - No credentials in your dotfiles - Cross-platform parity - A note on Hermes 4 - Setup - Fresh install — one command - Existing install — add Portal alongside other providers - Headless / SSH / remote setup - Profile setup - Using the Portal day-to-day - Inspecting what's wired up ### Section map ### What's in the subscription Maps what's in the subscription to the Integrations documentation path, with the source page reserved for exact commands and updates. ### 300+ frontier models, one bill Maps 300+ frontier models, one bill to the Integrations documentation path, with the source page reserved for exact commands and updates. ### The Nous Tool Gateway Maps the nous tool gateway to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Nous Chat Maps nous chat to the Integrations documentation path, with the source page reserved for exact commands and updates. ### No credentials in your dotfiles Maps no credentials in your dotfiles to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Cross-platform parity Maps cross-platform parity to the Integrations documentation path, with the source page reserved for exact commands and updates. ### A note on Hermes 4 Maps a note on hermes 4 to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Setup Maps setup to the Integrations documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Integrations doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What's in the subscription, 300+ frontier models, one bill, The Nous Tool Gateway, Nous Chat, No credentials in your dotfiles. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: portal, research, unified, subscription, gateway. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Integrations documentation | Use when you need orientation for nous portal before applying exact upstream commands. | | Verify first | What's in the subscription | Open the source anchor for What's in the subscription and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Integrations, then open the linked source page for exact current syntax. - Start with the source section for What's in the subscription; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for 300+ frontier models, one bill if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Hermes Paperclip Adapter | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/integrations/paperclip-adapter/ | | Source | https://github.com/NousResearch/hermes-paperclip-adapter | | Section | Integrations | ### Summary Official NousResearch adapter repository for connecting Hermes Agent with Paperclip. Use it when you need the current adapter source, README, installation notes, and compatibility boundary before wiring Paperclip into a Hermes workflow. ### Source outline - Repository source - Adapter boundary - Verification checklist ### Section map ### Repository source Start from the official NousResearch GitHub repository and README before installing or copying commands. Treat the repository as the source of truth for current setup details. ### Adapter boundary This page indexes the adapter as a Hermes integration surface. Verify supported Paperclip versions, configuration files, and runtime assumptions in the repository before using it in production. ### Implementation notes - Review the repository README and file tree before connecting the adapter to a real Hermes workspace. - Keep credentials, workspace paths, and Paperclip-specific configuration out of committed files. - Run the adapter against a disposable test workspace before granting access to production documents or automations. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Use the adapter | You need Hermes Agent to interact with Paperclip through the official NousResearch integration path. | Use the GitHub README as the installation source and add a local smoke check before production use. | | Wait | The README, release notes, or local environment do not clarify the required Paperclip runtime or credentials. | Open an issue or test in a disposable environment before connecting sensitive data. | ### Verification checklist - Open the official NousResearch/hermes-paperclip-adapter repository. - Confirm install commands and runtime requirements from the current README. - Verify the adapter in a disposable Paperclip workspace. - Document which credentials and files the adapter can access. ### Risk notes | Risk | Note | | --- | --- | | Integration drift | Adapter setup can change independently of Hermes Agent core docs; re-check the repository before copying commands. | | Workspace access | Paperclip integrations may touch document or project state. Start with least-privilege test data. | --- # Guides & Tutorials ## Tips & Best Practices | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/tips/ | | Source | https://hermesbible.com/docs/guides/tips | | Section | Guides & Tutorials | ### Summary A quick wins collection of practical tips that make you immediately more effective with Hermes Agent. Each section targets a different aspect — scan the headers ### Source outline - Getting the Best Results - Be Specific About What You Want - Provide Context Up Front - Use Context Files for Recurring Instructions - Let the Agent Use Its Tools - Use Skills for Complex Workflows - CLI Power User Tips - Multi-Line Input - Paste Detection - Interrupt and Redirect - Resume Sessions with -c - Clipboard Image Paste - Slash Command Autocomplete - Context Files ### Section map ### Getting the Best Results Maps getting the best results to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Be Specific About What You Want Maps be specific about what you want to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Provide Context Up Front Maps provide context up front to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Use Context Files for Recurring Instructions Maps use context files for recurring instructions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Let the Agent Use Its Tools Maps let the agent use its tools to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Use Skills for Complex Workflows Maps use skills for complex workflows to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### CLI Power User Tips Maps cli power user tips to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Multi-Line Input Maps multi-line input to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Getting the Best Results, Be Specific About What You Want, Provide Context Up Front, Use Context Files for Recurring Instructions, Let the Agent Use Its Tools. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: practices, quick, collection, practical, immediately. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for tips & best practices before applying exact upstream commands. | | Verify first | Getting the Best Results | Open the source anchor for Getting the Best Results and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Getting the Best Results; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Be Specific About What You Want if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Run Local LLMs on Mac | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/local-llm-on-mac/ | | Source | https://hermesbible.com/docs/guides/local-llm-on-mac | | Section | Guides & Tutorials | ### Summary This guide walks you through running a local LLM server on macOS with an OpenAI compatible API. You get full privacy, zero API costs, and surprisingly good perf ### Source outline - Choosing a model - Option A: llama.cpp - Install - Download the model - Start the server - Memory optimization for constrained systems - Test it - Get the model name - Option B: MLX via omlx - Install - Download the model - Start the server - Test it - List available models ### Section map ### Choosing a model Maps choosing a model to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Option A: llama.cpp Maps option a: llama.cpp to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Install Maps install to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Download the model Maps download the model to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Start the server Maps start the server to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Memory optimization for constrained systems Maps memory optimization for constrained systems to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Test it Maps test it to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Get the model name Maps get the model name to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Choosing a model, Option A: llama.cpp, Install, Download the model, Start the server. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: local, walks, through, running, server. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for run local llms on mac before applying exact upstream commands. | | Verify first | Choosing a model | Open the source anchor for Choosing a model and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Choosing a model; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Option A: llama.cpp if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Tutorial: Daily Briefing Bot | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/daily-briefing-bot/ | | Source | https://hermesbible.com/docs/guides/daily-briefing-bot | | Section | Guides & Tutorials | ### Summary Tutorial: Build a Daily Briefing Bot In this tutorial, you'll build a personal briefing bot that wakes up every morning, researches topics you care about, summa ### Source outline - What We're Building - Prerequisites - Step 1: Test the Workflow Manually - Step 2: Create the Cron Job - Option A: Natural Language (in chat) - Option B: CLI Slash Command - The Golden Rule: Self-Contained Prompts - Step 3: Customize the Briefing - Multi-Topic Briefings - Using Delegation for Parallel Research - Weekday-Only Schedule - Twice-Daily Briefings - Adding Personal Context with Memory - Step 4: Manage Your Jobs ### Section map ### What We're Building Maps what we're building to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: Test the Workflow Manually Maps step 1: test the workflow manually to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: Create the Cron Job Maps step 2: create the cron job to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Option A: Natural Language (in chat) Maps option a: natural language (in chat) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Option B: CLI Slash Command Maps option b: cli slash command to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### The Golden Rule: Self-Contained Prompts Maps the golden rule: self-contained prompts to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: Customize the Briefing Maps step 3: customize the briefing to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What We're Building, Prerequisites, Step 1: Test the Workflow Manually, Step 2: Create the Cron Job, Option A: Natural Language (in chat). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: tutorial, daily, briefing, build, personal. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for tutorial: daily briefing bot before applying exact upstream commands. | | Verify first | What We're Building | Open the source anchor for What We're Building and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for What We're Building; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Tutorial: Team Telegram Assistant | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/team-telegram-assistant/ | | Source | https://hermesbible.com/docs/guides/team-telegram-assistant | | Section | Guides & Tutorials | ### Summary Set Up a Team Telegram Assistant This tutorial walks you through setting up a Telegram bot powered by Hermes Agent that multiple team members can use. By the en ### Source outline - What We're Building - Prerequisites - Step 1: Create a Telegram Bot - Step 2: Configure the Gateway - Option A: Interactive Setup (Recommended) - Option B: Manual Configuration - Finding Your User ID - Step 3: Start the Gateway - Quick Test - Production: Install as a Service - Verify It's Running - Step 4: Set Up Team Access - Approach A: Static Allowlist - Approach B: DM Pairing (Recommended for Teams) ### Section map ### What We're Building Maps what we're building to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create a Telegram Bot Maps step 1: create a telegram bot to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: Configure the Gateway Maps step 2: configure the gateway to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Option A: Interactive Setup (Recommended) Maps option a: interactive setup (recommended) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Option B: Manual Configuration Maps option b: manual configuration to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Finding Your User ID Maps finding your user id to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: Start the Gateway Maps step 3: start the gateway to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What We're Building, Prerequisites, Step 1: Create a Telegram Bot, Step 2: Configure the Gateway, Option A: Interactive Setup (Recommended). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: tutorial, telegram, assistant, walks, through. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for tutorial: team telegram assistant before applying exact upstream commands. | | Verify first | What We're Building | Open the source anchor for What We're Building and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for What We're Building; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Using Hermes as a Python Library | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/python-library/ | | Source | https://hermesbible.com/docs/guides/python-library | | Section | Guides & Tutorials | ### Summary Hermes isn't just a CLI tool. You can import directly and use it programmatically in your own Python scripts, web applications, or automation pipelines. This gu ### Source outline - Installation - Basic Usage - Full Conversation Control - Configuring Tools - Multi-turn Conversations - Saving Trajectories - Custom System Prompts - Batch Processing - Integration Examples - FastAPI Endpoint - Discord Bot - CI/CD Pipeline Step - Key Constructor Parameters - Important Notes ### Section map ### Installation Maps installation to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Basic Usage Maps basic usage to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Full Conversation Control Maps full conversation control to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Configuring Tools Maps configuring tools to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Multi-turn Conversations Maps multi-turn conversations to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Saving Trajectories Maps saving trajectories to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Custom System Prompts Maps custom system prompts to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Batch Processing Maps batch processing to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Installation, Basic Usage, Full Conversation Control, Configuring Tools, Multi-turn Conversations. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: python, library, tool., import, directly. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for using hermes as a python library before applying exact upstream commands. | | Verify first | Installation | Open the source anchor for Installation and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Installation; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Basic Usage if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Use MCP with Hermes | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/use-mcp-with-hermes/ | | Source | https://hermesbible.com/docs/guides/use-mcp-with-hermes | | Section | Guides & Tutorials | ### Summary This guide shows how to actually use MCP with Hermes Agent in day to day workflows. If the feature page explains what MCP is, this guide is about how to get val ### Source outline - When should you use MCP? - Mental model - Step 1: install MCP support - Step 2: add one server first - Step 3: verify MCP loaded - Step 4: start filtering immediately - Example: whitelist only what you want - WSL2: bridge Hermes in WSL to Windows Chrome - Why this mode is useful - Recommended server - Typical prompt - When /browser connect is the wrong tool - Known pitfalls - Example: blacklist dangerous actions ### Section map ### When should you use MCP? Maps when should you use mcp? to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Mental model Maps mental model to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: install MCP support Maps step 1: install mcp support to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: add one server first Maps step 2: add one server first to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: verify MCP loaded Maps step 3: verify mcp loaded to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 4: start filtering immediately Maps step 4: start filtering immediately to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Example: whitelist only what you want Maps example: whitelist only what you want to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### WSL2: bridge Hermes in WSL to Windows Chrome Maps wsl2: bridge hermes in wsl to windows chrome to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: When should you use MCP?, Mental model, Step 1: install MCP support, Step 2: add one server first, Step 3: verify MCP loaded. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: shows, actually, workflows., feature, explains. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for use mcp with hermes before applying exact upstream commands. | | Verify first | When should you use MCP? | Open the source anchor for When should you use MCP? and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for When should you use MCP?; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Mental model if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Use Voice Mode with Hermes | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/use-voice-mode-with-hermes/ | | Source | https://hermesbible.com/docs/guides/use-voice-mode-with-hermes | | Section | Guides & Tutorials | ### Summary This guide is the practical companion to the Voice Mode feature reference. If the feature page explains what voice mode can do, this guide shows how to actually ### Source outline - What voice mode is good for - Choose your voice mode setup - Step 1: make sure normal Hermes works first - Step 2: install the right extras - CLI microphone + playback - Messaging platforms - Premium ElevenLabs TTS - Local NeuTTS (optional) - Everything - Step 3: install system dependencies - macOS - Ubuntu / Debian - Step 4: choose STT and TTS providers - Easiest / cheapest setup ### Section map ### What voice mode is good for Maps what voice mode is good for to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Choose your voice mode setup Maps choose your voice mode setup to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: make sure normal Hermes works first Maps step 1: make sure normal hermes works first to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: install the right extras Maps step 2: install the right extras to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### CLI microphone + playback Maps cli microphone + playback to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Messaging platforms Maps messaging platforms to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Premium ElevenLabs TTS Maps premium elevenlabs tts to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Local NeuTTS (optional) Maps local neutts (optional) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What voice mode is good for, Choose your voice mode setup, Step 1: make sure normal Hermes works first, Step 2: install the right extras, CLI microphone + playback. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: voice, practical, companion, feature, reference.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for use voice mode with hermes before applying exact upstream commands. | | Verify first | What voice mode is good for | Open the source anchor for What voice mode is good for and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for What voice mode is good for; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Choose your voice mode setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Use SOUL.md with Hermes | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/use-soul-with-hermes/ | | Source | https://hermesbible.com/docs/guides/use-soul-with-hermes | | Section | Guides & Tutorials | ### Summary is the primary identity for your Hermes instance. It's the first thing in the system prompt — it defines who the agent is, how it speaks, and what it avoids. If ### Source outline - What SOUL.md is for - What SOUL.md is not for - Where it lives - First-run behavior - How Hermes uses it - A good first edit - Example styles - 1. Pragmatic engineer - Style - Avoid - 2. Research partner - Style - 3. Teacher / explainer - Style ### Section map ### What SOUL.md is for Maps what soul.md is for to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What SOUL.md is not for Maps what soul.md is not for to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Where it lives Maps where it lives to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### First-run behavior Maps first-run behavior to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### How Hermes uses it Maps how hermes uses it to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### A good first edit Maps a good first edit to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Example styles Maps example styles to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 1. Pragmatic engineer Maps 1. pragmatic engineer to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What SOUL.md is for, What SOUL.md is not for, Where it lives, First-run behavior, How Hermes uses it. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: soul.md, primary, identity, instance., first. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for use soul.md with hermes before applying exact upstream commands. | | Verify first | What SOUL.md is for | Open the source anchor for What SOUL.md is for and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for What SOUL.md is for; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What SOUL.md is not for if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Build a Hermes Plugin | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/build-a-hermes-plugin/ | | Source | https://hermesbible.com/docs/guides/build-a-hermes-plugin | | Section | Guides & Tutorials | ### Summary This guide walks through building a complete Hermes plugin from scratch. By the end you'll have a working plugin with multiple tools, lifecycle hooks, shipped d ### Source outline - What you're building - Step 1: Create the plugin directory - Step 2: Write the manifest - Step 3: Write the tool schemas - Step 4: Write the tool handlers - Step 5: Write the registration - Step 6: Test it - Debugging plugin discovery - Your plugin's final structure - What else can plugins do? - Ship data files - Bundle skills - Gate on environment variables - Lazy-install optional Python dependencies ### Section map ### What you're building Maps what you're building to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create the plugin directory Maps step 1: create the plugin directory to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: Write the manifest Maps step 2: write the manifest to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: Write the tool schemas Maps step 3: write the tool schemas to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 4: Write the tool handlers Maps step 4: write the tool handlers to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 5: Write the registration Maps step 5: write the registration to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 6: Test it Maps step 6: test it to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Debugging plugin discovery Maps debugging plugin discovery to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: What you're building, Step 1: Create the plugin directory, Step 2: Write the manifest, Step 3: Write the tool schemas, Step 4: Write the tool handlers. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: build, plugin, walks, through, building. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for build a hermes plugin before applying exact upstream commands. | | Verify first | What you're building | Open the source anchor for What you're building and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for What you're building; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create the plugin directory if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Automate Anything with Cron | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/automate-with-cron/ | | Source | https://hermesbible.com/docs/guides/automate-with-cron | | Section | Guides & Tutorials | ### Summary The daily briefing bot tutorial covers the basics. This guide goes further — five real world automation patterns you can adapt for your own workflows. For the f ### Source outline - Pattern 1: Website Change Monitor - Pattern 2: Weekly Report - Pattern 3: GitHub Repository Watcher - Pattern 4: Data Collection Pipeline - Pattern 5: Multi-Skill Workflow - Managing Your Jobs - Delivery Targets - Tips ### Section map ### Pattern 1: Website Change Monitor Maps pattern 1: website change monitor to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern 2: Weekly Report Maps pattern 2: weekly report to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern 3: GitHub Repository Watcher Maps pattern 3: github repository watcher to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern 4: Data Collection Pipeline Maps pattern 4: data collection pipeline to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern 5: Multi-Skill Workflow Maps pattern 5: multi-skill workflow to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Managing Your Jobs Maps managing your jobs to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Delivery Targets Maps delivery targets to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Tips Maps tips to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Pattern 1: Website Change Monitor, Pattern 2: Weekly Report, Pattern 3: GitHub Repository Watcher, Pattern 4: Data Collection Pipeline, Pattern 5: Multi-Skill Workflow. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: automate, anything, daily, briefing, tutorial. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for automate anything with cron before applying exact upstream commands. | | Verify first | Pattern 1: Website Change Monitor | Open the source anchor for Pattern 1: Website Change Monitor and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Pattern 1: Website Change Monitor; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Pattern 2: Weekly Report if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Working with Skills | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/work-with-skills/ | | Source | https://hermesbible.com/docs/guides/work-with-skills | | Section | Guides & Tutorials | ### Summary Skills are on demand knowledge documents that teach Hermes how to handle specific tasks — from generating ASCII art to managing GitHub PRs. This guide walks you ### Source outline - Finding Skills - Searching for a Skill - The Skills Hub - Using a Skill - Progressive Disclosure - Installing from the Hub - Verifying Installation - Plugin-Provided Skills - Configuring Skill Settings - Creating Your Own Skill - 1. Create the Directory - 2. Write SKILL.md - When to Use - Procedure ### Section map ### Finding Skills Maps finding skills to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Searching for a Skill Maps searching for a skill to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### The Skills Hub Maps the skills hub to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Using a Skill Maps using a skill to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Progressive Disclosure Maps progressive disclosure to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Installing from the Hub Maps installing from the hub to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Verifying Installation Maps verifying installation to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Plugin-Provided Skills Maps plugin-provided skills to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Finding Skills, Searching for a Skill, The Skills Hub, Using a Skill, Progressive Disclosure. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: working, skills, demand, knowledge, documents. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for working with skills before applying exact upstream commands. | | Verify first | Finding Skills | Open the source anchor for Finding Skills and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Finding Skills; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Searching for a Skill if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Delegation & Parallel Work | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/delegation-patterns/ | | Source | https://hermesbible.com/docs/guides/delegation-patterns | | Section | Guides & Tutorials | ### Summary Hermes can spawn isolated child agents to work on tasks in parallel. Each subagent gets its own conversation, terminal session, and toolset. Only the final summ ### Source outline - When to Delegate - Pattern: Parallel Research - Pattern: Code Review - Pattern: Compare Alternatives - Pattern: Multi-File Refactoring - Pattern: Gather Then Analyze - Toolset Selection - Constraints - Tuning Concurrency and Depth - Tips ### Section map ### When to Delegate Maps when to delegate to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern: Parallel Research Maps pattern: parallel research to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern: Code Review Maps pattern: code review to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern: Compare Alternatives Maps pattern: compare alternatives to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern: Multi-File Refactoring Maps pattern: multi-file refactoring to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Pattern: Gather Then Analyze Maps pattern: gather then analyze to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Toolset Selection Maps toolset selection to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Constraints Maps constraints to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: When to Delegate, Pattern: Parallel Research, Pattern: Code Review, Pattern: Compare Alternatives, Pattern: Multi-File Refactoring. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: delegation, parallel, spawn, isolated, child. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for delegation & parallel work before applying exact upstream commands. | | Verify first | When to Delegate | Open the source anchor for When to Delegate and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for When to Delegate; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Pattern: Parallel Research if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Tutorial: GitHub PR Review Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/github-pr-review-agent/ | | Source | https://hermesbible.com/docs/guides/github-pr-review-agent | | Section | Guides & Tutorials | ### Summary Tutorial: Build a GitHub PR Review Agent The problem: Your team opens PRs faster than you can review them. PRs sit for days waiting for eyeballs. Junior devs me ### Source outline - Prerequisites - Step 1: Verify the Setup - Step 2: Try a Manual Review - Step 3: Create a Review Skill - What to Check - Output Format - Rules - Step 4: Teach It Your Conventions - Step 5: Create the Automated Cron Job - PR Reviews — today - [repo] #[number]: [title] - Other useful schedules - Step 6: Run It On Demand - Going Further ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: Verify the Setup Maps step 1: verify the setup to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: Try a Manual Review Maps step 2: try a manual review to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: Create a Review Skill Maps step 3: create a review skill to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What to Check Maps what to check to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Output Format Maps output format to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Rules Maps rules to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 4: Teach It Your Conventions Maps step 4: teach it your conventions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Step 1: Verify the Setup, Step 2: Try a Manual Review, Step 3: Create a Review Skill, What to Check. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: tutorial, github, review, build, problem. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for tutorial: github pr review agent before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Verify the Setup if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Automation Blueprints | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/automation-blueprints/ | | Source | https://hermesbible.com/docs/guides/automation-blueprints | | Section | Guides & Tutorials | ### Summary Copy paste blueprints for common automation patterns. Each blueprint uses Hermes's built in cron scheduler for time based triggers and webhook platform for even ### Source outline - Development Workflow - Nightly Backlog Triage - Automatic PR Code Review - Docs Drift Detection - Dependency Security Audit - DevOps & Monitoring - Deploy Verification - Alert Triage - Uptime Monitor - Research & Intelligence - Competitive Repository Scout - AI News Digest - Headlines (3-5 major stories) - Notable Papers (2-3 papers with one-sentence summaries) ### Section map ### Development Workflow Maps development workflow to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Nightly Backlog Triage Maps nightly backlog triage to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Automatic PR Code Review Maps automatic pr code review to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Docs Drift Detection Maps docs drift detection to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Dependency Security Audit Maps dependency security audit to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### DevOps & Monitoring Maps devops & monitoring to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Deploy Verification Maps deploy verification to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Alert Triage Maps alert triage to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Development Workflow, Nightly Backlog Triage, Automatic PR Code Review, Docs Drift Detection, Dependency Security Audit. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: automation, blueprints, paste, common, patterns.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for automation blueprints before applying exact upstream commands. | | Verify first | Development Workflow | Open the source anchor for Development Workflow and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Development Workflow; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Nightly Backlog Triage if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## AWS Bedrock | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/aws-bedrock/ | | Source | https://hermesbible.com/docs/guides/aws-bedrock | | Section | Guides & Tutorials | ### Summary Hermes Agent supports Amazon Bedrock as a native provider using the Converse API — not the OpenAI compatible endpoint. This gives you full access to the Bedrock ### Source outline - Prerequisites - Quick Start - Configuration - Region - Guardrails - Model Discovery - Available Models - Switching Models Mid-Session - Diagnostics - Gateway (Messaging Platforms) - Troubleshooting - "No API key found" / "No AWS credentials" - "Invocation of model ID ... with on-demand throughput isn't supported" - "ThrottlingException" ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Region Maps region to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Guardrails Maps guardrails to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Model Discovery Maps model discovery to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Available Models Maps available models to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Switching Models Mid-Session Maps switching models mid-session to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Quick Start, Configuration, Region, Guardrails. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: bedrock, supports, amazon, native, provider. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for aws bedrock before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Microsoft Foundry | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/azure-foundry/ | | Source | https://hermesbible.com/docs/guides/azure-foundry | | Section | Guides & Tutorials | ### Summary Hermes Agent's provider supports Microsoft Foundry (formerly Azure AI Foundry) and Azure OpenAI. A single Foundry resource can host models with two different wi ### Source outline - Prerequisites - Quick Start - Microsoft Entra ID (keyless, RBAC) — recommended - Why use Entra ID? - One-time setup (Azure side) - One-time setup (Hermes side) - Configuration written to config.yaml - Credential resolution order - Deployment patterns - Sovereign clouds (Government, China) - Health checks - Limitations - Configuration (written to config.yaml) - OpenAI-style endpoints (GPT, Llama, etc.) ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Microsoft Entra ID (keyless, RBAC) — recommended Maps microsoft entra id (keyless, rbac) — recommended to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Why use Entra ID? Maps why use entra id? to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### One-time setup (Azure side) Maps one-time setup (azure side) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### One-time setup (Hermes side) Maps one-time setup (hermes side) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Configuration written to config.yaml Maps configuration written to config.yaml to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Credential resolution order Maps credential resolution order to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Quick Start, Microsoft Entra ID (keyless, RBAC) — recommended, Why use Entra ID?, One-time setup (Azure side). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: microsoft, foundry, provider, supports, formerly. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for microsoft foundry before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Script-Only Cron Jobs (No LLM) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/cron-script-only/ | | Source | https://hermesbible.com/docs/guides/cron-script-only | | Section | Guides & Tutorials | ### Summary Script Only Cron Jobs Sometimes you already know exactly what message you want to send. You don't need an agent to reason about it — you just need a script to r ### Source outline - When to Use It - Create One from Chat - Example transcript - What the agent decides for you - Managing watchdogs from chat - Create One from the CLI - How Script Output Maps to Delivery - Script Rules - Schedule Syntax - Delivery Targets - Editing and Lifecycle - Worked Example: Disk Space Alert - Comparison with Other Patterns - Related ### Section map ### When to Use It Maps when to use it to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Create One from Chat Maps create one from chat to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Example transcript Maps example transcript to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What the agent decides for you Maps what the agent decides for you to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Managing watchdogs from chat Maps managing watchdogs from chat to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Create One from the CLI Maps create one from the cli to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### How Script Output Maps to Delivery Maps how script output maps to delivery to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Script Rules Maps script rules to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: When to Use It, Create One from Chat, Example transcript, What the agent decides for you, Managing watchdogs from chat. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: script-only, script, sometimes, already, exactly. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for script-only cron jobs (no llm) before applying exact upstream commands. | | Verify first | When to Use It | Open the source anchor for When to Use It and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for When to Use It; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Create One from Chat if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Cron Troubleshooting | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/cron-troubleshooting/ | | Source | https://hermesbible.com/docs/guides/cron-troubleshooting | | Section | Guides & Tutorials | ### Summary When a cron job isn't behaving as expected, work through these checks in order. Most issues fall into one of four categories: timing, delivery, permissions, or ### Source outline - Jobs Not Firing - Check 1: Verify the job exists and is active - Check 2: Confirm the schedule is correct - Check 3: Is the gateway running? - Check 4: Check the system clock and timezone - Delivery Failures - Check 1: Verify the deliver target is correct - Check 2: Check [SILENT] usage - Check 3: Platform token permissions - Check 4: Response wrapping - Skill Loading Failures - Check 1: Verify skills are installed - Check 2: Check skill name vs. skill folder name - Check 3: Skills that require interactive tools ### Section map ### Jobs Not Firing Maps jobs not firing to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Check 1: Verify the job exists and is active Maps check 1: verify the job exists and is active to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Check 2: Confirm the schedule is correct Maps check 2: confirm the schedule is correct to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Check 3: Is the gateway running? Maps check 3: is the gateway running? to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Check 4: Check the system clock and timezone Maps check 4: check the system clock and timezone to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Delivery Failures Maps delivery failures to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Check 1: Verify the deliver target is correct Maps check 1: verify the deliver target is correct to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Check 2: Check [SILENT] usage Maps check 2: check [silent] usage to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Jobs Not Firing, Check 1: Verify the job exists and is active, Check 2: Confirm the schedule is correct, Check 3: Is the gateway running?, Check 4: Check the system clock and timezone. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: troubleshooting, behaving, expected, through, these. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for cron troubleshooting before applying exact upstream commands. | | Verify first | Jobs Not Firing | Open the source anchor for Jobs Not Firing and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Jobs Not Firing; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Check 1: Verify the job exists and is active if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Google Gemini | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/google-gemini/ | | Source | https://hermesbible.com/docs/guides/google-gemini | | Section | Guides & Tutorials | ### Summary Hermes Agent supports Google Gemini as a native provider using the Google AI Studio / Gemini API — not the OpenAI compatible endpoint. This lets Hermes translat ### Source outline - Prerequisites - Quick Start - Configuration - Native Gemini API - Prefer the Native Endpoint - OAuth Provider - Available Models - Latest Aliases - Gemma via the Gemini API - Switching Models Mid-Session - Diagnostics - Gateway (Messaging Platforms) - Troubleshooting - "Gemini native client requires an API key" ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Native Gemini API Maps native gemini api to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Prefer the Native Endpoint Maps prefer the native endpoint to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### OAuth Provider Maps oauth provider to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Available Models Maps available models to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Latest Aliases Maps latest aliases to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Quick Start, Configuration, Native Gemini API, Prefer the Native Endpoint. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: google, gemini, supports, native, provider. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for google gemini before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick Start if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Run Hermes Locally with Ollama — Zero API Cost | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/local-ollama-setup/ | | Source | https://hermesbible.com/docs/guides/local-ollama-setup | | Section | Guides & Tutorials | ### Summary The Problem Cloud LLM APIs charge per token. A heavy coding session can cost $5–20. For personal projects, learning, or privacy sensitive work, that adds up — a ### Source outline - The Problem - What This Guide Solves - What You Need - Step 1: Install Ollama - Step 2: Pull a Model - Step 3: Configure Hermes - Step 4: Start Using Hermes - Step 5: Pick the Right Model for Your Task - Step 6: Optimize for Speed - Increase Ollama's Context Window - Keep the Model Loaded - Use GPU Offloading (If Available) - Step 7: Run as a Gateway Bot (Optional) - Telegram ### Section map ### The Problem Maps the problem to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What This Guide Solves Maps what this guide solves to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What You Need Maps what you need to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: Install Ollama Maps step 1: install ollama to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: Pull a Model Maps step 2: pull a model to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: Configure Hermes Maps step 3: configure hermes to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 4: Start Using Hermes Maps step 4: start using hermes to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 5: Pick the Right Model for Your Task Maps step 5: pick the right model for your task to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: The Problem, What This Guide Solves, What You Need, Step 1: Install Ollama, Step 2: Pull a Model. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: locally, ollama, problem, cloud, charge. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for run hermes locally with ollama — zero api cost before applying exact upstream commands. | | Verify first | The Problem | Open the source anchor for The Problem and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for The Problem; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What This Guide Solves if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Register a Microsoft Graph Application | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/microsoft-graph-app-registration/ | | Source | https://hermesbible.com/docs/guides/microsoft-graph-app-registration | | Section | Guides & Tutorials | ### Summary The Teams meeting pipeline reads meeting transcripts, recordings, and related artifacts from Microsoft Graph using app only (daemon) authentication — no user si ### Source outline - Prerequisites - Step 1: Create the App Registration - Step 2: Create a Client Secret - Step 3: Grant Graph API Permissions - Required for transcript-first summaries - Required for recording fallback (when a transcript is unavailable) - Required for outbound summary delivery (Graph mode only) - Not recommended - Step 4: (Recommended) Scope the App with an Application Access Policy - Step 5: Write the Credentials to Your Env File - Step 6: Verify the Token Flow - Rotating the Client Secret - Next Steps ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create the App Registration Maps step 1: create the app registration to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2: Create a Client Secret Maps step 2: create a client secret to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3: Grant Graph API Permissions Maps step 3: grant graph api permissions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Required for transcript-first summaries Maps required for transcript-first summaries to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Required for recording fallback (when a transcript is unavailable) Maps required for recording fallback (when a transcript is unavailable) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Required for outbound summary delivery (Graph mode only) Maps required for outbound summary delivery (graph mode only) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Not recommended Maps not recommended to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Step 1: Create the App Registration, Step 2: Create a Client Secret, Step 3: Grant Graph API Permissions, Required for transcript-first summaries. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: register, microsoft, graph, application, teams. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for register a microsoft graph application before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create the App Registration if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Migrate from OpenClaw | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/migrate-from-openclaw/ | | Source | https://hermesbible.com/docs/guides/migrate-from-openclaw | | Section | Guides & Tutorials | ### Summary imports your OpenClaw (or legacy Clawdbot/Moldbot) setup into Hermes. This guide covers exactly what gets migrated, the config key mappings, and what to verify ### Source outline - Quick start - Options - What gets migrated - Persona, memory, and instructions - Skills (4 sources) - Model and provider configuration - Agent behavior - Session reset policies - MCP servers - TTS (text-to-speech) - Messaging platforms - Other config - Archived (no direct Hermes equivalent) - API key resolution ### Section map ### Quick start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Options Maps options to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What gets migrated Maps what gets migrated to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Persona, memory, and instructions Maps persona, memory, and instructions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Skills (4 sources) Maps skills (4 sources) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Model and provider configuration Maps model and provider configuration to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Agent behavior Maps agent behavior to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Session reset policies Maps session reset policies to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick start, Options, What gets migrated, Persona, memory, and instructions, Skills (4 sources). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: migrate, openclaw, imports, legacy, clawdbot/moldbot. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for migrate from openclaw before applying exact upstream commands. | | Verify first | Quick start | Open the source anchor for Quick start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Quick start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Options if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## MiniMax OAuth | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/minimax-oauth/ | | Source | https://hermesbible.com/docs/guides/minimax-oauth | | Section | Guides & Tutorials | ### Summary Hermes Agent supports MiniMax through a browser based OAuth login flow, using the same credentials as the MiniMax portal. No API key or credit card is required ### Source outline - Overview - Prerequisites - Quick Start - Logging In Manually - China region - Remote / headless sessions - The OAuth Flow - Checking Login Status - Switching Models - Configuration Reference - Region endpoints - Provider aliases - Environment Variables - Models ### Section map ### Overview Maps overview to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Logging In Manually Maps logging in manually to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### China region Maps china region to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Remote / headless sessions Maps remote / headless sessions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### The OAuth Flow Maps the oauth flow to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Checking Login Status Maps checking login status to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Prerequisites, Quick Start, Logging In Manually, China region. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: minimax, oauth, supports, through, browser. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for minimax oauth before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## OAuth over SSH / Remote Hosts | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/oauth-over-ssh/ | | Source | https://hermesbible.com/docs/guides/oauth-over-ssh | | Section | Guides & Tutorials | ### Summary Some Hermes providers — xAI Grok OAuth , Spotify , and remote MCP servers (Linear, Sentry, Atlassian, Asana, Figma, …) — use a loopback redirect OAuth flow. The ### Source outline - TL;DR - Browser-only remote (Cloud Shell / Codespaces / EC2 Instance Connect) - Which Providers Need This - MCP Servers - Why the listener can't just bind 0.0.0.0 - Step-by-step: single SSH hop - 1. Start the tunnel from your local machine - 2. In a separate SSH session, run the auth command - 3. Open the URL in your local browser - Step-by-step: through a jump box - Mosh, tmux, ssh ControlMaster - Troubleshooting - bind [127.0.0.1]:56121: Address already in use - "Could not establish connection. We couldn't reach your app." (xAI) ### Section map ### TL;DR Maps tl;dr to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Browser-only remote (Cloud Shell / Codespaces / EC2 Instance Connect) Maps browser-only remote (cloud shell / codespaces / ec2 instance connect) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Which Providers Need This Maps which providers need this to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### MCP Servers Maps mcp servers to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Why the listener can't just bind 0.0.0.0 Maps why the listener can't just bind 0.0.0.0 to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step-by-step: single SSH hop Maps step-by-step: single ssh hop to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 1. Start the tunnel from your local machine Maps 1. start the tunnel from your local machine to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 2. In a separate SSH session, run the auth command Maps 2. in a separate ssh session, run the auth command to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: TL;DR, Browser-only remote (Cloud Shell / Codespaces / EC2 Instance Connect), Which Providers Need This, MCP Servers, Why the listener can't just bind 0.0.0.0. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: oauth, remote, hosts, providers, spotify. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for oauth over ssh / remote hosts before applying exact upstream commands. | | Verify first | TL;DR | Open the source anchor for TL;DR and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for TL;DR; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Browser-only remote (Cloud Shell / Codespaces / EC2 Instance Connect) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Operate the Teams Meeting Pipeline | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/operate-teams-meeting-pipeline/ | | Source | https://hermesbible.com/docs/guides/operate-teams-meeting-pipeline | | Section | Guides & Tutorials | ### Summary Use this guide after you have already enabled the feature from Teams Meetings. This page covers: operator CLI flows routine subscription maintenance failure tri ### Source outline - Core Operator Commands - Validate the config snapshot - Inspect token health - Inspect subscriptions - Renew near-expiry subscriptions - Automating subscription renewal (REQUIRED for production) - Option 1: Hermes cron (recommended if you already run the Hermes gateway) - Option 2: systemd timer (recommended for Linux production deployments) - Option 3: Plain crontab - Verifying renewal is working - Inspect recent jobs - Replay a stored job - Dry-run meeting artifact fetches - Routine Runbook ### Section map ### Core Operator Commands Maps core operator commands to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Validate the config snapshot Maps validate the config snapshot to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Inspect token health Maps inspect token health to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Inspect subscriptions Maps inspect subscriptions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Renew near-expiry subscriptions Maps renew near-expiry subscriptions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Automating subscription renewal (REQUIRED for production) Maps automating subscription renewal (required for production) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Inspect recent jobs Maps inspect recent jobs to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Replay a stored job Maps replay a stored job to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Core Operator Commands, Validate the config snapshot, Inspect token health, Inspect subscriptions, Renew near-expiry subscriptions. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: operate, teams, meeting, pipeline, after. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for operate the teams meeting pipeline before applying exact upstream commands. | | Verify first | Core Operator Commands | Open the source anchor for Core Operator Commands and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Core Operator Commands; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Validate the config snapshot if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Pipe Script Output to Messaging Platforms | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/pipe-script-output/ | | Source | https://hermesbible.com/docs/guides/pipe-script-output | | Section | Guides & Tutorials | ### Summary is a small, scriptable CLI that pushes a message to any messaging platform Hermes is already configured for. Think of it as a cross platform for notifications — ### Source outline - Quick Start - Argument Reference - Target Formats - Exit Codes - Message Body Resolution - Real-World Examples - Monitoring: Memory / Disk Alerts - CI / CD: Build and Test Results - Cron: Daily Report - Long-Running Tasks: Ping When Done - Scripting with --json and --quiet - Does hermes send Need the Gateway Running? - Listing and Discovering Targets - Comparison with Other Approaches ### Section map ### Quick Start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Argument Reference Maps argument reference to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Target Formats Maps target formats to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Exit Codes Maps exit codes to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Message Body Resolution Maps message body resolution to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Real-World Examples Maps real-world examples to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Monitoring: Memory / Disk Alerts Maps monitoring: memory / disk alerts to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### CI / CD: Build and Test Results Maps ci / cd: build and test results to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Quick Start, Argument Reference, Target Formats, Exit Codes, Message Body Resolution. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: script, output, messaging, platforms, small. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for pipe script output to messaging platforms before applying exact upstream commands. | | Verify first | Quick Start | Open the source anchor for Quick Start and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Quick Start; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Argument Reference if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Run Hermes Agent with Nous Portal | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/run-hermes-with-nous-portal/ | | Source | https://hermesbible.com/docs/guides/run-hermes-with-nous-portal | | Section | Guides & Tutorials | ### Summary This guide walks you through running Hermes Agent on a Nous Portal subscription end to end — from signing up to verifying that every tool routes correctly. If y ### Source outline - Prerequisites - 1. Get a subscription - 2. Run the one-shot setup - What if I'm SSH'd into a server? - 3. Verify it worked - 4. Run your first conversation - 5. Pick the model you actually want - Don't pick Hermes-4 for agent work - 6. (Optional) Customize Tool Gateway routing - 7. (Optional) Enable voice mode - 8. (Optional) Cron + always-on workflows - Profiles and multi-user setups - Troubleshooting - hermes portal info shows "not logged in" after hermes setup --portal ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 1. Get a subscription Maps 1. get a subscription to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 2. Run the one-shot setup Maps 2. run the one-shot setup to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### What if I'm SSH'd into a server? Maps what if i'm ssh'd into a server? to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 3. Verify it worked Maps 3. verify it worked to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 4. Run your first conversation Maps 4. run your first conversation to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 5. Pick the model you actually want Maps 5. pick the model you actually want to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Don't pick Hermes-4 for agent work Maps don't pick hermes-4 for agent work to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, 1. Get a subscription, 2. Run the one-shot setup, What if I'm SSH'd into a server?, 3. Verify it worked. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: portal, walks, through, running, subscription. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for run hermes agent with nous portal before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for 1. Get a subscription if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Run Nemotron 3 Ultra free in Hermes Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/run-nemotron-3-ultra-free/ | | Source | https://hermesbible.com/docs/guides/run-nemotron-3-ultra-free | | Section | Guides & Tutorials | ### Summary Nous Research has been inducted into the Nemotron Coalition of leading AI labs working with NVIDIA to advance open frontier foundation models. In honor of this, ### Source outline - Option A — Desktop app (recommended) - 1. Download and install - 2. Connect Nous Portal - 3. Pick the free Nemotron 3 Ultra model - 4. Start chatting - Option B — Command line - 1. Install Hermes Agent - 2. Run Quick Setup - 3. Create a Nous Portal account - 4. Connect your account - 5. Select the free Nemotron 3 Ultra model - 6. Start chatting - Switching to it later - Troubleshooting ### Section map ### Option A — Desktop app (recommended) Maps option a — desktop app (recommended) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 1. Download and install Maps 1. download and install to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 2. Connect Nous Portal Maps 2. connect nous portal to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 3. Pick the free Nemotron 3 Ultra model Maps 3. pick the free nemotron 3 ultra model to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 4. Start chatting Maps 4. start chatting to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Option B — Command line Maps option b — command line to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 1. Install Hermes Agent Maps 1. install hermes agent to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### 2. Run Quick Setup Maps 2. run quick setup to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Option A — Desktop app (recommended), 1. Download and install, 2. Connect Nous Portal, 3. Pick the free Nemotron 3 Ultra model, 4. Start chatting. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: nemotron, ultra, research, inducted, coalition. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for run nemotron 3 ultra free in hermes agent before applying exact upstream commands. | | Verify first | Option A — Desktop app (recommended) | Open the source anchor for Option A — Desktop app (recommended) and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Option A — Desktop app (recommended); do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for 1. Download and install if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Automated GitHub PR Comments with Webhooks | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/webhook-github-pr-review/ | | Source | https://hermesbible.com/docs/guides/webhook-github-pr-review | | Section | Guides & Tutorials | ### Summary This guide walks you through connecting Hermes Agent to GitHub so it automatically fetches a pull request's diff, analyzes the code changes, and posts a comment ### Source outline - Prerequisites - Step 1 — Enable the webhook platform - Step 2 — Start the gateway - Step 3 — Register the webhook on GitHub - Step 4 — Open a test PR - Local testing with ngrok - Filtering to specific actions - Using a skill for consistent review style - Sending responses to Slack or Discord instead - GitLab support - Security notes - Troubleshooting - Full config reference - What's Next? ### Section map ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 1 — Enable the webhook platform Maps step 1 — enable the webhook platform to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 2 — Start the gateway Maps step 2 — start the gateway to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 3 — Register the webhook on GitHub Maps step 3 — register the webhook on github to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Step 4 — Open a test PR Maps step 4 — open a test pr to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Local testing with ngrok Maps local testing with ngrok to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Filtering to specific actions Maps filtering to specific actions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Using a skill for consistent review style Maps using a skill for consistent review style to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Prerequisites, Step 1 — Enable the webhook platform, Step 2 — Start the gateway, Step 3 — Register the webhook on GitHub, Step 4 — Open a test PR. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: automated, github, comments, webhooks, walks. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for automated github pr comments with webhooks before applying exact upstream commands. | | Verify first | Prerequisites | Open the source anchor for Prerequisites and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Prerequisites; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1 — Enable the webhook platform if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## xAI Grok OAuth (SuperGrok / X Premium+) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/guides/xai-grok-oauth/ | | Source | https://hermesbible.com/docs/guides/xai-grok-oauth | | Section | Guides & Tutorials | ### Summary Hermes Agent supports xAI Grok through a browser based OAuth login flow against accounts.x.ai, using either a SuperGrok subscription (grok.com) or an X Premium+ ### Source outline - Overview - Prerequisites - Quick Start - Logging In Manually - Remote / headless sessions - Browser-only remotes (Cloud Shell, Codespaces, EC2 Instance Connect) - How the Login Works - Checking Login Status - Switching Models - Configuration Reference - Provider aliases - Direct-to-xAI Tools (TTS / Image / Video / Transcription / X Search) - Models - Environment Variables ### Section map ### Overview Maps overview to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Quick Start Maps quick start to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Logging In Manually Maps logging in manually to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Remote / headless sessions Maps remote / headless sessions to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Browser-only remotes (Cloud Shell, Codespaces, EC2 Instance Connect) Maps browser-only remotes (cloud shell, codespaces, ec2 instance connect) to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### How the Login Works Maps how the login works to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Checking Login Status Maps checking login status to the Guides & Tutorials documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Guides & Tutorials doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Prerequisites, Quick Start, Logging In Manually, Remote / headless sessions. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: oauth, supergrok, premium+, supports, through. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides & Tutorials documentation | Use when you need orientation for xai grok oauth (supergrok / x premium+) before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Guides & Tutorials, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Prerequisites if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Developer Guide ## Contributing | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/contributing/ | | Source | https://hermesbible.com/docs/developer-guide/contributing | | Section | Developer Guide | ### Summary Thank you for contributing to Hermes Agent! This guide covers setting up your dev environment, understanding the codebase, and getting your PR merged. Contribut ### Source outline - Contribution Priorities - Common contribution paths - Development Setup - Prerequisites - Install with the standard installer - Manual clone fallback - Configure for Development - Run - Run Tests - Code Style - Cross-Platform Compatibility - 1. termios and fcntl are Unix-only - 2. File encoding - 3. Process management ### Section map ### Contribution Priorities Maps contribution priorities to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Common contribution paths Maps common contribution paths to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Development Setup Maps development setup to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Prerequisites Maps prerequisites to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Install with the standard installer Maps install with the standard installer to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Manual clone fallback Maps manual clone fallback to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Configure for Development Maps configure for development to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Run Maps run to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Contribution Priorities, Common contribution paths, Development Setup, Prerequisites, Install with the standard installer. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: contributing, thank, covers, setting, environment. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for contributing before applying exact upstream commands. | | Verify first | Contribution Priorities | Open the source anchor for Contribution Priorities and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Contribution Priorities; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Common contribution paths if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Architecture | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/architecture/ | | Source | https://hermesbible.com/docs/developer-guide/architecture | | Section | Developer Guide | ### Summary This page is the top level map of Hermes Agent internals. Use it to orient yourself in the codebase, then dive into subsystem specific docs for implementation d ### Source outline - System Overview - Directory Structure - Data Flow - CLI Session - Gateway Message - Cron Job - Recommended Reading Order - Major Subsystems - Agent Loop - Prompt System - Provider Resolution - Tool System - Session Persistence - Messaging Gateway ### Section map ### System Overview Maps system overview to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Directory Structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Data Flow Maps data flow to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### CLI Session Maps cli session to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Gateway Message Maps gateway message to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Cron Job Maps cron job to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Recommended Reading Order Maps recommended reading order to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Major Subsystems Maps major subsystems to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: System Overview, Directory Structure, Data Flow, CLI Session, Gateway Message. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: architecture, level, internals., orient, yourself. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for architecture before applying exact upstream commands. | | Verify first | System Overview | Open the source anchor for System Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for System Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Directory Structure if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Agent Loop Internals | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/agent-loop/ | | Source | https://hermesbible.com/docs/developer-guide/agent-loop | | Section | Developer Guide | ### Summary The core orchestration engine is 's class — a large file that handles everything from prompt assembly to tool dispatch to provider failover. Core Responsibiliti ### Source outline - Core Responsibilities - Two Entry Points - API Modes - Turn Lifecycle - Message Format - Message Alternation Rules - Interruptible API Calls - Tool Execution - Sequential vs Concurrent - Execution Flow - Agent-Level Tools - Callback Surfaces - Budget and Fallback Behavior - Iteration Budget ### Section map ### Core Responsibilities Maps core responsibilities to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Two Entry Points Maps two entry points to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### API Modes Maps api modes to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Turn Lifecycle Maps turn lifecycle to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Message Format Maps message format to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Message Alternation Rules Maps message alternation rules to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Interruptible API Calls Maps interruptible api calls to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Tool Execution Maps tool execution to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Core Responsibilities, Two Entry Points, API Modes, Turn Lifecycle, Message Format. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: internals, orchestration, engine, class, large. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for agent loop internals before applying exact upstream commands. | | Verify first | Core Responsibilities | Open the source anchor for Core Responsibilities and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Core Responsibilities; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Two Entry Points if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Prompt Assembly | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/prompt-assembly/ | | Source | https://hermesbible.com/docs/developer-guide/prompt-assembly | | Section | Developer Guide | ### Summary Hermes deliberately separates: cached system prompt state ephemeral API call time additions This is one of the most important design choices in the project beca ### Source outline - Cached system prompt layers - Concrete example: assembled system prompt - Persistent Memory - User Profile - Skills (mandatory) - AGENTS.md - How SOUL.md appears in the prompt - How context files are injected - Context file discovery details - API-call-time-only layers - Memory snapshots - Context files - Skills index - Supported prompt customization surfaces ### Section map ### Cached system prompt layers Maps cached system prompt layers to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Concrete example: assembled system prompt Maps concrete example: assembled system prompt to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Persistent Memory Maps persistent memory to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### User Profile Maps user profile to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Skills (mandatory) Maps skills (mandatory) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### AGENTS.md Maps agents.md to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### How SOUL.md appears in the prompt Maps how soul.md appears in the prompt to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### How context files are injected Maps how context files are injected to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Cached system prompt layers, Concrete example: assembled system prompt, Persistent Memory, User Profile, Skills (mandatory). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: prompt, assembly, deliberately, separates, cached. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for prompt assembly before applying exact upstream commands. | | Verify first | Cached system prompt layers | Open the source anchor for Cached system prompt layers and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Cached system prompt layers; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Concrete example: assembled system prompt if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Context Compression and Caching | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/context-compression-and-caching/ | | Source | https://hermesbible.com/docs/developer-guide/context-compression-and-caching | | Section | Developer Guide | ### Summary Context Compression and Caching Hermes Agent uses a dual compression system and Anthropic prompt caching to manage context window usage efficiently across long ### Source outline - Pluggable Context Engine - Dual Compression System - 1. Gateway Session Hygiene (85% threshold) - 2. Agent ContextCompressor (50% threshold, configurable) - Configuration - Parameter Details - Codex gpt-5.5 threshold autoraise - Computed Values (for a 200K context model at defaults) - Compression Algorithm - Phase 1: Prune Old Tool Results (cheap, no LLM call) - Phase 2: Determine Boundaries - Phase 3: Generate Structured Summary - Goal - Constraints & Preferences ### Section map ### Pluggable Context Engine Maps pluggable context engine to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Dual Compression System Maps dual compression system to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### 1. Gateway Session Hygiene (85% threshold) Maps 1. gateway session hygiene (85% threshold) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### 2. Agent ContextCompressor (50% threshold, configurable) Maps 2. agent contextcompressor (50% threshold, configurable) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Parameter Details Maps parameter details to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Codex gpt-5.5 threshold autoraise Maps codex gpt-5.5 threshold autoraise to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Computed Values (for a 200K context model at defaults) Maps computed values (for a 200k context model at defaults) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Pluggable Context Engine, Dual Compression System, 1. Gateway Session Hygiene (85% threshold), 2. Agent ContextCompressor (50% threshold, configurable), Configuration. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: context, compression, caching, system, anthropic. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for context compression and caching before applying exact upstream commands. | | Verify first | Pluggable Context Engine | Open the source anchor for Pluggable Context Engine and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Pluggable Context Engine; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Dual Compression System if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Gateway Internals | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/gateway-internals/ | | Source | https://hermesbible.com/docs/developer-guide/gateway-internals | | Section | Developer Guide | ### Summary The messaging gateway is the long running process that connects Hermes to 20+ external messaging platforms through a unified architecture. Key Files File Purpos ### Source outline - Key Files - Architecture Overview - Message Flow - Session Key Format - Two-Level Message Guard - Authorization - DM Pairing Flow - Slash Command Dispatch - Running-Agent Guard - Config Sources - Platform Adapters - Token Locks - Delivery Path - Hooks ### Section map ### Key Files Maps key files to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Architecture Overview Maps architecture overview to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Message Flow Maps message flow to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Session Key Format Maps session key format to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Two-Level Message Guard Maps two-level message guard to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Authorization Maps authorization to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### DM Pairing Flow Maps dm pairing flow to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Slash Command Dispatch Maps slash command dispatch to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Key Files, Architecture Overview, Message Flow, Session Key Format, Two-Level Message Guard. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: gateway, internals, messaging, running, process. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for gateway internals before applying exact upstream commands. | | Verify first | Key Files | Open the source anchor for Key Files and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Key Files; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Architecture Overview if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Session Storage | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/session-storage/ | | Source | https://hermesbible.com/docs/developer-guide/session-storage | | Section | Developer Guide | ### Summary Session Storage Hermes Agent uses a SQLite database ( ) to persist session metadata, full message history, and model configuration across CLI and gateway sessio ### Source outline - Architecture Overview - SQLite Schema - Sessions Table - Messages Table - FTS5 Full-Text Search - Schema Version and Migrations - Write Contention Handling - Common Operations - Initialize - Create and Manage Sessions - Store Messages - Retrieve Messages - Session Titles - Full-Text Search ### Section map ### Architecture Overview Maps architecture overview to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### SQLite Schema Maps sqlite schema to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Sessions Table Maps sessions table to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Messages Table Maps messages table to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### FTS5 Full-Text Search Maps fts5 full-text search to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Schema Version and Migrations Maps schema version and migrations to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Write Contention Handling Maps write contention handling to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Common Operations Maps common operations to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Architecture Overview, SQLite Schema, Sessions Table, Messages Table, FTS5 Full-Text Search. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: session, storage, sqlite, database, persist. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for session storage before applying exact upstream commands. | | Verify first | Architecture Overview | Open the source anchor for Architecture Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Architecture Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for SQLite Schema if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Provider Runtime Resolution | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/provider-runtime/ | | Source | https://hermesbible.com/docs/developer-guide/provider-runtime | | Section | Developer Guide | ### Summary Hermes has a shared provider runtime resolver used across: CLI gateway cron jobs ACP auxiliary model calls Primary implementation: — credential resolution, — pr ### Source outline - Resolution precedence - Providers - Output of runtime resolution - Why this matters - OpenRouter and custom OpenAI-compatible base URLs - Native Anthropic path - OpenAI Codex path - Auxiliary model routing - Fallback models - How it works internally - What does NOT support fallback - Test coverage - Related docs ### Section map ### Resolution precedence Maps resolution precedence to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Providers Maps providers to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Output of runtime resolution Maps output of runtime resolution to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Why this matters Maps why this matters to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### OpenRouter and custom OpenAI-compatible base URLs Maps openrouter and custom openai-compatible base urls to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Native Anthropic path Maps native anthropic path to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### OpenAI Codex path Maps openai codex path to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Auxiliary model routing Maps auxiliary model routing to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Resolution precedence, Providers, Output of runtime resolution, Why this matters, OpenRouter and custom OpenAI-compatible base URLs. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: provider, runtime, resolution, resolver, across. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for provider runtime resolution before applying exact upstream commands. | | Verify first | Resolution precedence | Open the source anchor for Resolution precedence and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Resolution precedence; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Providers if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Adding Tools | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/adding-tools/ | | Source | https://hermesbible.com/docs/developer-guide/adding-tools | | Section | Developer Guide | ### Summary Before writing a tool, ask yourself: should this be a skill instead? WARNING — Built in Core Tools Only This page is for adding a built in Hermes tool to the re ### Source outline - Overview - Step 1: Create the Built-in Tool File - Key Rules - Step 2: Add the Built-in Tool to a Toolset - ~~Step 3: Add Discovery Import~~ (No longer needed) - Async Handlers - Handlers That Need task_id - Agent-Loop Intercepted Tools - Optional: Setup Wizard Integration - Checklist ### Section map ### Overview Maps overview to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Step 1: Create the Built-in Tool File Maps step 1: create the built-in tool file to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Key Rules Maps key rules to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Step 2: Add the Built-in Tool to a Toolset Maps step 2: add the built-in tool to a toolset to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### ~~Step 3: Add Discovery Import~~ (No longer needed) Maps ~~step 3: add discovery import~~ (no longer needed) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Async Handlers Maps async handlers to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Handlers That Need task_id Maps handlers that need task_id to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Agent-Loop Intercepted Tools Maps agent-loop intercepted tools to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Overview, Step 1: Create the Built-in Tool File, Key Rules, Step 2: Add the Built-in Tool to a Toolset, ~~Step 3: Add Discovery Import~~ (No longer needed). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: adding, tools, before, writing, yourself. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for adding tools before applying exact upstream commands. | | Verify first | Overview | Open the source anchor for Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Step 1: Create the Built-in Tool File if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Adding Providers | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/adding-providers/ | | Source | https://hermesbible.com/docs/developer-guide/adding-providers | | Section | Developer Guide | ### Summary Hermes can already talk to any OpenAI compatible endpoint through the custom provider path. Do not add a built in provider unless you want first class UX for th ### Source outline - The mental model - Choose the implementation path first - Path A — OpenAI-compatible provider - Path B — Native provider - File checklist - Required for every built-in provider - Additional for native / non-OpenAI providers - Fast path: Simple API-key providers - Full path: OAuth and complex providers - Step 1: Pick one canonical provider id - Step 2: Add auth metadata in hermes_cli/auth.py - Step 3: Add model catalog and aliases in hermes_cli/models.py - Step 4: Resolve runtime data in hermes_cli/runtime_provider.py - Step 5: Wire the CLI in hermes_cli/main.py ### Section map ### The mental model Maps the mental model to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Choose the implementation path first Maps choose the implementation path first to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Path A — OpenAI-compatible provider Maps path a — openai-compatible provider to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Path B — Native provider Maps path b — native provider to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### File checklist Maps file checklist to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Required for every built-in provider Maps required for every built-in provider to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Additional for native / non-OpenAI providers Maps additional for native / non-openai providers to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Fast path: Simple API-key providers Maps fast path: simple api-key providers to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: The mental model, Choose the implementation path first, Path A — OpenAI-compatible provider, Path B — Native provider, File checklist. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: adding, providers, already, openai, compatible. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for adding providers before applying exact upstream commands. | | Verify first | The mental model | Open the source anchor for The mental model and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for The mental model; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Choose the implementation path first if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Adding a Platform Adapter | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/adding-platform-adapters/ | | Source | https://hermesbible.com/docs/developer-guide/adding-platform-adapters | | Section | Developer Guide | ### Summary Adding a Platform Adapter This guide covers adding a new messaging platform to the Hermes gateway. A platform adapter connects Hermes to an external messaging s ### Source outline - Architecture Overview - Plugin Path (Recommended) - plugin.yaml - adapter.py - Configuration - What the Plugin System Handles Automatically - Env-Driven Auto-Configuration - YAML→env Config Bridge - Cron Delivery - Out-of-process cron delivery - Surfacing Env Vars in hermes config - Platform-Specific Slow-LLM UX - Pattern: subclass _keep_typing to layer mid-flight UX - Pattern: subclass send to route through a cache instead of sending immediately ### Section map ### Architecture Overview Maps architecture overview to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Plugin Path (Recommended) Maps plugin path (recommended) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### plugin.yaml Maps plugin.yaml to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### adapter.py Maps adapter.py to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### What the Plugin System Handles Automatically Maps what the plugin system handles automatically to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Env-Driven Auto-Configuration Maps env-driven auto-configuration to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### YAML→env Config Bridge Maps yaml→env config bridge to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Architecture Overview, Plugin Path (Recommended), plugin.yaml, adapter.py, Configuration. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: adding, platform, adapter, covers, messaging. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for adding a platform adapter before applying exact upstream commands. | | Verify first | Architecture Overview | Open the source anchor for Architecture Overview and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Architecture Overview; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Plugin Path (Recommended) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Creating Skills | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/creating-skills/ | | Source | https://hermesbible.com/docs/developer-guide/creating-skills | | Section | Developer Guide | ### Summary Skills are the preferred way to add new capabilities to Hermes Agent. They're easier to create than tools, require no code changes to the agent, and can be shar ### Source outline - Should it be a Skill or a Tool? - Skill Directory Structure - SKILL.md Format - When to Use - Quick Reference - Procedure - Pitfalls - Verification - Platform-Specific Skills - Conditional Skill Activation - Environment Variable Requirements - Secure Setup on Load - Config Settings (config.yaml) - Credential File Requirements (OAuth tokens, etc.) ### Section map ### Should it be a Skill or a Tool? Maps should it be a skill or a tool? to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Skill Directory Structure Maps skill directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### SKILL.md Format Maps skill.md format to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### When to Use Maps when to use to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Quick Reference Maps quick reference to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Procedure Maps procedure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Pitfalls Maps pitfalls to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Verification Maps verification to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Should it be a Skill or a Tool?, Skill Directory Structure, SKILL.md Format, When to Use, Quick Reference. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: creating, skills, preferred, capabilities, agent.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for creating skills before applying exact upstream commands. | | Verify first | Should it be a Skill or a Tool? | Open the source anchor for Should it be a Skill or a Tool? and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Should it be a Skill or a Tool?; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Skill Directory Structure if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Extending the CLI | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/extending-the-cli/ | | Source | https://hermesbible.com/docs/developer-guide/extending-the-cli | | Section | Developer Guide | ### Summary Hermes exposes protected extension hooks on so wrapper CLIs can add widgets, keybindings, and layout customizations without overriding the 1000+ line method. Th ### Source outline - Extension points - Quick start: a wrapper CLI - Hook reference - _get_extra_tui_widgets() - _register_extra_tui_keybindings(kb, *, input_area) - _build_tui_layout_children(**widgets) - Layout diagram - Tips ### Section map ### Extension points Maps extension points to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Quick start: a wrapper CLI Maps quick start: a wrapper cli to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Hook reference Maps hook reference to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### _get_extra_tui_widgets() Maps _get_extra_tui_widgets() to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### _register_extra_tui_keybindings(kb, *, input_area) Maps _register_extra_tui_keybindings(kb, *, input_area) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### _build_tui_layout_children(**widgets) Maps _build_tui_layout_children(**widgets) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Layout diagram Maps layout diagram to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Tips Maps tips to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Extension points, Quick start: a wrapper CLI, Hook reference, _get_extra_tui_widgets(), _register_extra_tui_keybindings(kb, *, input_area). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: extending, exposes, protected, extension, hooks. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for extending the cli before applying exact upstream commands. | | Verify first | Extension points | Open the source anchor for Extension points and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Extension points; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Quick start: a wrapper CLI if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## ACP Internals | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/acp-internals/ | | Source | https://hermesbible.com/docs/developer-guide/acp-internals | | Section | Developer Guide | ### Summary The ACP adapter wraps Hermes' synchronous in an async JSON RPC stdio server. Key implementation files: Boot flow The Zed ACP Registry path launches the same ada ### Source outline - Boot flow - Major components - HermesACPAgent - SessionManager - Event bridge - Permission bridge - Tool rendering helpers - Session lifecycle - Cancelation - Forking - Provider/auth behavior - Working directory binding - Duplicate same-name tool calls - Approval callback restoration ### Section map ### Boot flow Maps boot flow to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Major components Maps major components to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### HermesACPAgent Maps hermesacpagent to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### SessionManager Maps sessionmanager to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Event bridge Maps event bridge to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Permission bridge Maps permission bridge to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Tool rendering helpers Maps tool rendering helpers to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Session lifecycle Maps session lifecycle to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Boot flow, Major components, HermesACPAgent, SessionManager, Event bridge. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: internals, adapter, wraps, synchronous, async. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for acp internals before applying exact upstream commands. | | Verify first | Boot flow | Open the source anchor for Boot flow and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Boot flow; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Major components if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Browser CDP Supervisor | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/browser-supervisor/ | | Source | https://hermesbible.com/docs/developer-guide/browser-supervisor | | Section | Developer Guide | ### Summary The CDP supervisor closes two long standing gaps in Hermes' browser tooling: 1. Native JS dialogs ( / / / ) block the page's JS thread. Without supervision, the ### Source outline - Backend support - Architecture - CDPSupervisor - Lifecycle - Dialog policy - Agent surface - browser_dialog tool - browser_snapshot extension - Availability gating - Cross-origin iframe interaction - File layout - Non-goals - Testing ### Section map ### Backend support Maps backend support to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Architecture Maps architecture to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### CDPSupervisor Maps cdpsupervisor to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Lifecycle Maps lifecycle to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Dialog policy Maps dialog policy to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Agent surface Maps agent surface to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### browser_dialog tool Maps browser_dialog tool to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### browser_snapshot extension Maps browser_snapshot extension to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Backend support, Architecture, CDPSupervisor, Lifecycle, Dialog policy. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: browser, supervisor, closes, standing, tooling. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for browser cdp supervisor before applying exact upstream commands. | | Verify first | Backend support | Open the source anchor for Backend support and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Backend support; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Architecture if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Context Engine Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/context-engine-plugin/ | | Source | https://hermesbible.com/docs/developer-guide/context-engine-plugin | | Section | Developer Guide | ### Summary Building a Context Engine Plugin Context engine plugins replace the built in with an alternative strategy for managing conversation context. For example, a Loss ### Source outline - How it works - Directory structure - The ContextEngine ABC - Class attributes your engine must maintain - Optional methods - Engine tools - Registration - Via directory (recommended) - Via general plugin system - Lifecycle - Configuration - Testing - See also ### Section map ### How it works Maps how it works to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Directory structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The ContextEngine ABC Maps the contextengine abc to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Class attributes your engine must maintain Maps class attributes your engine must maintain to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Optional methods Maps optional methods to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Engine tools Maps engine tools to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Registration Maps registration to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Via directory (recommended) Maps via directory (recommended) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How it works, Directory structure, The ContextEngine ABC, Class attributes your engine must maintain, Optional methods. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: context, engine, plugins, building, plugin. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for context engine plugins before applying exact upstream commands. | | Verify first | How it works | Open the source anchor for How it works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for How it works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Directory structure if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Source authority | Use the upstream source page for exact current behavior before applying configuration changes. | --- ## Cron Internals | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/cron-internals/ | | Source | https://hermesbible.com/docs/developer-guide/cron-internals | | Section | Developer Guide | ### Summary The cron subsystem provides scheduled task execution — from simple one shot delays to recurring cron expression jobs with skill injection and cross platform del ### Source outline - Key Files - Scheduling Model - Job Storage - Job Lifecycle States - Backward Compatibility - Scheduler Runtime - Tick Cycle - Gateway Integration - Fresh Session Isolation - Skill-Backed Jobs - Script-Backed Jobs - Provider Recovery - Delivery Model - Response Wrapping ### Section map ### Key Files Maps key files to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Scheduling Model Maps scheduling model to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Job Storage Maps job storage to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Job Lifecycle States Maps job lifecycle states to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Backward Compatibility Maps backward compatibility to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Scheduler Runtime Maps scheduler runtime to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Tick Cycle Maps tick cycle to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Gateway Integration Maps gateway integration to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Key Files, Scheduling Model, Job Storage, Job Lifecycle States, Backward Compatibility. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: internals, subsystem, provides, scheduled, execution. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for cron internals before applying exact upstream commands. | | Verify first | Key Files | Open the source anchor for Key Files and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Key Files; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Scheduling Model if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Image Generation Provider Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/image-gen-provider-plugin/ | | Source | https://hermesbible.com/docs/developer-guide/image-gen-provider-plugin | | Section | Developer Guide | ### Summary Building an Image Generation Provider Plugin Image gen provider plugins register a backend that services every tool call — DALL·E, gpt image, Grok, Flux, Imagen ### Source outline - How discovery works - Directory structure - The ImageGenProvider ABC - plugin.yaml - ABC reference - Response format - Handling base64 vs URL output - User overrides - Testing - Reference implementations - Distribute via pip - Related pages ### Section map ### How discovery works Maps how discovery works to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Directory structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The ImageGenProvider ABC Maps the imagegenprovider abc to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### plugin.yaml Maps plugin.yaml to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### ABC reference Maps abc reference to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Response format Maps response format to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Handling base64 vs URL output Maps handling base64 vs url output to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### User overrides Maps user overrides to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How discovery works, Directory structure, The ImageGenProvider ABC, plugin.yaml, ABC reference. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: image, generation, provider, plugins, building. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for image generation provider plugins before applying exact upstream commands. | | Verify first | How discovery works | Open the source anchor for How discovery works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for How discovery works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Directory structure if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Memory Provider Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/memory-provider-plugin/ | | Source | https://hermesbible.com/docs/developer-guide/memory-provider-plugin | | Section | Developer Guide | ### Summary Building a Memory Provider Plugin Memory provider plugins give Hermes Agent persistent, cross session knowledge beyond the built in MEMORY.md and USER.md. This ### Source outline - Directory Structure - The MemoryProvider ABC - Required Methods - Core Lifecycle - Config - Optional Hooks - Config Schema - Save Config - Plugin Entry Point - plugin.yaml - Threading Contract - Profile Isolation - Testing - Adding CLI Commands ### Section map ### Directory Structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The MemoryProvider ABC Maps the memoryprovider abc to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Required Methods Maps required methods to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Core Lifecycle Maps core lifecycle to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Config Maps config to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Optional Hooks Maps optional hooks to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Config Schema Maps config schema to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Save Config Maps save config to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Directory Structure, The MemoryProvider ABC, Required Methods, Core Lifecycle, Config. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: memory, provider, plugins, building, plugin. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for memory provider plugins before applying exact upstream commands. | | Verify first | Directory Structure | Open the source anchor for Directory Structure and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Directory Structure; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for The MemoryProvider ABC if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Model Provider Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/model-provider-plugin/ | | Source | https://hermesbible.com/docs/developer-guide/model-provider-plugin | | Section | Developer Guide | ### Summary Building a Model Provider Plugin Model provider plugins declare an inference backend — an OpenAI compatible endpoint, an Anthropic Messages server, a Codex styl ### Source outline - How discovery works - Directory structure - Minimal example — a simple API-key provider - ProviderProfile fields - Overridable hooks - Hook reference examples - User overrides — replace a built-in without editing the repo - api_mode selection - Auth types - Discovery timing - Testing your plugin - General PluginManager integration - Distribute via pip - Related pages ### Section map ### How discovery works Maps how discovery works to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Directory structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Minimal example — a simple API-key provider Maps minimal example — a simple api-key provider to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### ProviderProfile fields Maps providerprofile fields to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Overridable hooks Maps overridable hooks to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Hook reference examples Maps hook reference examples to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### User overrides — replace a built-in without editing the repo Maps user overrides — replace a built-in without editing the repo to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### api_mode selection Maps api_mode selection to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How discovery works, Directory structure, Minimal example — a simple API-key provider, ProviderProfile fields, Overridable hooks. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: model, provider, plugins, building, plugin. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for model provider plugins before applying exact upstream commands. | | Verify first | How discovery works | Open the source anchor for How discovery works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for How discovery works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Directory structure if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Plugin LLM Access | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/plugin-llm-access/ | | Source | https://hermesbible.com/docs/developer-guide/plugin-llm-access | | Section | Developer Guide | ### Summary is the supported way for a plugin to make an LLM call. Chat completion, structured extraction, sync, async, with or without images — same surface, same trust ga ### Source outline - The smallest possible call - A more complete chat example - Structured output - What this lane gives you - Quick start - Chat completion — /tldr - Structured extraction — /paste-to-tasks - When to use which - API surface - complete() - complete_structured() - Async - Result attributes - Trust gate ### Section map ### The smallest possible call Maps the smallest possible call to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### A more complete chat example Maps a more complete chat example to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Structured output Maps structured output to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### What this lane gives you Maps what this lane gives you to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Quick start Maps quick start to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Chat completion — /tldr Maps chat completion — /tldr to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Structured extraction — /paste-to-tasks Maps structured extraction — /paste-to-tasks to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### When to use which Maps when to use which to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: The smallest possible call, A more complete chat example, Structured output, What this lane gives you, Quick start. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: plugin, access, supported, call., completion. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for plugin llm access before applying exact upstream commands. | | Verify first | The smallest possible call | Open the source anchor for The smallest possible call and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for The smallest possible call; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for A more complete chat example if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Programmatic Integration | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/programmatic-integration/ | | Source | https://hermesbible.com/docs/developer-guide/programmatic-integration | | Section | Developer Guide | ### Summary Hermes ships three protocols for driving the agent from external programs — IDE plugins, custom UIs, CI pipelines, embedded sub agents. Pick the one that matche ### Source outline - ACP (Agent Client Protocol) - TUI Gateway JSON-RPC - Method catalog (selected) - Events streamed back - Pi-style RPC mapping - OpenAI-Compatible API Server - Which one should I use? - Model hot-swapping - A note on --mode rpc ### Section map ### ACP (Agent Client Protocol) Maps acp (agent client protocol) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### TUI Gateway JSON-RPC Maps tui gateway json-rpc to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Method catalog (selected) Maps method catalog (selected) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Events streamed back Maps events streamed back to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Pi-style RPC mapping Maps pi-style rpc mapping to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### OpenAI-Compatible API Server Maps openai-compatible api server to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Which one should I use? Maps which one should i use? to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Model hot-swapping Maps model hot-swapping to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: ACP (Agent Client Protocol), TUI Gateway JSON-RPC, Method catalog (selected), Events streamed back, Pi-style RPC mapping. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: programmatic, integration, ships, three, protocols. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for programmatic integration before applying exact upstream commands. | | Verify first | ACP (Agent Client Protocol) | Open the source anchor for ACP (Agent Client Protocol) and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for ACP (Agent Client Protocol); do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for TUI Gateway JSON-RPC if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Tools Runtime | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/tools-runtime/ | | Source | https://hermesbible.com/docs/developer-guide/tools-runtime | | Section | Developer Guide | ### Summary Hermes tools are self registering functions grouped into toolsets and executed through a central registry/dispatch system. Primary files: Tool registration mode ### Source outline - Tool registration model - How registry.register() works - Discovery: discover_builtin_tools() - Tool availability checking (check_fn) - Toolset resolution - How get_tool_definitions() filters tools - Legacy toolset names - Dispatch - Dispatch flow: model tool_call → handler execution - Error wrapping - Agent-loop tools - Async bridging - The DANGEROUS_PATTERNS approval flow - Terminal/runtime environments ### Section map ### Tool registration model Maps tool registration model to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### How registry.register() works Maps how registry.register() works to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Discovery: discover_builtin_tools() Maps discovery: discover_builtin_tools() to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Tool availability checking (check_fn) Maps tool availability checking (check_fn) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Toolset resolution Maps toolset resolution to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### How get_tool_definitions() filters tools Maps how get_tool_definitions() filters tools to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Legacy toolset names Maps legacy toolset names to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Dispatch Maps dispatch to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Tool registration model, How registry.register() works, Discovery: discover_builtin_tools(), Tool availability checking (check_fn), Toolset resolution. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: tools, runtime, registering, functions, grouped. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for tools runtime before applying exact upstream commands. | | Verify first | Tool registration model | Open the source anchor for Tool registration model and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for Tool registration model; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for How registry.register() works if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Trajectory Format | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/trajectory-format/ | | Source | https://hermesbible.com/docs/developer-guide/trajectory-format | | Section | Developer Guide | ### Summary Trajectory Format Hermes Agent saves conversation trajectories in ShareGPT compatible JSONL format for use as training data, debugging artifacts, and reinforcem ### Source outline - File Naming Convention - JSONL Entry Format - CLI/Interactive Format (from _save_trajectory) - Batch Runner Format (from batch_runner.py) - Conversations Array (ShareGPT Format) - Complete Example - Normalization Rules - Reasoning Content Markup - Tool Call Normalization - Tool Response Normalization - System Message - Loading Trajectories - Loading for HuggingFace Datasets - Controlling Trajectory Saving ### Section map ### File Naming Convention Maps file naming convention to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### JSONL Entry Format Maps jsonl entry format to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### CLI/Interactive Format (from _save_trajectory) Maps cli/interactive format (from _save_trajectory) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Batch Runner Format (from batch_runner.py) Maps batch runner format (from batch_runner.py) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Conversations Array (ShareGPT Format) Maps conversations array (sharegpt format) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Complete Example Maps complete example to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Normalization Rules Maps normalization rules to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Reasoning Content Markup Maps reasoning content markup to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: File Naming Convention, JSONL Entry Format, CLI/Interactive Format (from _save_trajectory), Batch Runner Format (from batch_runner.py), Conversations Array (ShareGPT Format). Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: trajectory, format, saves, conversation, trajectories. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for trajectory format before applying exact upstream commands. | | Verify first | File Naming Convention | Open the source anchor for File Naming Convention and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for File Naming Convention; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for JSONL Entry Format if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Video Generation Provider Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/video-gen-provider-plugin/ | | Source | https://hermesbible.com/docs/developer-guide/video-gen-provider-plugin | | Section | Developer Guide | ### Summary Building a Video Generation Provider Plugin Video gen provider plugins register a backend that services every tool call. Built in providers (xAI, FAL) ship as p ### Source outline - The unified surface (one tool, two modalities) - How discovery works - Directory structure - The VideoGenProvider ABC - The plugin manifest - The video_generate schema - Model families and endpoint routing (the FAL pattern) - Selection precedence - Response shape - Where to save artifacts - Testing ### Section map ### The unified surface (one tool, two modalities) Maps the unified surface (one tool, two modalities) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### How discovery works Maps how discovery works to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Directory structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The VideoGenProvider ABC Maps the videogenprovider abc to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The plugin manifest Maps the plugin manifest to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The video_generate schema Maps the video_generate schema to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Model families and endpoint routing (the FAL pattern) Maps model families and endpoint routing (the fal pattern) to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Selection precedence Maps selection precedence to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: The unified surface (one tool, two modalities), How discovery works, Directory structure, The VideoGenProvider ABC, The plugin manifest. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: video, generation, provider, plugins, building. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for video generation provider plugins before applying exact upstream commands. | | Verify first | The unified surface (one tool, two modalities) | Open the source anchor for The unified surface (one tool, two modalities) and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for The unified surface (one tool, two modalities); do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for How discovery works if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Web Search Provider Plugins | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/developer-guide/web-search-provider-plugin/ | | Source | https://hermesbible.com/docs/developer-guide/web-search-provider-plugin | | Section | Developer Guide | ### Summary Building a Web Search Provider Plugin Web search provider plugins register a backend that services , , and (optionally) deep crawl tool calls. Built in provider ### Source outline - How discovery works - Directory structure - The WebSearchProvider ABC - plugin.yaml - ABC reference - Response shape - Capability flags - How Hermes wires it into the tools - Lazy-installing optional dependencies - Reference implementations - Distribute via pip - Related pages ### Section map ### How discovery works Maps how discovery works to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Directory structure Maps directory structure to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### The WebSearchProvider ABC Maps the websearchprovider abc to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### plugin.yaml Maps plugin.yaml to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### ABC reference Maps abc reference to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Response shape Maps response shape to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Capability flags Maps capability flags to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### How Hermes wires it into the tools Maps how hermes wires it into the tools to the Developer Guide documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Developer Guide doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How discovery works, Directory structure, The WebSearchProvider ABC, plugin.yaml, ABC reference. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: search, provider, plugins, building, plugin. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Developer Guide documentation | Use when you need orientation for web search provider plugins before applying exact upstream commands. | | Verify first | How discovery works | Open the source anchor for How discovery works and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Developer Guide, then open the linked source page for exact current syntax. - Start with the source section for How discovery works; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Directory structure if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Reference ## CLI Commands Reference | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/cli-commands/ | | Source | https://hermesbible.com/docs/reference/cli-commands | | Section | Reference | ### Summary This page covers the terminal commands you run from your shell. For in chat slash commands, see Slash Commands Reference. Global entrypoint Global options Optio ### Source outline - Global entrypoint - Global options - Top-level commands - hermes chat - hermes -z — scripted one-shot - hermes model - /model slash command (mid-session) - hermes gateway - hermes lsp - hermes setup - hermes portal - hermes whatsapp - hermes slack - hermes send ### Section map ### Global entrypoint Maps global entrypoint to the Reference documentation path, with the source page reserved for exact commands and updates. ### Global options Maps global options to the Reference documentation path, with the source page reserved for exact commands and updates. ### Top-level commands Maps top-level commands to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes chat Maps hermes chat to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes -z — scripted one-shot Maps hermes -z — scripted one-shot to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes model Maps hermes model to the Reference documentation path, with the source page reserved for exact commands and updates. ### /model slash command (mid-session) Maps /model slash command (mid-session) to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes gateway Maps hermes gateway to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Global entrypoint, Global options, Top-level commands, hermes chat, hermes -z — scripted one-shot. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: commands, reference, covers, terminal, shell.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for cli commands reference before applying exact upstream commands. | | Verify first | Global entrypoint | Open the source anchor for Global entrypoint and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for Global entrypoint; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Global options if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Slash Commands Reference | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/slash-commands/ | | Source | https://hermesbible.com/docs/reference/slash-commands | | Section | Reference | ### Summary Hermes has two slash command surfaces, both driven by a central in : Interactive CLI slash commands — dispatched by , with autocomplete from the registry Messag ### Source outline - Permissions and admin/user split - Interactive CLI slash commands - Session - Configuration - Tools & Skills - Info - Exit - Dynamic CLI slash commands - Quick Commands - Custom model aliases - Alias Resolution - Messaging slash commands - Notes - Confirmation prompts for destructive commands ### Section map ### Permissions and admin/user split Maps permissions and admin/user split to the Reference documentation path, with the source page reserved for exact commands and updates. ### Interactive CLI slash commands Maps interactive cli slash commands to the Reference documentation path, with the source page reserved for exact commands and updates. ### Session Maps session to the Reference documentation path, with the source page reserved for exact commands and updates. ### Configuration Maps configuration to the Reference documentation path, with the source page reserved for exact commands and updates. ### Tools & Skills Maps tools & skills to the Reference documentation path, with the source page reserved for exact commands and updates. ### Info Maps info to the Reference documentation path, with the source page reserved for exact commands and updates. ### Exit Maps exit to the Reference documentation path, with the source page reserved for exact commands and updates. ### Dynamic CLI slash commands Maps dynamic cli slash commands to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Permissions and admin/user split, Interactive CLI slash commands, Session, Configuration, Tools & Skills. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: slash, commands, reference, command, surfaces. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for slash commands reference before applying exact upstream commands. | | Verify first | Permissions and admin/user split | Open the source anchor for Permissions and admin/user split and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for Permissions and admin/user split; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Interactive CLI slash commands if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Profile Commands Reference | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/profile-commands/ | | Source | https://hermesbible.com/docs/reference/profile-commands | | Section | Reference | ### Summary Profile Commands Reference This page covers all commands related to Hermes profiles. For general CLI commands, see CLI Commands Reference. Top level command for ### Source outline - hermes profile - hermes profile list - hermes profile use - hermes profile create - hermes profile describe - hermes profile delete - hermes profile show - hermes profile alias - hermes profile rename - hermes profile export - hermes profile import - Distribution commands - hermes profile install - hermes profile update ### Section map ### hermes profile Maps hermes profile to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile list Maps hermes profile list to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile use Maps hermes profile use to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile create Maps hermes profile create to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile describe Maps hermes profile describe to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile delete Maps hermes profile delete to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile show Maps hermes profile show to the Reference documentation path, with the source page reserved for exact commands and updates. ### hermes profile alias Maps hermes profile alias to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: hermes profile, hermes profile list, hermes profile use, hermes profile create, hermes profile describe. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: profile, commands, reference, covers, related. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for profile commands reference before applying exact upstream commands. | | Verify first | hermes profile | Open the source anchor for hermes profile and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for hermes profile; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for hermes profile list if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Environment Variables | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/environment-variables/ | | Source | https://hermesbible.com/docs/reference/environment-variables | | Section | Reference | ### Summary Environment Variables Reference All variables go in . You can also set them with . LLM Providers Variable Description OpenRouter API key (recommended for flexib ### Source outline - LLM Providers - Provider Auth (OAuth) - Tool APIs - Langfuse Observability - Nous Tool Gateway - Terminal Backend - SSH Backend - Container Resources (Docker, Singularity, Modal, Daytona) - Persistent Shell - Messaging - Web Dashboard & Hermes Desktop - Microsoft Graph (Teams Meetings) - Microsoft Graph Webhook Listener - Teams Meeting Summary Delivery ### Section map ### LLM Providers Maps llm providers to the Reference documentation path, with the source page reserved for exact commands and updates. ### Provider Auth (OAuth) Maps provider auth (oauth) to the Reference documentation path, with the source page reserved for exact commands and updates. ### Tool APIs Maps tool apis to the Reference documentation path, with the source page reserved for exact commands and updates. ### Langfuse Observability Maps langfuse observability to the Reference documentation path, with the source page reserved for exact commands and updates. ### Nous Tool Gateway Maps nous tool gateway to the Reference documentation path, with the source page reserved for exact commands and updates. ### Terminal Backend Maps terminal backend to the Reference documentation path, with the source page reserved for exact commands and updates. ### SSH Backend Maps ssh backend to the Reference documentation path, with the source page reserved for exact commands and updates. ### Container Resources (Docker, Singularity, Modal, Daytona) Maps container resources (docker, singularity, modal, daytona) to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: LLM Providers, Provider Auth (OAuth), Tool APIs, Langfuse Observability, Nous Tool Gateway. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: environment, variables, reference, providers, variable. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for environment variables before applying exact upstream commands. | | Verify first | LLM Providers | Open the source anchor for LLM Providers and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for LLM Providers; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Provider Auth (OAuth) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## Built-in Tools Reference | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/tools-reference/ | | Source | https://hermesbible.com/docs/reference/tools-reference | | Section | Reference | ### Summary This page documents Hermes' built in tools, grouped by toolset. Availability varies by platform, credentials, and enabled toolsets. Quick counts (current regist ### Source outline - browser toolset - browser toolset (CDP-gated tools) - clarify toolset - code_execution toolset - cronjob toolset - delegation toolset - feishu_doc toolset - feishu_drive toolset - file toolset - homeassistant toolset - computer_use toolset - image_gen toolset - kanban toolset - memory toolset ### Section map ### browser toolset Maps browser toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### browser toolset (CDP-gated tools) Maps browser toolset (cdp-gated tools) to the Reference documentation path, with the source page reserved for exact commands and updates. ### clarify toolset Maps clarify toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### code_execution toolset Maps code_execution toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### cronjob toolset Maps cronjob toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### delegation toolset Maps delegation toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### feishu_doc toolset Maps feishu_doc toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### feishu_drive toolset Maps feishu_drive toolset to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: browser toolset, browser toolset (CDP-gated tools), clarify toolset, code_execution toolset, cronjob toolset. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: built-in, tools, reference, documents, grouped. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for built-in tools reference before applying exact upstream commands. | | Verify first | browser toolset | Open the source anchor for browser toolset and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for browser toolset; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for browser toolset (CDP-gated tools) if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Toolsets Reference | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/toolsets-reference/ | | Source | https://hermesbible.com/docs/reference/toolsets-reference | | Section | Reference | ### Summary Toolsets are named bundles of tools that control what the agent can do. They're the primary mechanism for configuring tool availability per platform, per sessio ### Source outline - How Toolsets Work - Configuring Toolsets - Per-session (CLI) - Per-platform (config.yaml) - Interactive management - Core Toolsets - Platform Toolsets - Dynamic Toolsets - MCP server toolsets - Plugin toolsets - Custom toolsets - Wildcards - Relationship to hermes tools ### Section map ### How Toolsets Work Maps how toolsets work to the Reference documentation path, with the source page reserved for exact commands and updates. ### Configuring Toolsets Maps configuring toolsets to the Reference documentation path, with the source page reserved for exact commands and updates. ### Per-session (CLI) Maps per-session (cli) to the Reference documentation path, with the source page reserved for exact commands and updates. ### Per-platform (config.yaml) Maps per-platform (config.yaml) to the Reference documentation path, with the source page reserved for exact commands and updates. ### Interactive management Maps interactive management to the Reference documentation path, with the source page reserved for exact commands and updates. ### Core Toolsets Maps core toolsets to the Reference documentation path, with the source page reserved for exact commands and updates. ### Platform Toolsets Maps platform toolsets to the Reference documentation path, with the source page reserved for exact commands and updates. ### Dynamic Toolsets Maps dynamic toolsets to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: How Toolsets Work, Configuring Toolsets, Per-session (CLI), Per-platform (config.yaml), Interactive management. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: toolsets, reference, named, bundles, tools. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for toolsets reference before applying exact upstream commands. | | Verify first | How Toolsets Work | Open the source anchor for How Toolsets Work and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for How Toolsets Work; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Configuring Toolsets if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## MCP Config Reference | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/mcp-config-reference/ | | Source | https://hermesbible.com/docs/reference/mcp-config-reference | | Section | Reference | ### Summary This page is the compact reference companion to the main MCP docs. For conceptual guidance, see: MCP (Model Context Protocol) Use MCP with Hermes Root config sh ### Source outline - Root config shape - Server keys - tools policy keys - Filtering semantics - include - exclude - Precedence - Utility-tool policy - Disable resources - Disable prompts - Capability-aware registration - enabled: false - Empty result behavior - Example configs ### Section map ### Root config shape Maps root config shape to the Reference documentation path, with the source page reserved for exact commands and updates. ### Server keys Maps server keys to the Reference documentation path, with the source page reserved for exact commands and updates. ### tools policy keys Maps tools policy keys to the Reference documentation path, with the source page reserved for exact commands and updates. ### Filtering semantics Maps filtering semantics to the Reference documentation path, with the source page reserved for exact commands and updates. ### include Maps include to the Reference documentation path, with the source page reserved for exact commands and updates. ### exclude Maps exclude to the Reference documentation path, with the source page reserved for exact commands and updates. ### Precedence Maps precedence to the Reference documentation path, with the source page reserved for exact commands and updates. ### Utility-tool policy Maps utility-tool policy to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Root config shape, Server keys, tools policy keys, Filtering semantics, include. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: config, reference, compact, companion, docs.. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for mcp config reference before applying exact upstream commands. | | Verify first | Root config shape | Open the source anchor for Root config shape and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for Root config shape; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Server keys if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Model Catalog | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/model-catalog/ | | Source | https://hermesbible.com/docs/reference/model-catalog | | Section | Reference | ### Summary Model Catalog Hermes fetches curated model lists for OpenRouter and Nous Portal from a JSON manifest hosted alongside the docs site. This lets maintainers updat ### Source outline - Live manifest URL - Schema - Fetch behavior - Config - Per-provider override URLs - Updating the manifest ### Section map ### Live manifest URL Maps live manifest url to the Reference documentation path, with the source page reserved for exact commands and updates. ### Schema Maps schema to the Reference documentation path, with the source page reserved for exact commands and updates. ### Fetch behavior Maps fetch behavior to the Reference documentation path, with the source page reserved for exact commands and updates. ### Config Maps config to the Reference documentation path, with the source page reserved for exact commands and updates. ### Per-provider override URLs Maps per-provider override urls to the Reference documentation path, with the source page reserved for exact commands and updates. ### Updating the manifest Maps updating the manifest to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Live manifest URL, Schema, Fetch behavior, Config, Per-provider override URLs. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: model, catalog, fetches, curated, lists. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for model catalog before applying exact upstream commands. | | Verify first | Live manifest URL | Open the source anchor for Live manifest URL and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for Live manifest URL; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for Schema if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Bundled Skills Catalog | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/skills-catalog/ | | Source | https://hermesbible.com/docs/reference/skills-catalog | | Section | Reference | ### Summary Hermes ships with a large built in skill library copied into on install. Each skill below links to a dedicated page with its full definition, setup, and usage. ### Source outline - apple - autonomous-ai-agents - creative - data-science - devops - dogfood - email - github - media - mlops - note-taking - productivity - research - smart-home ### Section map ### apple Maps apple to the Reference documentation path, with the source page reserved for exact commands and updates. ### autonomous-ai-agents Maps autonomous-ai-agents to the Reference documentation path, with the source page reserved for exact commands and updates. ### creative Maps creative to the Reference documentation path, with the source page reserved for exact commands and updates. ### data-science Maps data-science to the Reference documentation path, with the source page reserved for exact commands and updates. ### devops Maps devops to the Reference documentation path, with the source page reserved for exact commands and updates. ### dogfood Maps dogfood to the Reference documentation path, with the source page reserved for exact commands and updates. ### email Maps email to the Reference documentation path, with the source page reserved for exact commands and updates. ### github Maps github to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: apple, autonomous-ai-agents, creative, data-science, devops. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: bundled, skills, catalog, ships, large. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for bundled skills catalog before applying exact upstream commands. | | Verify first | apple | Open the source anchor for apple and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for apple; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for autonomous-ai-agents if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Optional Skills Catalog | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/optional-skills-catalog/ | | Source | https://hermesbible.com/docs/reference/optional-skills-catalog | | Section | Reference | ### Summary Optional skills ship with hermes agent under but are not active by default . Install them explicitly: For example: Each skill below links to a dedicated page wi ### Source outline - autonomous-ai-agents - blockchain - communication - creative - devops - dogfood - email - finance - gaming - health - mcp - migration - mlops - payments ### Section map ### autonomous-ai-agents Maps autonomous-ai-agents to the Reference documentation path, with the source page reserved for exact commands and updates. ### blockchain Maps blockchain to the Reference documentation path, with the source page reserved for exact commands and updates. ### communication Maps communication to the Reference documentation path, with the source page reserved for exact commands and updates. ### creative Maps creative to the Reference documentation path, with the source page reserved for exact commands and updates. ### devops Maps devops to the Reference documentation path, with the source page reserved for exact commands and updates. ### dogfood Maps dogfood to the Reference documentation path, with the source page reserved for exact commands and updates. ### email Maps email to the Reference documentation path, with the source page reserved for exact commands and updates. ### finance Maps finance to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: autonomous-ai-agents, blockchain, communication, creative, devops. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: optional, skills, catalog, under, active. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for optional skills catalog before applying exact upstream commands. | | Verify first | autonomous-ai-agents | Open the source anchor for autonomous-ai-agents and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for autonomous-ai-agents; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for blockchain if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | --- ## FAQ & Troubleshooting | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/docs/reference/faq/ | | Source | https://hermesbible.com/docs/reference/faq | | Section | Reference | ### Summary Quick answers and fixes for the most common questions and issues. Frequently Asked Questions What LLM providers work with Hermes? Hermes Agent works with any Op ### Source outline - Frequently Asked Questions - What LLM providers work with Hermes? - Does it work on Windows? - I run Hermes in WSL2. What's the best way to control my normal Windows Chrome? - Does it work on Android / Termux? - Is my data sent anywhere? - Can I use it offline / with local models? - How much does it cost? - Can multiple people use one instance? - What's the difference between memory and skills? - Can I use it in my own Python project? - Troubleshooting - Installation Issues - hermes: command not found after installation ### Section map ### Frequently Asked Questions Maps frequently asked questions to the Reference documentation path, with the source page reserved for exact commands and updates. ### What LLM providers work with Hermes? Maps what llm providers work with hermes? to the Reference documentation path, with the source page reserved for exact commands and updates. ### Does it work on Windows? Maps does it work on windows? to the Reference documentation path, with the source page reserved for exact commands and updates. ### I run Hermes in WSL2. What's the best way to control my normal Windows Chrome? Maps i run hermes in wsl2. what's the best way to control my normal windows chrome? to the Reference documentation path, with the source page reserved for exact commands and updates. ### Does it work on Android / Termux? Maps does it work on android / termux? to the Reference documentation path, with the source page reserved for exact commands and updates. ### Is my data sent anywhere? Maps is my data sent anywhere? to the Reference documentation path, with the source page reserved for exact commands and updates. ### Can I use it offline / with local models? Maps can i use it offline / with local models? to the Reference documentation path, with the source page reserved for exact commands and updates. ### How much does it cost? Maps how much does it cost? to the Reference documentation path, with the source page reserved for exact commands and updates. ### Implementation notes - Use this Reference doc as a navigation page first: the local clone mirrors the source structure and links each heading back to the authoritative upstream section. - Primary decision areas: Frequently Asked Questions, What LLM providers work with Hermes?, Does it work on Windows?, I run Hermes in WSL2. What's the best way to control my normal Windows Chrome?, Does it work on Android / Termux?. Read those source anchors before changing installs, credentials, automation, or runtime configuration. - Useful search signals for this doc: troubleshooting, quick, answers, fixes, common. These are derived from the public title and summary so the clone remains lightweight. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Reference documentation | Use when you need orientation for faq & troubleshooting before applying exact upstream commands. | | Verify first | Frequently Asked Questions | Open the source anchor for Frequently Asked Questions and confirm platform-specific requirements before changing configuration. | | Escalate to source | Commands, credentials, runtime behavior | Use the upstream page as the authority for current syntax, release changes, and security-sensitive steps. | ### Verification checklist - Use this page to orient yourself within Reference, then open the linked source page for exact current syntax. - Start with the source section for Frequently Asked Questions; do not rely on the local summary for commands or secrets. - Check platform, install method, provider, and credential assumptions before changing a real environment. - Review the source section for What LLM providers work with Hermes? if the page involves setup, automation, messaging, or runtime behavior. - After applying anything from the source, run the smallest relevant smoke test before widening scope. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Community Flows # Architecture ## Hermes Agent as a Personal AI Operating System | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-as-personal-ai-operating-system/ | | Source | https://hermesbible.com/flows/hermes-as-personal-ai-operating-system | | Author | YanXbt | | Category | Architecture | | Level | Community | | Platforms | Hermes Agent | | Tags | personal, operating, system, layer-by-layer, analysis, mapped, operating-system | | Reading time | 5 min | ### Summary A layer-by-layer analysis of Hermes mapped to operating-system concepts — memory, profiles, Kanban, cron, /goal, skills, the Curator, Tool Search, the Gateway, voice, and security — plus the compounding effect, token economics, and how it compares to other frameworks. ### Source outline - Overview - 1. Core Layers of Hermes - 1.1 Memory Architecture - 1.2 Profiles as Isolated Execution Environments - 1.3 Kanban as Orchestration and State Management - 1.4 Cron Jobs — The Scheduler - 1.5 /goal — Persistent Objectives (The Ralph Loop) - 1.6 Skill Creation Mechanisms - 1.7 Autonomous Curator — The Garbage Collector - 1.8 Tool Search — Dynamic Linker - 1.9 Gateway — The Network Stack - 1.10 Voice Mode — I/O Layer - 1.11 Security Layer - 1.12 Extensibility — Skills Hub and MCP Catalog ### Section map ### Overview Frames overview for this Architecture workflow, including the operating context to verify in the source page. ### 1. Core Layers of Hermes Frames 1. core layers of hermes for this Architecture workflow, including the operating context to verify in the source page. ### 1.1 Memory Architecture Frames 1.1 memory architecture for this Architecture workflow, including the operating context to verify in the source page. ### 1.2 Profiles as Isolated Execution Environments Frames 1.2 profiles as isolated execution environments for this Architecture workflow, including the operating context to verify in the source page. ### 1.3 Kanban as Orchestration and State Management Frames 1.3 kanban as orchestration and state management for this Architecture workflow, including the operating context to verify in the source page. ### 1.4 Cron Jobs — The Scheduler Frames 1.4 cron jobs — the scheduler for this Architecture workflow, including the operating context to verify in the source page. ### 1.5 /goal — Persistent Objectives (The Ralph Loop) Frames 1.5 /goal — persistent objectives (the ralph loop) for this Architecture workflow, including the operating context to verify in the source page. ### 1.6 Skill Creation Mechanisms Frames 1.6 skill creation mechanisms for this Architecture workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Architecture flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Overview, 1. Core Layers of Hermes, 1.1 Memory Architecture, 1.2 Profiles as Isolated Execution Environments, 1.3 Kanban as Orchestration and State Management. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: personal, operating, system, layer-by-layer, analysis. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Architecture workflow pattern | Use when the summary outcome matches your own workflow and overview is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Overview and 1. Core Layers of Hermes before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A layer-by-layer analysis of Hermes mapped to operating-system concepts — memory, profiles, Kanban, cron, /goal, skills, the Curator, Tool Search, the Gateway, voice, and security — plus the compounding effect, token economics, and how it compares to other frameworks. - Open the source section for Overview before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Overview and 1. Core Layers of Hermes. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## 8 Loops Inside Hermes Agent (And Why They Compound) | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/8-loops-inside-hermes-agent/ | | Source | https://hermesbible.com/flows/8-loops-inside-hermes-agent | | Author | YanXbt | | Category | Architecture | | Level | Community | | Platforms | Hermes Agent | | Tags | loops, inside, compound, eight, simultaneously, millisecond, weekly | | Reading time | 5 min | ### Summary A complete map of the eight loops Hermes Agent runs simultaneously — from the millisecond core loop to the weekly Curator — how they nest across timescales, and what breaks when any one of them fails. ### Source outline - Overview - What is a loop in agent architecture? - Loop 1 — The core agent loop - Loop 2 — The Ralph loop (/goal) - Loop 3 — The self-improvement loop - Loop 4 — The Curator loop - Loop 5 — The memory loop - Loop 6 — The Kanban dispatcher loop - Loop 7 — The compression loop - Loop 8 — The sub-agent loop - How the loops nest - How Hermes compares to other loop architectures - Token cost per loop - Start here ### Section map ### Overview Frames overview for this Architecture workflow, including the operating context to verify in the source page. ### What is a loop in agent architecture? Frames what is a loop in agent architecture? for this Architecture workflow, including the operating context to verify in the source page. ### Loop 1 — The core agent loop Frames loop 1 — the core agent loop for this Architecture workflow, including the operating context to verify in the source page. ### Loop 2 — The Ralph loop (/goal) Frames loop 2 — the ralph loop (/goal) for this Architecture workflow, including the operating context to verify in the source page. ### Loop 3 — The self-improvement loop Frames loop 3 — the self-improvement loop for this Architecture workflow, including the operating context to verify in the source page. ### Loop 4 — The Curator loop Frames loop 4 — the curator loop for this Architecture workflow, including the operating context to verify in the source page. ### Loop 5 — The memory loop Frames loop 5 — the memory loop for this Architecture workflow, including the operating context to verify in the source page. ### Loop 6 — The Kanban dispatcher loop Frames loop 6 — the kanban dispatcher loop for this Architecture workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Architecture flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Overview, What is a loop in agent architecture?, Loop 1 — The core agent loop, Loop 2 — The Ralph loop (/goal), Loop 3 — The self-improvement loop. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: loops, inside, compound, eight, simultaneously. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Architecture workflow pattern | Use when the summary outcome matches your own workflow and overview is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Overview and What is a loop in agent architecture? before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A complete map of the eight loops Hermes Agent runs simultaneously — from the millisecond core loop to the weekly Curator — how they nest across timescales, and what breaks when any one of them fails. - Open the source section for Overview before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Overview and What is a loop in agent architecture?. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Automation ## How to Make Hermes + xurl Actually Work as a System | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-xurl-as-a-system/ | | Source | https://hermesbible.com/flows/hermes-xurl-as-a-system | | Author | YanXbt | | Category | Automation | | Level | Community | | Platforms | Hermes Agent, X | | Tags | actually, system, gives, direct, access, searching, reading | | Reading time | 5 min | ### Summary xurl gives your Hermes agent direct access to X — searching, reading, and publishing. On its own it's just an execution tool. Paired with /goal, research, and memory, it becomes a structured, repeatable content system. ### Source outline - What This Flow Covers - Why Basic xurl Usage Falls Short - Best Skill Combinations - xurl + /goal - xurl + Research Skills - xurl + Multi-step Reasoning - xurl + Memory / Planning - How to Build a Recurring Content Workflow - Common Mistakes and How to Avoid Them - How to Start (Step-by-Step) - Step 1: Create Your First Basic Goal - Step 2: Add Structure to the Process - Step 3: Introduce Memory and Repetition Control - Step 4: Add Quality Evaluation ### Section map ### What This Flow Covers Frames what this flow covers for this Automation workflow, including the operating context to verify in the source page. ### Why Basic xurl Usage Falls Short Frames why basic xurl usage falls short for this Automation workflow, including the operating context to verify in the source page. ### Best Skill Combinations Frames best skill combinations for this Automation workflow, including the operating context to verify in the source page. ### xurl + /goal Frames xurl + /goal for this Automation workflow, including the operating context to verify in the source page. ### xurl + Research Skills Frames xurl + research skills for this Automation workflow, including the operating context to verify in the source page. ### xurl + Multi-step Reasoning Frames xurl + multi-step reasoning for this Automation workflow, including the operating context to verify in the source page. ### xurl + Memory / Planning Frames xurl + memory / planning for this Automation workflow, including the operating context to verify in the source page. ### How to Build a Recurring Content Workflow Frames how to build a recurring content workflow for this Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What This Flow Covers, Why Basic xurl Usage Falls Short, Best Skill Combinations, xurl + /goal, xurl + Research Skills. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: actually, system, gives, direct, access. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Automation workflow pattern | Use when the summary outcome matches your own workflow and what this flow covers is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What This Flow Covers and Why Basic xurl Usage Falls Short before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: xurl gives your Hermes agent direct access to X — searching, reading, and publishing. On its own it's just an execution tool. Paired with /goal, research, and memory, it becomes a structured, repeatable content system. - Open the source section for What This Flow Covers before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What This Flow Covers and Why Basic xurl Usage Falls Short. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Hermes /goal — The Full Guide | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-goal-the-full-guide/ | | Source | https://hermesbible.com/flows/hermes-goal-the-full-guide | | Author | YanXbt | | Category | Automation | | Level | Community | | Platforms | X | | Tags | /goal, command, every, subcommand, write, strong, measurable | | Reading time | 5 min | ### Summary A complete guide to Hermes' /goal command — what it does, every subcommand, how to write strong measurable goals, the recommended workflow, best practices, and ready-to-use example prompts. ### Source outline - What /goal is and why it matters - Main commands - How to write strong goals - Recommended workflow - Best practices and common mistakes - When to use /goal - Example /goal prompts ### Section map ### What /goal is and why it matters Frames what /goal is and why it matters for this Automation workflow, including the operating context to verify in the source page. ### Main commands Frames main commands for this Automation workflow, including the operating context to verify in the source page. ### How to write strong goals Frames how to write strong goals for this Automation workflow, including the operating context to verify in the source page. ### Recommended workflow Frames recommended workflow for this Automation workflow, including the operating context to verify in the source page. ### Best practices and common mistakes Frames best practices and common mistakes for this Automation workflow, including the operating context to verify in the source page. ### When to use /goal Frames when to use /goal for this Automation workflow, including the operating context to verify in the source page. ### Example /goal prompts Frames example /goal prompts for this Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What /goal is and why it matters, Main commands, How to write strong goals, Recommended workflow, Best practices and common mistakes. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: /goal, command, every, subcommand, write. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Automation workflow pattern | Use when the summary outcome matches your own workflow and what /goal is and why it matters is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What /goal is and why it matters and Main commands before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A complete guide to Hermes' /goal command — what it does, every subcommand, how to write strong measurable goals, the recommended workflow, best practices, and ready-to-use example prompts. - Open the source section for What /goal is and why it matters before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What /goal is and why it matters and Main commands. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Hermes Agent Builds Itself While You Sleep: The Complete Guide to the 9-Hour Overnight Workflow | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-9-hour-overnight-workflow/ | | Source | https://hermesbible.com/flows/hermes-9-hour-overnight-workflow | | Author | YanXbt | | Category | Automation | | Level | Community | | Platforms | Hermes Agent | | Tags | builds, itself, while, sleep, 9-hour, overnight, workflow | | Reading time | 5 min | ### Summary A full hour-by-hour map of the autonomous overnight cycle — from session close and self-improvement to knowledge ingestion, the morning briefing, the infrastructure behind it, and the security layers that make unattended operation safe. ### Source outline - Why "While You Sleep" Is Not Marketing - The 24-Hour Timeline - 23:00 — Session close - 23:30 — Self-improvement loop - 00:00 — Curator check - 02:00 — Competitive intel cron - 03:00 — Knowledge ingestion - 04:00 — Scheduled reports - 06:00 — Morning briefing prep - 07:00 — Kanban dispatcher - 08:00 — Briefing lands - What You Review in the Morning - The morning shortcut command - The Infrastructure That Makes This Work ### Section map ### Why "While You Sleep" Is Not Marketing Frames why "while you sleep" is not marketing for this Automation workflow, including the operating context to verify in the source page. ### The 24-Hour Timeline Frames the 24-hour timeline for this Automation workflow, including the operating context to verify in the source page. ### 23:00 — Session close Frames 23:00 — session close for this Automation workflow, including the operating context to verify in the source page. ### 23:30 — Self-improvement loop Frames 23:30 — self-improvement loop for this Automation workflow, including the operating context to verify in the source page. ### 00:00 — Curator check Frames 00:00 — curator check for this Automation workflow, including the operating context to verify in the source page. ### 02:00 — Competitive intel cron Frames 02:00 — competitive intel cron for this Automation workflow, including the operating context to verify in the source page. ### 03:00 — Knowledge ingestion Frames 03:00 — knowledge ingestion for this Automation workflow, including the operating context to verify in the source page. ### 04:00 — Scheduled reports Frames 04:00 — scheduled reports for this Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Why "While You Sleep" Is Not Marketing, The 24-Hour Timeline, 23:00 — Session close, 23:30 — Self-improvement loop, 00:00 — Curator check. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: builds, itself, while, sleep, 9-hour. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Automation workflow pattern | Use when the summary outcome matches your own workflow and why "while you sleep" is not marketing is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Why "While You Sleep" Is Not Marketing and The 24-Hour Timeline before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A full hour-by-hour map of the autonomous overnight cycle — from session close and self-improvement to knowledge ingestion, the morning briefing, the infrastructure behind it, and the security layers that make unattended operation safe. - Open the source section for Why "While You Sleep" Is Not Marketing before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Why "While You Sleep" Is Not Marketing and The 24-Hour Timeline. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Grok + Hermes + Telegram: A Real-Time X Intelligence Stack | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/grok-hermes-telegram-realtime-x-stack/ | | Source | https://hermesbible.com/flows/grok-hermes-telegram-realtime-x-stack | | Author | YanXbt | | Category | Automation | | Level | Community | | Platforms | Hermes Agent, Telegram, Grok, X | | Tags | telegram, real-time, intelligence, stack, native, access, persistent | | Reading time | 5 min | ### Summary Pair Grok's native real-time X access with Hermes Agent's persistent scheduling and Telegram delivery to build a 24/7 intelligence agent that drafts a morning brief before you wake up — using your existing SuperGrok subscription. ### Source outline - Why this stack works - Part 1 — Install Hermes - Part 2 — Connect Grok (no API key needed) - Part 3 — Connect Telegram - Part 4 — Real-time X search - Part 5 — A morning brief that runs itself - Mistakes to avoid - The takeaway ### Section map ### Why this stack works Frames why this stack works for this Automation workflow, including the operating context to verify in the source page. ### Part 1 — Install Hermes Frames part 1 — install hermes for this Automation workflow, including the operating context to verify in the source page. ### Part 2 — Connect Grok (no API key needed) Frames part 2 — connect grok (no api key needed) for this Automation workflow, including the operating context to verify in the source page. ### Part 3 — Connect Telegram Frames part 3 — connect telegram for this Automation workflow, including the operating context to verify in the source page. ### Part 4 — Real-time X search Frames part 4 — real-time x search for this Automation workflow, including the operating context to verify in the source page. ### Part 5 — A morning brief that runs itself Frames part 5 — a morning brief that runs itself for this Automation workflow, including the operating context to verify in the source page. ### Mistakes to avoid Frames mistakes to avoid for this Automation workflow, including the operating context to verify in the source page. ### The takeaway Frames the takeaway for this Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Why this stack works, Part 1 — Install Hermes, Part 2 — Connect Grok (no API key needed), Part 3 — Connect Telegram, Part 4 — Real-time X search. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: telegram, real-time, intelligence, stack, native. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Automation workflow pattern | Use when the summary outcome matches your own workflow and why this stack works is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Why this stack works and Part 1 — Install Hermes before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Pair Grok's native real-time X access with Hermes Agent's persistent scheduling and Telegram delivery to build a 24/7 intelligence agent that drafts a morning brief before you wake up — using your existing SuperGrok subscription. - Open the source section for Why this stack works before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Why this stack works and Part 1 — Install Hermes. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | --- ## The Complete Hermes Agent /goal Playbook | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/complete-goal-playbook-21-workflows/ | | Source | https://hermesbible.com/flows/complete-goal-playbook-21-workflows | | Author | YanXbt | | Category | Automation | | Level | Community | | Platforms | Hermes Agent | | Tags | /goal, playbook, copy-paste, commands, across, categories, research | | Reading time | 5 min | ### Summary 21 copy-paste /goal commands across 6 categories — research, lead gen, content, email, operations, and development — plus a Chief of Staff setup that runs your entire morning ops autonomously. ### Source outline - What is /goal? - The four commands you need - Category 1 — Research & Intelligence - 1. Competitor Intelligence Brief - 2. Market Trend Tracker - 3. Audience Research Agent - 4. Content Gap Analysis - Category 2 — Lead Generation & Sales - 5. Lead Research Agent - 6. Prospect Monitoring Agent - 7. Sales Pipeline Qualifier - Category 3 — Content & Social Media - 8. X Morning Brief - 9. Viral Post Analyzer ### Section map ### What is /goal? Frames what is /goal? for this Automation workflow, including the operating context to verify in the source page. ### The four commands you need Frames the four commands you need for this Automation workflow, including the operating context to verify in the source page. ### Category 1 — Research & Intelligence Frames category 1 — research & intelligence for this Automation workflow, including the operating context to verify in the source page. ### 1. Competitor Intelligence Brief Frames 1. competitor intelligence brief for this Automation workflow, including the operating context to verify in the source page. ### 2. Market Trend Tracker Frames 2. market trend tracker for this Automation workflow, including the operating context to verify in the source page. ### 3. Audience Research Agent Frames 3. audience research agent for this Automation workflow, including the operating context to verify in the source page. ### 4. Content Gap Analysis Frames 4. content gap analysis for this Automation workflow, including the operating context to verify in the source page. ### Category 2 — Lead Generation & Sales Frames category 2 — lead generation & sales for this Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What is /goal?, The four commands you need, Category 1 — Research & Intelligence, 1. Competitor Intelligence Brief, 2. Market Trend Tracker. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: /goal, playbook, copy-paste, commands, across. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Automation workflow pattern | Use when the summary outcome matches your own workflow and what is /goal? is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What is /goal? and The four commands you need before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: 21 copy-paste /goal commands across 6 categories — research, lead gen, content, email, operations, and development — plus a Chief of Staff setup that runs your entire morning ops autonomously. - Open the source section for What is /goal? before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What is /goal? and The four commands you need. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## 10 Hermes Agent Hacks That Turned My Chat Agent Into a 24/7 System | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/10-hermes-hacks-24-7-system/ | | Source | https://hermesbible.com/flows/10-hermes-hacks-24-7-system | | Author | YanXbt | | Category | Automation | | Level | Community | | Platforms | Hermes Agent, Telegram | | Tags | hacks, turned, system, domain-agnostic, setups, mission, control | | Reading time | 5 min | ### Summary Ten domain-agnostic Hermes setups — mission control, event triggers, cron jobs, structured /goal, sub-agents, Telegram workspaces, Kanban, skills, webhooks, and separate agents — that turn a chat window into a system that runs while you sleep. ### Source outline - Overview - Setup time and time saved - 1. Mission Control - 2. Event Triggers - 3. Cron Jobs - 4. /goal With Structure - 5. Sub-Agents as a Research Team - 6. Telegram Topics as Workspaces - 7. Kanban for Task Management - 8. Skills as SOPs - 9. Webhooks and Event-Based Agents - 10. Separate Agents by Job - How They Chain Together - The Real Insight ### Section map ### Overview Frames overview for this Automation workflow, including the operating context to verify in the source page. ### Setup time and time saved Frames setup time and time saved for this Automation workflow, including the operating context to verify in the source page. ### 1. Mission Control Frames 1. mission control for this Automation workflow, including the operating context to verify in the source page. ### 2. Event Triggers Frames 2. event triggers for this Automation workflow, including the operating context to verify in the source page. ### 3. Cron Jobs Frames 3. cron jobs for this Automation workflow, including the operating context to verify in the source page. ### 4. /goal With Structure Frames 4. /goal with structure for this Automation workflow, including the operating context to verify in the source page. ### 5. Sub-Agents as a Research Team Frames 5. sub-agents as a research team for this Automation workflow, including the operating context to verify in the source page. ### 6. Telegram Topics as Workspaces Frames 6. telegram topics as workspaces for this Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Overview, Setup time and time saved, 1. Mission Control, 2. Event Triggers, 3. Cron Jobs. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: hacks, turned, system, domain-agnostic, setups. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Automation workflow pattern | Use when the summary outcome matches your own workflow and overview is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Overview and Setup time and time saved before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Ten domain-agnostic Hermes setups — mission control, event triggers, cron jobs, structured /goal, sub-agents, Telegram workspaces, Kanban, skills, webhooks, and separate agents — that turn a chat window into a system that runs while you sleep. - Open the source section for Overview before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Overview and Setup time and time saved. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | --- # Configuration ## Hermes Agent SOUL.md: Why 50 Lines Matter More Than Your Model | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/soul-md-why-50-lines-matter-more-than-your-model/ | | Source | https://hermesbible.com/flows/soul-md-why-50-lines-matter-more-than-your-model | | Author | YanXbt | | Category | Configuration | | Level | Community | | Platforms | Hermes Agent, SOUL.md | | Tags | soul.md, lines, matter, model, where, prompt, stack | | Reading time | 5 min | ### Summary A complete guide to SOUL.md — where it sits in the prompt stack, what belongs in it, token economics, advanced role templates, /personality overlays, profiles, and the iterative method for growing an effective agent identity. ### Source outline - 1. What SOUL.md Actually Is - 2. Where SOUL.md Sits in the Prompt Stack - 3. The Rules: What Goes In and What Does Not - Voice - Restrictions - The injection scanner - 4. Token Impact - 5. The Structure That Works - Voice - Operations - Restrictions - Style - Avoid - 6. Advanced SOUL.md Templates ### Section map ### 1. What SOUL.md Actually Is Frames 1. what soul.md actually is for this Configuration workflow, including the operating context to verify in the source page. ### 2. Where SOUL.md Sits in the Prompt Stack Frames 2. where soul.md sits in the prompt stack for this Configuration workflow, including the operating context to verify in the source page. ### 3. The Rules: What Goes In and What Does Not Frames 3. the rules: what goes in and what does not for this Configuration workflow, including the operating context to verify in the source page. ### Voice Frames voice for this Configuration workflow, including the operating context to verify in the source page. ### Restrictions Frames restrictions for this Configuration workflow, including the operating context to verify in the source page. ### The injection scanner Frames the injection scanner for this Configuration workflow, including the operating context to verify in the source page. ### 4. Token Impact Frames 4. token impact for this Configuration workflow, including the operating context to verify in the source page. ### 5. The Structure That Works Frames 5. the structure that works for this Configuration workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Configuration flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: 1. What SOUL.md Actually Is, 2. Where SOUL.md Sits in the Prompt Stack, 3. The Rules: What Goes In and What Does Not, Voice, Restrictions. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: soul.md, lines, matter, model, where. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Configuration workflow pattern | Use when the summary outcome matches your own workflow and 1. what soul.md actually is is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for 1. What SOUL.md Actually Is and 2. Where SOUL.md Sits in the Prompt Stack before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A complete guide to SOUL.md — where it sits in the prompt stack, what belongs in it, token economics, advanced role templates, /personality overlays, profiles, and the iterative method for growing an effective agent identity. - Open the source section for 1. What SOUL.md Actually Is before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for 1. What SOUL.md Actually Is and 2. Where SOUL.md Sits in the Prompt Stack. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## I'm Not Sharing My SOUL.md. I'm Sharing Something More Useful. | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/soul-md-operating-contract-template/ | | Source | https://hermesbible.com/flows/soul-md-operating-contract-template | | Author | Tony | | Category | Configuration | | Level | Community | | Platforms | Hermes Agent, SOUL.md | | Tags | sharing, soul.md., something, useful., soul.md, operating, contract | | Reading time | 5 min | ### Summary Why a SOUL.md is an operating contract, not a personality hack — plus a sanitized, copy-paste template you can adapt to make your Hermes Agent behave like an operator instead of a chatbot. ### Source outline - The question everyone asks - Why this exists - What this template is - What you should customize - The template - Stance - Accountability - Pushback - Autonomy - Mission - Tone & Communication - Private work - Public-facing work - Operating Mode ### Section map ### The question everyone asks Frames the question everyone asks for this Configuration workflow, including the operating context to verify in the source page. ### Why this exists Frames why this exists for this Configuration workflow, including the operating context to verify in the source page. ### What this template is Frames what this template is for this Configuration workflow, including the operating context to verify in the source page. ### What you should customize Frames what you should customize for this Configuration workflow, including the operating context to verify in the source page. ### The template Frames the template for this Configuration workflow, including the operating context to verify in the source page. ### Stance Frames stance for this Configuration workflow, including the operating context to verify in the source page. ### Accountability Frames accountability for this Configuration workflow, including the operating context to verify in the source page. ### Pushback Frames pushback for this Configuration workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Configuration flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: The question everyone asks, Why this exists, What this template is, What you should customize, The template. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: sharing, soul.md., something, useful., soul.md. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Configuration workflow pattern | Use when the summary outcome matches your own workflow and the question everyone asks is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for The question everyone asks and Why this exists before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Why a SOUL.md is an operating contract, not a personality hack — plus a sanitized, copy-paste template you can adapt to make your Hermes Agent behave like an operator instead of a chatbot. - Open the source section for The question everyone asks before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for The question everyone asks and Why this exists. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## The 170-Line SOUL.md That Made My Hermes Agent Dangerous | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/170-line-soul-md-that-made-hermes-dangerous/ | | Source | https://hermesbible.com/flows/170-line-soul-md-that-made-hermes-dangerous | | Author | Tony | | Category | Configuration | | Level | Community | | Platforms | Hermes Agent, SOUL.md | | Tags | 170-line, soul.md, dangerous, single, markdown, secret, model | | Reading time | 5 min | ### Summary Why a single 170-line markdown file — not a secret model or magic framework — is what makes a Hermes Agent push back, hold you accountable, and act like an operator instead of a chatbot. ### Source outline - The file that changes everything - Most people train their AI to be useless - It is required to push back - It holds you accountable too - Hermes has a split personality (on purpose) - It knows exactly what you're building - The autonomy boundary is brutally simple - Why "be helpful" doesn't work - How to build your own SOUL - Final thought ### Section map ### The file that changes everything Frames the file that changes everything for this Configuration workflow, including the operating context to verify in the source page. ### Most people train their AI to be useless Frames most people train their ai to be useless for this Configuration workflow, including the operating context to verify in the source page. ### It is required to push back Frames it is required to push back for this Configuration workflow, including the operating context to verify in the source page. ### It holds you accountable too Frames it holds you accountable too for this Configuration workflow, including the operating context to verify in the source page. ### Hermes has a split personality (on purpose) Frames hermes has a split personality (on purpose) for this Configuration workflow, including the operating context to verify in the source page. ### It knows exactly what you're building Frames it knows exactly what you're building for this Configuration workflow, including the operating context to verify in the source page. ### The autonomy boundary is brutally simple Frames the autonomy boundary is brutally simple for this Configuration workflow, including the operating context to verify in the source page. ### Why "be helpful" doesn't work Frames why "be helpful" doesn't work for this Configuration workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Configuration flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: The file that changes everything, Most people train their AI to be useless, It is required to push back, It holds you accountable too, Hermes has a split personality (on purpose). Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: 170-line, soul.md, dangerous, single, markdown. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Configuration workflow pattern | Use when the summary outcome matches your own workflow and the file that changes everything is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for The file that changes everything and Most people train their AI to be useless before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Why a single 170-line markdown file — not a secret model or magic framework — is what makes a Hermes Agent push back, hold you accountable, and act like an operator instead of a chatbot. - Open the source section for The file that changes everything before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for The file that changes everything and Most people train their AI to be useless. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## 10 Real Hermes Agent Settings That Actually Matter | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/10-hermes-settings-that-matter/ | | Source | https://hermesbible.com/flows/10-hermes-settings-that-matter | | Author | Tony | | Category | Configuration | | Level | Community | | Platforms | Hermes Agent, MCP, X | | Tags | settings, actually, matter, no-nonsense, rundown, configuration, moves | | Reading time | 5 min | ### Summary A no-nonsense rundown of the real Hermes configuration that moves the needle — identity, memory, profiles, cron, gateway, MCP, skills, context files, delegation, and plugins. Real config keys and commands only, no made-up env vars. ### Source outline - Why this list exists - 1. SOUL.md — the thing that gives Hermes a spine - Style - Technical posture - 2. Memory config — because forgetting everything is embarrassing - 3. Profiles — because one Hermes for everything turns into a mess - 4. Cron scheduling with --deliver — where chat turns into operations - 5. Gateway — because your agent shouldn't be trapped in a terminal - 6. MCP servers — the cleanest way to bolt Hermes onto the rest of your stack - 7. Skills — where Hermes stops solving the same problem from scratch - 8. Context files — so the project doesn't need a full re-explanation every time - 9. Subagent delegation — the thing that makes one agent feel like five - 10. Plugins — where the extension system gets fun - The actual lesson ### Section map ### Why this list exists Frames why this list exists for this Configuration workflow, including the operating context to verify in the source page. ### 1. SOUL.md — the thing that gives Hermes a spine Frames 1. soul.md — the thing that gives hermes a spine for this Configuration workflow, including the operating context to verify in the source page. ### Style Frames style for this Configuration workflow, including the operating context to verify in the source page. ### Technical posture Frames technical posture for this Configuration workflow, including the operating context to verify in the source page. ### 2. Memory config — because forgetting everything is embarrassing Frames 2. memory config — because forgetting everything is embarrassing for this Configuration workflow, including the operating context to verify in the source page. ### 3. Profiles — because one Hermes for everything turns into a mess Frames 3. profiles — because one hermes for everything turns into a mess for this Configuration workflow, including the operating context to verify in the source page. ### 4. Cron scheduling with --deliver — where chat turns into operations Frames 4. cron scheduling with --deliver — where chat turns into operations for this Configuration workflow, including the operating context to verify in the source page. ### 5. Gateway — because your agent shouldn't be trapped in a terminal Frames 5. gateway — because your agent shouldn't be trapped in a terminal for this Configuration workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Configuration flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Why this list exists, 1. SOUL.md — the thing that gives Hermes a spine, Style, Technical posture, 2. Memory config — because forgetting everything is embarrassing. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: settings, actually, matter, no-nonsense, rundown. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Configuration workflow pattern | Use when the summary outcome matches your own workflow and why this list exists is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Why this list exists and 1. SOUL.md — the thing that gives Hermes a spine before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A no-nonsense rundown of the real Hermes configuration that moves the needle — identity, memory, profiles, cron, gateway, MCP, skills, context files, delegation, and plugins. Real config keys and commands only, no made-up env vars. - Open the source section for Why this list exists before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Why this list exists and 1. SOUL.md — the thing that gives Hermes a spine. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Desktop & GUI ## Hermes Desktop: a full tour of the native GUI for Hermes Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-desktop-full-tour/ | | Source | https://hermesbible.com/flows/hermes-desktop-full-tour | | Author | Tony | | Category | Desktop & GUI | | Level | Community | | Platforms | Hermes Agent | | Tags | desktop, native, hands-on, walkthrough, electron, wraps, runtime. | | Reading time | 5 min | ### Summary A hands-on walkthrough of Hermes Desktop — the native Electron app that wraps the full Hermes Agent runtime. Same config, keys, sessions, skills, and memory as the CLI and TUI, with a real settings UI, live tool output, a file browser, voice mode, and remote-backend support. ### Source outline - What Hermes Desktop Actually Is - How to Install Hermes Desktop - Fresh install (no Hermes yet) - Add Desktop to an existing Hermes install - First Launch and Onboarding - The Chat Experience - File Browser - Voice Mode - Settings and Configuration - Management Panes - Keyboard and Navigation - Connecting to a Remote Backend - Troubleshooting remote connections - Updating and Uninstalling ### Section map ### What Hermes Desktop Actually Is Frames what hermes desktop actually is for this Desktop & GUI workflow, including the operating context to verify in the source page. ### How to Install Hermes Desktop Frames how to install hermes desktop for this Desktop & GUI workflow, including the operating context to verify in the source page. ### Fresh install (no Hermes yet) Frames fresh install (no hermes yet) for this Desktop & GUI workflow, including the operating context to verify in the source page. ### Add Desktop to an existing Hermes install Frames add desktop to an existing hermes install for this Desktop & GUI workflow, including the operating context to verify in the source page. ### First Launch and Onboarding Frames first launch and onboarding for this Desktop & GUI workflow, including the operating context to verify in the source page. ### The Chat Experience Frames the chat experience for this Desktop & GUI workflow, including the operating context to verify in the source page. ### File Browser Frames file browser for this Desktop & GUI workflow, including the operating context to verify in the source page. ### Voice Mode Frames voice mode for this Desktop & GUI workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Desktop & GUI flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What Hermes Desktop Actually Is, How to Install Hermes Desktop, Fresh install (no Hermes yet), Add Desktop to an existing Hermes install, First Launch and Onboarding. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: desktop, native, hands-on, walkthrough, electron. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Desktop & GUI workflow pattern | Use when the summary outcome matches your own workflow and what hermes desktop actually is is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What Hermes Desktop Actually Is and How to Install Hermes Desktop before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A hands-on walkthrough of Hermes Desktop — the native Electron app that wraps the full Hermes Agent runtime. Same config, keys, sessions, skills, and memory as the CLI and TUI, with a real settings UI, live tool output, a file browser, voice mode, and remote-backend support. - Open the source section for What Hermes Desktop Actually Is before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What Hermes Desktop Actually Is and How to Install Hermes Desktop. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Engineering Automation ## How we used four AI agents to turn Jira tickets into reviewed PRs for about $12 each | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/jira-to-pr-four-agents/ | | Source | https://hermesbible.com/flows/jira-to-pr-four-agents | | Author | Luke | | Category | Engineering Automation | | Level | Community | | Platforms | Hermes Agent, Jira | | Tags | agents, tickets, reviewed, about, event-driven, engineering, workflow | | Reading time | 5 min | ### Summary An event-driven engineering workflow where four specialized Hermes agents handle ticket intake, coding, review, and CI — while humans keep merge authority. Routine tickets go from intake to reviewed PR in about four hours for roughly $12 in AI spend. ### Source outline - 1. The Architecture - The Four Named Agents - 1. Mark — The Intake & Gate Agent (Claude 3.5 Haiku) - 2. Andrew — The Senior Coder (OpenAI 5.5 Pro, fallback Claude Opus 4.8) - 3. Rev — The Code Reviewer (Claude 3.5 Haiku) - 4. Mr. Pipeline — The CI/Lint/Style Gate (Claude Haiku) - Communication Paths - 2. The Event-Driven Flow - Step 1: Ticket Created in Jira - Step 2: Mark Intake (Orchestration) - Step 3: Andrew Codes (Implementation) - Acceptance Criteria - Tests - Changes ### Section map ### 1. The Architecture Frames 1. the architecture for this Engineering Automation workflow, including the operating context to verify in the source page. ### The Four Named Agents Frames the four named agents for this Engineering Automation workflow, including the operating context to verify in the source page. ### Communication Paths Frames communication paths for this Engineering Automation workflow, including the operating context to verify in the source page. ### 2. The Event-Driven Flow Frames 2. the event-driven flow for this Engineering Automation workflow, including the operating context to verify in the source page. ### Step 1: Ticket Created in Jira Frames step 1: ticket created in jira for this Engineering Automation workflow, including the operating context to verify in the source page. ### Step 2: Mark Intake (Orchestration) Frames step 2: mark intake (orchestration) for this Engineering Automation workflow, including the operating context to verify in the source page. ### Step 3: Andrew Codes (Implementation) Frames step 3: andrew codes (implementation) for this Engineering Automation workflow, including the operating context to verify in the source page. ### Acceptance Criteria Frames acceptance criteria for this Engineering Automation workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Engineering Automation flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: 1. The Architecture, The Four Named Agents, Communication Paths, 2. The Event-Driven Flow, Step 1: Ticket Created in Jira. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: agents, tickets, reviewed, about, event-driven. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Engineering Automation workflow pattern | Use when the summary outcome matches your own workflow and 1. the architecture is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for 1. The Architecture and The Four Named Agents before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: An event-driven engineering workflow where four specialized Hermes agents handle ticket intake, coding, review, and CI — while humans keep merge authority. Routine tickets go from intake to reviewed PR in about four hours for roughly $12 in AI spend. - Open the source section for 1. The Architecture before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for 1. The Architecture and The Four Named Agents. ### Risk notes | Risk | Note | | --- | --- | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Guides ## Hidden Features in Hermes You Should Know About | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hidden-hermes-features-you-should-know/ | | Source | https://hermesbible.com/flows/hidden-hermes-features-you-should-know | | Author | hermes_updates | | Category | Guides | | Level | Community | | Platforms | Hermes Agent, X | | Tags | hidden, features, should, about, community-sourced, collection, lesser-known | | Reading time | 5 min | ### Summary A community-sourced collection of lesser-known Hermes Agent commands and behaviors — cross-platform /handoff, session resume, context compression levers, local browser via CDP, the REST API, the native desktop app, /steer mid-task, and delegating to Claude Code. ### Source outline - Overview - 1. /handoff — move a live conversation between platforms - 2. hermes -c — continue your last session - 3. What context compression keeps, and what it drops - 4. /browser connect — drive your own browser - 5. Hermes has its own REST API - 6. The native cross-platform desktop app - 7. /steer — redirect mid-task without interrupting - 8. /claude-code — put Claude Code in the fleet - Keep them coming ### Section map ### Overview Frames overview for this Guides workflow, including the operating context to verify in the source page. ### 1. /handoff — move a live conversation between platforms Frames 1. /handoff — move a live conversation between platforms for this Guides workflow, including the operating context to verify in the source page. ### 2. hermes -c — continue your last session Frames 2. hermes -c — continue your last session for this Guides workflow, including the operating context to verify in the source page. ### 3. What context compression keeps, and what it drops Frames 3. what context compression keeps, and what it drops for this Guides workflow, including the operating context to verify in the source page. ### 4. /browser connect — drive your own browser Frames 4. /browser connect — drive your own browser for this Guides workflow, including the operating context to verify in the source page. ### 5. Hermes has its own REST API Frames 5. hermes has its own rest api for this Guides workflow, including the operating context to verify in the source page. ### 6. The native cross-platform desktop app Frames 6. the native cross-platform desktop app for this Guides workflow, including the operating context to verify in the source page. ### 7. /steer — redirect mid-task without interrupting Frames 7. /steer — redirect mid-task without interrupting for this Guides workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Guides flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Overview, 1. /handoff — move a live conversation between platforms, 2. hermes -c — continue your last session, 3. What context compression keeps, and what it drops, 4. /browser connect — drive your own browser. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: hidden, features, should, about, community-sourced. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides workflow pattern | Use when the summary outcome matches your own workflow and overview is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Overview and 1. /handoff — move a live conversation between platforms before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A community-sourced collection of lesser-known Hermes Agent commands and behaviors — cross-platform /handoff, session resume, context compression levers, local browser via CDP, the REST API, the native desktop app, /steer mid-task, and delegating to Claude Code. - Open the source section for Overview before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Overview and 1. /handoff — move a live conversation between platforms. ### Risk notes | Risk | Note | | --- | --- | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Hermes Agent FULL GUIDE: Architecture, Setup, and the Self-Improving Loop | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-full-guide-architecture-setup-self-improving-loop/ | | Source | https://hermesbible.com/flows/hermes-full-guide-architecture-setup-self-improving-loop | | Author | Scotty Beam | | Category | Guides | | Level | Community | | Platforms | Hermes Agent, X | | Tags | architecture, setup, self-improving, walkthrough, together, installation, model | | Reading time | 5 min | ### Summary A complete walkthrough of how Hermes is put together — installation, model routing, terminal backends, messaging, context and memory engines — and how its self-improving loop turns conversations into permanent upgrades. ### Source outline - What Hermes is, and how it differs - Installation and initial setup - Choosing and routing models - Terminal backends - Messaging gateway and tool configuration - Slash commands worth knowing - Cron jobs and webhooks - Context engines - Memory engines - The self-improving loop - The trigger system - The background review agent - The curator - Using Hermes well ### Section map ### What Hermes is, and how it differs Frames what hermes is, and how it differs for this Guides workflow, including the operating context to verify in the source page. ### Installation and initial setup Frames installation and initial setup for this Guides workflow, including the operating context to verify in the source page. ### Choosing and routing models Frames choosing and routing models for this Guides workflow, including the operating context to verify in the source page. ### Terminal backends Frames terminal backends for this Guides workflow, including the operating context to verify in the source page. ### Messaging gateway and tool configuration Frames messaging gateway and tool configuration for this Guides workflow, including the operating context to verify in the source page. ### Slash commands worth knowing Frames slash commands worth knowing for this Guides workflow, including the operating context to verify in the source page. ### Cron jobs and webhooks Frames cron jobs and webhooks for this Guides workflow, including the operating context to verify in the source page. ### Context engines Frames context engines for this Guides workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Guides flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What Hermes is, and how it differs, Installation and initial setup, Choosing and routing models, Terminal backends, Messaging gateway and tool configuration. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: architecture, setup, self-improving, walkthrough, together. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides workflow pattern | Use when the summary outcome matches your own workflow and what hermes is, and how it differs is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What Hermes is, and how it differs and Installation and initial setup before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A complete walkthrough of how Hermes is put together — installation, model routing, terminal backends, messaging, context and memory engines — and how its self-improving loop turns conversations into permanent upgrades. - Open the source section for What Hermes is, and how it differs before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What Hermes is, and how it differs and Installation and initial setup. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## Hermes Agent: The Complete Guide — From Zero to Self-Improving AI Employee | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-complete-guide-zero-to-self-improving/ | | Source | https://hermesbible.com/flows/hermes-complete-guide-zero-to-self-improving | | Author | YanXbt | | Category | Guides | | Level | Community | | Platforms | Hermes Agent | | Tags | self-improving, employee, end-to-end, running, installation, model, selection | | Reading time | 5 min | ### Summary An end-to-end guide to running Hermes Agent 24/7: installation, model selection, messaging, the dashboard most people use wrong, use cases, the self-improvement loop, and security. ### Source outline - What this guide covers - Layer 1 — What Hermes Agent actually is - Layer 2 — Hermes vs other tools - Layer 3 — Installation - Layer 4 — Model selection - Layer 5 — Messaging platform - Layer 6 — First things to do - Layer 7 — The dashboard (most people use it wrong) - Layer 8 — Use cases - Layer 9 — Self-improvement (the actual edge) - Layer 10 — Security (the honest take) - The real insight - Resources ### Section map ### What this guide covers Frames what this guide covers for this Guides workflow, including the operating context to verify in the source page. ### Layer 1 — What Hermes Agent actually is Frames layer 1 — what hermes agent actually is for this Guides workflow, including the operating context to verify in the source page. ### Layer 2 — Hermes vs other tools Frames layer 2 — hermes vs other tools for this Guides workflow, including the operating context to verify in the source page. ### Layer 3 — Installation Frames layer 3 — installation for this Guides workflow, including the operating context to verify in the source page. ### Layer 4 — Model selection Frames layer 4 — model selection for this Guides workflow, including the operating context to verify in the source page. ### Layer 5 — Messaging platform Frames layer 5 — messaging platform for this Guides workflow, including the operating context to verify in the source page. ### Layer 6 — First things to do Frames layer 6 — first things to do for this Guides workflow, including the operating context to verify in the source page. ### Layer 7 — The dashboard (most people use it wrong) Frames layer 7 — the dashboard (most people use it wrong) for this Guides workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Guides flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What this guide covers, Layer 1 — What Hermes Agent actually is, Layer 2 — Hermes vs other tools, Layer 3 — Installation, Layer 4 — Model selection. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: self-improving, employee, end-to-end, running, installation. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Guides workflow pattern | Use when the summary outcome matches your own workflow and what this guide covers is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What this guide covers and Layer 1 — What Hermes Agent actually is before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: An end-to-end guide to running Hermes Agent 24/7: installation, model selection, messaging, the dashboard most people use wrong, use cases, the self-improvement loop, and security. - Open the source section for What this guide covers before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What this guide covers and Layer 1 — What Hermes Agent actually is. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Integrations ## Hermes + Grok: Three New Superpowers That Change the Workflow | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-grok-three-new-superpowers/ | | Source | https://hermesbible.com/flows/hermes-grok-three-new-superpowers | | Author | babyape113 | | Category | Integrations | | Level | Community | | Platforms | Grok, X | | Tags | three, superpowers, change, workflow, already, premium, grok. | | Reading time | 5 min | ### Summary If you already pay for X Premium, you already have Grok. Connect it to Hermes with one OAuth login — no API key — and the agent reads X for you, runs browser tasks, and executes multi-skill playbooks from a single slash command. A tour of X Search, Browse.sh, and Skill Bundles. ### Source outline - Grok app vs. Grok in Hermes - Just using X vs. X + Hermes - The stack - The three latest superpowers - 01 · X Search - 02 · Browse.sh - 03 · Skill Bundles - Video generation, in action - Four workflows I'm actually running - The shift in month one - What you're actually building - Run it yourself ### Section map ### Grok app vs. Grok in Hermes Frames grok app vs. grok in hermes for this Integrations workflow, including the operating context to verify in the source page. ### Just using X vs. X + Hermes Frames just using x vs. x + hermes for this Integrations workflow, including the operating context to verify in the source page. ### The stack Frames the stack for this Integrations workflow, including the operating context to verify in the source page. ### The three latest superpowers Frames the three latest superpowers for this Integrations workflow, including the operating context to verify in the source page. ### 01 · X Search Frames 01 · x search for this Integrations workflow, including the operating context to verify in the source page. ### 02 · Browse.sh Frames 02 · browse.sh for this Integrations workflow, including the operating context to verify in the source page. ### 03 · Skill Bundles Frames 03 · skill bundles for this Integrations workflow, including the operating context to verify in the source page. ### Video generation, in action Frames video generation, in action for this Integrations workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Integrations flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Grok app vs. Grok in Hermes, Just using X vs. X + Hermes, The stack, The three latest superpowers, 01 · X Search. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: three, superpowers, change, workflow, already. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Integrations workflow pattern | Use when the summary outcome matches your own workflow and grok app vs. grok in hermes is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Grok app vs. Grok in Hermes and Just using X vs. X + Hermes before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: If you already pay for X Premium, you already have Grok. Connect it to Hermes with one OAuth login — no API key — and the agent reads X for you, runs browser tasks, and executes multi-skill playbooks from a single slash command. A tour of X Search, Browse.sh, and Skill Bundles. - Open the source section for Grok app vs. Grok in Hermes before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Grok app vs. Grok in Hermes and Just using X vs. X + Hermes. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Memory & Context ## Forget About Memory: Building a Context OS for Your Hermes Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/context-os-for-hermes-agent/ | | Source | https://hermesbible.com/flows/context-os-for-hermes-agent | | Author | Tony | | Category | Memory & Context | | Level | Community | | Platforms | Hermes Agent, X | | Tags | forget, about, memory, building, context, sticky, note. | | Reading time | 5 min | ### Summary Most AI memory is a sticky note. This flow breaks down an 11-layer context architecture for Hermes Agent — identity, facts, procedures, session archives, compression, and scheduled routines — and the distinctions that decide whether your agent actually remembers how you work. ### Source outline - The core idea - How to audit your own memory - The 11 layers - Layer 1 — SOUL.md: the identity file - Layer 2 — MEMORY.md and USER.md: always-on context - Layer 3 — Holographic memory (fact_store): structured facts - Layer 4 — Session database and session_search: the archive - Layer 5 — LCM: context compression - Layer 6 — Skills: procedural memory - Layer 7 — Project-local context files - Layer 8 — Nexus: the second brain - Layer 9 — Self-improving files: after-action learning - Layer 10 — Cron jobs: scheduled context loops - Layer 11 — Hooks, plugins, and MCP: expansion surfaces ### Section map ### The core idea Frames the core idea for this Memory & Context workflow, including the operating context to verify in the source page. ### How to audit your own memory Frames how to audit your own memory for this Memory & Context workflow, including the operating context to verify in the source page. ### The 11 layers Frames the 11 layers for this Memory & Context workflow, including the operating context to verify in the source page. ### Layer 1 — SOUL.md: the identity file Frames layer 1 — soul.md: the identity file for this Memory & Context workflow, including the operating context to verify in the source page. ### Layer 2 — MEMORY.md and USER.md: always-on context Frames layer 2 — memory.md and user.md: always-on context for this Memory & Context workflow, including the operating context to verify in the source page. ### Layer 3 — Holographic memory (fact_store): structured facts Frames layer 3 — holographic memory (fact_store): structured facts for this Memory & Context workflow, including the operating context to verify in the source page. ### Layer 4 — Session database and session_search: the archive Frames layer 4 — session database and session_search: the archive for this Memory & Context workflow, including the operating context to verify in the source page. ### Layer 5 — LCM: context compression Frames layer 5 — lcm: context compression for this Memory & Context workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Memory & Context flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: The core idea, How to audit your own memory, The 11 layers, Layer 1 — SOUL.md: the identity file, Layer 2 — MEMORY.md and USER.md: always-on context. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: forget, about, memory, building, context. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Memory & Context workflow pattern | Use when the summary outcome matches your own workflow and the core idea is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for The core idea and How to audit your own memory before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Most AI memory is a sticky note. This flow breaks down an 11-layer context architecture for Hermes Agent — identity, facts, procedures, session archives, compression, and scheduled routines — and the distinctions that decide whether your agent actually remembers how you work. - Open the source section for The core idea before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for The core idea and How to audit your own memory. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Multi-Agent ## Hermes + NotebookLM + Obsidian: Build a 3-Agent Research Department That Gets Smarter Every Day | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/3-agent-research-department-notebooklm-obsidian/ | | Source | https://hermesbible.com/flows/3-agent-research-department-notebooklm-obsidian | | Author | YanXbt | | Category | Multi-Agent | | Level | Community | | Platforms | Obsidian, NotebookLM | | Tags | notebooklm, obsidian, build, 3-agent, research, department, smarter | | Reading time | 5 min | ### Summary A three-profile Hermes setup where Scout finds signals, Analyst synthesizes through NotebookLM, and Briefer delivers a morning brief — coordinated through a shared Obsidian vault. Roughly $19-27/month, one evening to set up. ### Source outline - The core idea - Who this is for - Why three agents, not one - Fastest setup path: the Desktop app - Scout — finds signals - Voice - Operations - Restrictions - Analyst — synthesizes meaning - Voice - Operations - Restrictions - Briefer — delivers action items - Voice ### Section map ### The core idea Frames the core idea for this Multi-Agent workflow, including the operating context to verify in the source page. ### Who this is for Frames who this is for for this Multi-Agent workflow, including the operating context to verify in the source page. ### Why three agents, not one Frames why three agents, not one for this Multi-Agent workflow, including the operating context to verify in the source page. ### Fastest setup path: the Desktop app Frames fastest setup path: the desktop app for this Multi-Agent workflow, including the operating context to verify in the source page. ### Scout — finds signals Frames scout — finds signals for this Multi-Agent workflow, including the operating context to verify in the source page. ### Voice Frames voice for this Multi-Agent workflow, including the operating context to verify in the source page. ### Operations Frames operations for this Multi-Agent workflow, including the operating context to verify in the source page. ### Restrictions Frames restrictions for this Multi-Agent workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Multi-Agent flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: The core idea, Who this is for, Why three agents, not one, Fastest setup path: the Desktop app, Scout — finds signals. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: notebooklm, obsidian, build, 3-agent, research. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Multi-Agent workflow pattern | Use when the summary outcome matches your own workflow and the core idea is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for The core idea and Who this is for before wiring credentials or automation. | | Review boundary | 3 agent handoff | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A three-profile Hermes setup where Scout finds signals, Analyst synthesizes through NotebookLM, and Briefer delivers a morning brief — coordinated through a shared Obsidian vault. Roughly $19-27/month, one evening to set up. - Open the source section for The core idea before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for The core idea and Who this is for. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Orchestration ## How to Become a Hermes Agent Operator | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/how-to-become-a-hermes-agent-operator/ | | Source | https://hermesbible.com/flows/how-to-become-a-hermes-agent-operator | | Author | Mike | | Category | Orchestration | | Level | Community | | Platforms | Hermes Agent, SOUL.md, VPS | | Tags | become, operator, single, install, control, orchestrating, specialist | | Reading time | 5 min | ### Summary Go from a single Hermes install to a control room orchestrating a team of specialist agents on one cheap VPS. Covers install, memory and SOUL.md, the orchestrator pattern, messaging surfaces, cron, and the operator mindset that makes it all compound. ### Source outline - What This Flow Covers - Install Hermes in Two Minutes - Understand What You Just Installed - Set Up Your Agent Control Room - Connect Your Messaging Surface - Configure Scheduled Recurring Work - Grow From One Agent to a Marketing Operation - What Breaks and How to Catch It - The Operator Mindset ### Section map ### What This Flow Covers Frames what this flow covers for this Orchestration workflow, including the operating context to verify in the source page. ### Install Hermes in Two Minutes Frames install hermes in two minutes for this Orchestration workflow, including the operating context to verify in the source page. ### Understand What You Just Installed Frames understand what you just installed for this Orchestration workflow, including the operating context to verify in the source page. ### Set Up Your Agent Control Room Frames set up your agent control room for this Orchestration workflow, including the operating context to verify in the source page. ### Connect Your Messaging Surface Frames connect your messaging surface for this Orchestration workflow, including the operating context to verify in the source page. ### Configure Scheduled Recurring Work Frames configure scheduled recurring work for this Orchestration workflow, including the operating context to verify in the source page. ### Grow From One Agent to a Marketing Operation Frames grow from one agent to a marketing operation for this Orchestration workflow, including the operating context to verify in the source page. ### What Breaks and How to Catch It Frames what breaks and how to catch it for this Orchestration workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Orchestration flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: What This Flow Covers, Install Hermes in Two Minutes, Understand What You Just Installed, Set Up Your Agent Control Room, Connect Your Messaging Surface. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: become, operator, single, install, control. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Orchestration workflow pattern | Use when the summary outcome matches your own workflow and what this flow covers is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for What This Flow Covers and Install Hermes in Two Minutes before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Go from a single Hermes install to a control room orchestrating a team of specialist agents on one cheap VPS. Covers install, memory and SOUL.md, the orchestrator pattern, messaging surfaces, cron, and the operator mindset that makes it all compound. - Open the source section for What This Flow Covers before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for What This Flow Covers and Install Hermes in Two Minutes. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- ## How to Dominate Projects with the Hermes Agent Kanban Board | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/dominate-projects-with-hermes-kanban/ | | Source | https://hermesbible.com/flows/dominate-projects-with-hermes-kanban | | Author | Tony | | Category | Orchestration | | Level | Community | | Platforms | Hermes Agent | | Tags | dominate, projects, kanban, board, wrong, grows, teeth. | | Reading time | 5 min | ### Summary One agent is the wrong unit once work grows teeth. This field manual shows how to use Hermes Kanban — boards, tasks, claims, blocks, schedules, and receipts — to give long-running multi-agent work durable coordination that survives a dead shell. ### Source outline - One agent is the wrong unit - The context window isn't a manager - Build the board like you mean it - Small contracts beat giant prompts - Claim, block, schedule, then stop improvising - Receipts beat vibes - The three dumb failures that keep eating afternoons - When NOT to use a board - The operator still owns judgment - Wrapping up ### Section map ### One agent is the wrong unit Frames one agent is the wrong unit for this Orchestration workflow, including the operating context to verify in the source page. ### The context window isn't a manager Frames the context window isn't a manager for this Orchestration workflow, including the operating context to verify in the source page. ### Build the board like you mean it Frames build the board like you mean it for this Orchestration workflow, including the operating context to verify in the source page. ### Small contracts beat giant prompts Frames small contracts beat giant prompts for this Orchestration workflow, including the operating context to verify in the source page. ### Claim, block, schedule, then stop improvising Frames claim, block, schedule, then stop improvising for this Orchestration workflow, including the operating context to verify in the source page. ### Receipts beat vibes Frames receipts beat vibes for this Orchestration workflow, including the operating context to verify in the source page. ### The three dumb failures that keep eating afternoons Frames the three dumb failures that keep eating afternoons for this Orchestration workflow, including the operating context to verify in the source page. ### When NOT to use a board Frames when not to use a board for this Orchestration workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Orchestration flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: One agent is the wrong unit, The context window isn't a manager, Build the board like you mean it, Small contracts beat giant prompts, Claim, block, schedule, then stop improvising. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: dominate, projects, kanban, board, wrong. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Orchestration workflow pattern | Use when the summary outcome matches your own workflow and one agent is the wrong unit is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for One agent is the wrong unit and The context window isn't a manager before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: One agent is the wrong unit once work grows teeth. This field manual shows how to use Hermes Kanban — boards, tasks, claims, blocks, schedules, and receipts — to give long-running multi-agent work durable coordination that survives a dead shell. - Open the source section for One agent is the wrong unit before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for One agent is the wrong unit and The context window isn't a manager. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Security ## Hermes x Bitwarden: The Security Stack AI Agents Actually Need | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-bitwarden-security-stack/ | | Source | https://hermesbible.com/flows/hermes-bitwarden-security-stack | | Author | YanXbt | | Category | Security | | Level | Community | | Platforms | Hermes Agent, Bitwarden, X | | Tags | bitwarden, security, stack, agents, actually, ships, credential | | Reading time | 5 min | ### Summary How Hermes Agent ships credential management (Bitwarden Secrets Manager) and credential protection (iron-proxy egress firewall) as composable, first-class infrastructure — not README advice. ### Source outline - The problem nobody is solving properly - Layer 1: Bitwarden Secrets Manager — credential management - What this actually gives you - Setup - Layer 2: iron-proxy — credential protection - What this closes concretely - New CLI surface - Honest scope (from the PR itself) - How the two layers compose - Where the rest of the ecosystem stands - Why this matters beyond Hermes - The trajectory - The bottom line ### Section map ### The problem nobody is solving properly Frames the problem nobody is solving properly for this Security workflow, including the operating context to verify in the source page. ### Layer 1: Bitwarden Secrets Manager — credential management Frames layer 1: bitwarden secrets manager — credential management for this Security workflow, including the operating context to verify in the source page. ### What this actually gives you Frames what this actually gives you for this Security workflow, including the operating context to verify in the source page. ### Setup Frames setup for this Security workflow, including the operating context to verify in the source page. ### Layer 2: iron-proxy — credential protection Frames layer 2: iron-proxy — credential protection for this Security workflow, including the operating context to verify in the source page. ### What this closes concretely Frames what this closes concretely for this Security workflow, including the operating context to verify in the source page. ### New CLI surface Frames new cli surface for this Security workflow, including the operating context to verify in the source page. ### Honest scope (from the PR itself) Frames honest scope (from the pr itself) for this Security workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Security flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: The problem nobody is solving properly, Layer 1: Bitwarden Secrets Manager — credential management, What this actually gives you, Setup, Layer 2: iron-proxy — credential protection. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: bitwarden, security, stack, agents, actually. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Security workflow pattern | Use when the summary outcome matches your own workflow and the problem nobody is solving properly is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for The problem nobody is solving properly and Layer 1: Bitwarden Secrets Manager — credential management before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: How Hermes Agent ships credential management (Bitwarden Secrets Manager) and credential protection (iron-proxy egress firewall) as composable, first-class infrastructure — not README advice. - Open the source section for The problem nobody is solving properly before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for The problem nobody is solving properly and Layer 1: Bitwarden Secrets Manager — credential management. ### Risk notes | Risk | Note | | --- | --- | | Credentials | Treat every token, OAuth grant, secret manager entry, and API key as production-sensitive. Verify least privilege and revocation before reuse. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Self-Improvement ## Introducing Hermes Dreaming: Reviewable Self-Improvement for Hermes Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-dreaming-reviewable-self-improvement/ | | Source | https://hermesbible.com/flows/hermes-dreaming-reviewable-self-improvement | | Author | Tony | | Category | Self-Improvement | | Level | Community | | Platforms | Hermes Agent | | Tags | introducing, dreaming, reviewable, self-improvement, staged, artifact-first, engine | | Reading time | 5 min | ### Summary Hermes Dreaming is a staged, artifact-first self-improvement engine for Hermes Agent. It proposes changes as reviewable artifacts you can diff, validate, apply, or discard — turning self-improvement into a receipt trail instead of silent mutation. ### Source outline - Why Build Hermes Dreaming - Staged Change Beats Silent Mutation - The Command Surface Is Boring On Purpose - The Artifact Is The Product - Offline-First Is Not A Downgrade - It Also Ships As A Hermes Plugin - What This Is Not - Why Operators Should Care - The Point - Resources ### Section map ### Why Build Hermes Dreaming Frames why build hermes dreaming for this Self-Improvement workflow, including the operating context to verify in the source page. ### Staged Change Beats Silent Mutation Frames staged change beats silent mutation for this Self-Improvement workflow, including the operating context to verify in the source page. ### The Command Surface Is Boring On Purpose Frames the command surface is boring on purpose for this Self-Improvement workflow, including the operating context to verify in the source page. ### The Artifact Is The Product Frames the artifact is the product for this Self-Improvement workflow, including the operating context to verify in the source page. ### Offline-First Is Not A Downgrade Frames offline-first is not a downgrade for this Self-Improvement workflow, including the operating context to verify in the source page. ### It Also Ships As A Hermes Plugin Frames it also ships as a hermes plugin for this Self-Improvement workflow, including the operating context to verify in the source page. ### What This Is Not Frames what this is not for this Self-Improvement workflow, including the operating context to verify in the source page. ### Why Operators Should Care Frames why operators should care for this Self-Improvement workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Self-Improvement flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Why Build Hermes Dreaming, Staged Change Beats Silent Mutation, The Command Surface Is Boring On Purpose, The Artifact Is The Product, Offline-First Is Not A Downgrade. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: introducing, dreaming, reviewable, self-improvement, staged. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Self-Improvement workflow pattern | Use when the summary outcome matches your own workflow and why build hermes dreaming is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Why Build Hermes Dreaming and Staged Change Beats Silent Mutation before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: Hermes Dreaming is a staged, artifact-first self-improvement engine for Hermes Agent. It proposes changes as reviewable artifacts you can diff, validate, apply, or discard — turning self-improvement into a receipt trail instead of silent mutation. - Open the source section for Why Build Hermes Dreaming before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Why Build Hermes Dreaming and Staged Change Beats Silent Mutation. ### Risk notes | Risk | Note | | --- | --- | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | --- # Trading ## Hermes + Polymarket: A Self-Learning Up/Down Trading Agent | Field | Value | | --- | --- | | Local route | https://agentguide.net/hermes/flows/hermes-polymarket-self-learning-trading-agent/ | | Source | https://hermesbible.com/flows/hermes-polymarket-self-learning-trading-agent | | Author | YanXbt | | Category | Trading | | Level | Community | | Platforms | Hermes Agent, Telegram, X, VPS, Polymarket | | Tags | polymarket, self-learning, up/down, trading, step-by-step, building, trades | | Reading time | 5 min | ### Summary A step-by-step guide to building a self-learning Hermes agent that trades Polymarket 5-minute up/down crypto markets — VPS setup, Telegram control, CLOB v2 execution, and a self-improving loop that adjusts probability estimates from live results. ### Source outline - Why this flow exists - Why short-interval crypto up/down — not BTC - How bots classify the opportunities - What Hermes Agent contributes - Installing Hermes Agent - Step 1 — Prepare a VPS - Step 2 — Connect to the VPS - Step 3 — Install Hermes - Step 4 — Choose a model - Step 5 — Set up the Telegram gateway - Step 6 — Start Hermes - Building the trading logic - Prompt 1 — Build the core logic - Prompt 2 — Create a wallet ### Section map ### Why this flow exists Frames why this flow exists for this Trading workflow, including the operating context to verify in the source page. ### Why short-interval crypto up/down — not BTC Frames why short-interval crypto up/down — not btc for this Trading workflow, including the operating context to verify in the source page. ### How bots classify the opportunities Frames how bots classify the opportunities for this Trading workflow, including the operating context to verify in the source page. ### What Hermes Agent contributes Frames what hermes agent contributes for this Trading workflow, including the operating context to verify in the source page. ### Installing Hermes Agent Frames installing hermes agent for this Trading workflow, including the operating context to verify in the source page. ### Step 1 — Prepare a VPS Frames step 1 — prepare a vps for this Trading workflow, including the operating context to verify in the source page. ### Step 2 — Connect to the VPS Frames step 2 — connect to the vps for this Trading workflow, including the operating context to verify in the source page. ### Step 3 — Install Hermes Frames step 3 — install hermes for this Trading workflow, including the operating context to verify in the source page. ### Implementation notes - Use this Trading flow as a pattern library entry: start from the summary, then inspect the linked source before copying any commands, schedules, or account wiring. - Primary decision areas: Why this flow exists, Why short-interval crypto up/down — not BTC, How bots classify the opportunities, What Hermes Agent contributes, Installing Hermes Agent. Treat those sections as checkpoints for scope, cost, orchestration, and human review. - Useful search signals for this flow: polymarket, self-learning, up/down, trading, step-by-step. These are derived from the public title and summary, not from private runtime data. ### Decision table | Decision | Signal | Action | | --- | --- | --- | | Best fit | Trading workflow pattern | Use when the summary outcome matches your own workflow and why this flow exists is relevant to your setup. | | Verify first | Accounts, models, schedules, and tool access | Open the source sections for Why this flow exists and Why short-interval crypto up/down — not BTC before wiring credentials or automation. | | Review boundary | Human approval point | Keep human approval for merges, spending, external messages, credentials, and unattended execution. | ### Verification checklist - Confirm the workflow outcome matches your use case: A step-by-step guide to building a self-learning Hermes agent that trades Polymarket 5-minute up/down crypto markets — VPS setup, Telegram control, CLOB v2 execution, and a self-improving loop that adjusts probability estimates from live results. - Open the source section for Why this flow exists before copying commands, prompts, or schedules. - List every credential, account, model, and external service the flow would touch. - Define the human approval step before spending money, sending messages, trading, merging, or running unattended. - Run a small dry run and compare the result with the source sections for Why this flow exists and Why short-interval crypto up/down — not BTC. ### Risk notes | Risk | Note | | --- | --- | | Automation | Start with a bounded dry run, logs, and a manual stop path before enabling recurring or unattended execution. | | External messages | Keep human review before sending public posts, customer messages, trading instructions, or team notifications. | | Model spend | Set provider, token, and retry limits before scaling the workflow beyond a single test run. | | Runtime access | Check filesystem, shell, browser, repository, and server permissions before granting the agent write access. | ---