Hermes Agent 101: A Practical Guide to Persistent and Self-Improving Agents
How Nous Research’s Hermes Agent turns the idea of an AI assistant into a long-running agent that remembers, learns skills, and works…
Hermes Agent 101: A Practical Guide to Persistent and Self-Improving Agents
How Nous Research’s Hermes Agent turns the idea of an AI assistant into a long-running agent that remembers, learns skills, and works across tools
Most AI agents are still designed around short-lived sessions. They can reason, call tools, write code, search files, or summarize information, but they often lose the operational context that made the previous interaction useful.
For developers and AI practitioners, this becomes a practical limitation. Real workflows depend on project conventions, repeated commands, debugging patterns, source preferences, review habits, and long-running context.
Hermes Agent, developed by Nous Research, approaches this problem as a persistent agent system. Instead of treating each interaction as an isolated prompt, Hermes gives the agent an identity, memory, reusable skills, profiles, tools, messaging interfaces, and scheduled jobs.
This makes it possible to build agents that can gradually adapt to repeated workflows while keeping their state inspectable through files such as SOUL.md, memory files, skills, sessions, config, and cron jobs.
This guide explains Hermes from both a conceptual and practical perspective. We start with the core mental model behind persistent agents, then look at identity, memory, skills, the Curator, GEPA-based offline self-evolution, profiles, messaging, and scheduled work.
After that, we move into practical workflows: setting up Hermes, creating a developer assistant, using Hermes for coding and research, connecting it to Telegram, and scheduling recurring outputs with cron.
The goal is not to present Hermes as a fully autonomous replacement for human review. It is better understood as an open-source framework for building persistent, inspectable, and workflow-aware agents. Used carefully, Hermes can reduce repeated context setup, standardize recurring procedures, and make agent behavior easier to improve over time.
Table of Contents:
- Introduction to Self-Improving Agents
- What Is Hermes Agent?
- Why Persistent Agents Matter for Developers
- The Core Mental Model: Identity, Memory, Skills, and Tools
- How a Hermes Task Runs: From User Request to Persistent State
- The Identity Layer: What SOUL.md Does
- Hermes Memory: From Short Notes to Searchable History
- Self-Evolving Skills: Turning Repeated Workflows Into Reusable Procedures
- The Curator: Keeping the Skill Library Clean
- GEPA and Offline Self-Evolution
- Practical Setup: Installing Hermes Agent
- Understanding the ~/.hermes/ Folder
- Creating Your First Useful Agent
- Working With Multiple Profiles
- Connecting Hermes to Telegram or Messaging Apps
- Practical Workflow 1: Hermes as a Coding Assistant
- Practical Workflow 2: Hermes as a Research Agent
- Scheduling Work With Hermes Cron
- Best Practices, Limits, and When Hermes Makes Sense
I turned this guide into a full course: Hermes Agent 101: Persistent Agents, Memory, Skills, and Real Workflows.
It includes a 3-hour video course and a 150-page companion guide covering setup, memory, skills, profiles, Telegram integration, coding workflows, research workflows, and Hermes cron.
1. Introduction to Self-Improving Agents
Most AI agents are still designed around short-lived interactions. A user opens a session, provides the task, explains the relevant context, corrects the agent when it misunderstands something, and eventually receives a useful output. This pattern works reasonably well for one-off tasks. It is less effective when the work depends on a context that should persist across time.
Developers and AI practitioners often work in environments where context is not temporary. A software project has its own structure, dependencies, conventions, test commands, deployment steps, and common failure modes. A research workflow may include preferred sources, recurring topics, citation requirements, and formatting expectations. A content workflow may involve a specific writing style, visual style, publishing format, and review process.
In many current AI assistants, this context has to be rebuilt repeatedly. The assistant may help solve a problem in a single session, but the operational knowledge gained during that process is usually not consolidated into durable memory or reusable procedures. As a result, the user often has to re-explain the same repository structure, tool preferences, project rules, and output expectations in future sessions.
This limits how useful an agent can become in long-running workflows.
An effective agent system needs more than tool use and multi-step reasoning. It also needs a mechanism for carrying useful information forward. This includes remembering stable facts about the user and environment, storing previous interactions in a searchable form, and turning repeated workflows into reusable skills.
**Hermes Agent, developed by [Nous Research](https://nousresearch.com/), is designed around this problem. It is an open-source agent framework focused on persistence, memory, skills, and self-improvement**. Instead of treating each interaction as an isolated conversation, Hermes is structured so that the agent can retain useful context, build procedural knowledge, and operate across different interfaces such as the terminal and messaging platforms.
Figure 1. Two patterns for AI agent workflows.
The practical value of Hermes is not only that it can answer prompts or call tools. Its primary design goal is for the agent to gradually adapt to repeated workflows. For example, it can remember how a project is structured, preserve user-specific preferences, create skills for recurring procedures, and run scheduled tasks through its automation system.
This makes Hermes relevant for several developer and practitioner workflows, including coding assistance, research monitoring, documentation generation, personal automation, and content production pipelines. These workflows often require continuity. They benefit from an agent that can preserve useful context rather than starting from a blank slate every time.
This hands-on guide introduces Hermes Agent from both a conceptual and practical perspective. We will first look at the main ideas behind the framework: identity, memory, skills, profiles, tools, and self-improvement. After that, we will move into the hands-on side: installing Hermes, understanding the ~/.hermes/ directory, creating a useful agent profile, connecting it to Telegram, and using it for coding and research workflows.
Hermes should not be treated as a fully autonomous replacement for human review. Like any agent framework, it still depends on clear instructions, careful configuration, and controlled access to tools and files.
However, it is a useful example of where agent systems are moving: from isolated prompt-response sessions toward persistent systems that can retain context, reuse procedures, and improve their behavior through repeated use.
2. What Is Hermes Agent?
**Hermes Agent is an open-source agent framework developed by [Nous Research](https://nousresearch.com/)** for building persistent, tool-using AI agents. Its main focus is not only task execution, but also continuity across sessions. This means the agent can retain useful information, search previous conversations, create reusable skills, and operate through different interfaces such as the terminal or messaging platforms.
At a high level, Hermes can be understood as a long-running agent environment. The user interacts with the agent, the agent uses tools to complete tasks, and the system stores useful context that can be reused later. This is different from a standard chatbot interface, where most of the interaction is limited to the current conversation window.
The design of Hermes is centered around a few core capabilities.
Figure 2. Hermes Agent in One Diagram.
- First, Hermes supports persistent memory. The agent can store information about the user, the working environment, project conventions, and previous interactions. This allows it to preserve context that would normally be lost between sessions.
- Second, Hermes supports self-evolving skills. A skill is a reusable procedure that describes how the agent should perform a specific type of task. For example, a skill might describe how to debug a failing Docker container, how to run tests in a specific repository, how to summarize research papers, or how to generate content in a particular format. Instead of solving the same workflow from scratch every time, the agent can reuse and refine these skills.
- Third, Hermes supports tool use and execution. It can interact with the local environment, run commands, work with files, and connect to external systems depending on how it is configured. This makes it useful for practical workflows such as coding assistance, research automation, documentation generation, and scheduled reporting.
- Fourth, Hermes supports profiles. A profile is an isolated agent configuration with its own identity, memory, skills, sessions, and tools. This makes it possible to create specialized agents for different roles. For example, one profile can act as a programming assistant, another can act as a research assistant, and another can be configured for content or design workflows. Separating these roles helps keep memory and behavior cleaner than forcing every task into one general-purpose assistant.
Another useful way to describe Hermes is that it combines declarative configuration with adaptive behavior. Some parts of the agent are explicitly configured by the user, such as its identity, model provider, tools, and profile settings. Other parts evolve through use, such as memory entries and agent-created skills. This combination gives the user control over the agent’s initial behavior while still allowing the system to improve through repeated interaction.
This distinction is important. Hermes is not only a model wrapper. A model wrapper mainly forwards user prompts to an LLM and returns the answer. Hermes adds an execution layer around the model: it manages memory, loads skills, runs tools, stores sessions, supports recurring jobs, and allows multiple isolated profiles. The language model remains the reasoning component, but Hermes provides the surrounding system that makes the agent persistent and operational.
For developers, this changes the practical use case. Instead of using the agent only to answer isolated questions, Hermes can be configured as a working assistant around a repeated workflow. A programming profile can learn repository-specific commands and debugging procedures. A research profile can maintain a recurring process for collecting and summarizing new papers or tools. A content profile can preserve style preferences, formatting rules, and publishing steps.
This does not mean Hermes removes the need for human review. The agent can still make incorrect assumptions, create weak skills, store noisy memories, or take the wrong action if the task is underspecified. However, its architecture gives developers a useful foundation for building agents that are more persistent and workflow-aware than ordinary chat sessions.
In the next section, we will look more closely at why this kind of persistence matters for developers and AI practitioners, especially when the work involves repeated tasks, project-specific conventions, and long-running context.
3. Why Persistent Agents Matter for Developers
Developers rarely work on isolated tasks. Most real software work happens inside an existing environment with accumulated context: a repository structure, a dependency stack, naming conventions, test commands, deployment rules, team preferences, and recurring failure patterns. The usefulness of an AI agent depends heavily on how well it can operate inside that environment.
A session-based assistant can still be helpful. It can explain code, generate functions, suggest fixes, write tests, or summarize files. However, every new session usually requires the developer to rebuild the relevant context. The user may need to explain which framework the project uses, how the codebase is organized, which commands are safe to run, what style the team follows, and which previous attempts already failed.
This repetition becomes more visible as the workflow becomes more complex. For example, consider a developer using an agent to debug a backend service.
The agent may eventually learn that the project uses a specific test command, that environment variables are loaded from a certain file, that Docker needs to be restarted after changing a configuration file, and that a known flaky test can be ignored during local debugging. In a normal chat-based workflow, these details may help during the current session but may not be available when the next debugging task starts.
A persistent agent changes the engineering model around the assistant. Instead of treating every session as a clean slate, the system can preserve useful operational knowledge and reuse it later. This matters because many developer tasks are not only reasoning problems. They are also context-management problems.
For developers, persistence is useful in at least four areas.
Figure 3. Developer loop with persistent context.
- First, it reduces repeated setup context. The agent can remember stable facts such as the package manager, project structure, preferred commands, local environment constraints, and naming conventions. This does not remove the need for verification, but it reduces the amount of repeated explanation required from the user.
- Second, it helps preserve debugging knowledge. When an agent discovers that a certain error is caused by a missing environment variable, a stale container, an incompatible dependency version, or a specific command sequence, that information can be saved and reused. Over time, this can create a practical memory of how problems usually appear and how they are usually resolved in a specific project.
- Third, it allows repeated workflows to become procedural knowledge. Many tasks follow a pattern: reviewing a pull request, generating documentation, running a release checklist, triaging logs, writing tests for a module, or summarizing changes after a refactor. A persistent agent can turn these workflows into reusable skills instead of rediscovering the process every time.
- Fourth, persistence makes role-specific agents more practical. A coding agent, a research agent, and a documentation agent should not necessarily share the same memory, tone, tools, or operating assumptions. Separating them into profiles allows each agent to accumulate context around a specific type of work. This improves organization and reduces instruction conflicts.
This is especially relevant for long-running projects. A developer may work on the same application for months. During that time, the project accumulates decisions and constraints that are not always captured in documentation.
Some of them live in commit history, some in deployment scripts, some in recurring conversations, and some only in the developer’s memory. A persistent agent provides a place where part of this operational knowledge can be made explicit and reusable.
The same idea applies beyond coding. AI practitioners often repeat research and content workflows: tracking new papers, comparing tools, preparing technical summaries, creating diagrams, converting experiments into blog posts, or maintaining newsletters. These workflows also benefit from accumulated context. The agent can learn preferred sources, formatting rules, evaluation criteria, and recurring output structures.
Persistence should still be treated carefully. Not every piece of information deserves to be stored. Temporary details, secrets, uncertain assumptions, and one-off observations can make memory noisy or unsafe. A useful persistent agent needs disciplined memory management, clear boundaries, and periodic review of generated skills and stored context.
For this reason, Hermes Agent is best understood as a system for making repeated workflows more explicit. It gives the agent a way to retain stable information, search previous sessions, create reusable procedures, and specialize behavior through profiles. The practical benefit is not that the agent becomes automatically correct, but that it can reduce repeated context setup and gradually adapt to the way a developer or team works.
4. The Core Mental Model: Identity, Memory, Skills, and Tools
Before going into the internal architecture of Hermes, it is useful to define a simple mental model for how the system is organized. Hermes can be understood through four main layers: identity (Soul.md), memory, skills, and tools.
These layers are not separate products or independent agents. They are parts of the same agent runtime. Together, they define how the agent behaves, what it remembers, how it performs recurring tasks, and where it can take action.
Figure 4. Four-Layer mental model of Hermes agent.
The first layer is identity. This defines who the agent is supposed to be when it interacts with the user. In Hermes, this is mainly controlled through SOUL.md, a file that describes the agent’s role, tone, operating principles, and behavioral constraints.
For example, one agent can be configured as a direct staff engineer, another as a careful research assistant, and another as a visual design assistant. The underlying model may be the same, but the identity layer changes how the agent frames tasks and communicates results.
The second layer is memory. This defines what the agent can carry across sessions. Memory can include stable user preferences, project conventions, tool usage patterns, environment details, and lessons learned from previous tasks.
Hermes does not treat memory as a single large text file. It combines compact, always-available memory with searchable session history and optional external memory providers. This allows the agent to keep critical facts close to the prompt while still being able to retrieve older interactions when needed.
The third layer is skills. Skills are reusable procedures that describe how the agent should perform a specific type of task. They are closer to procedural memory than factual memory.
A memory entry may say that a project uses pytest, but a skill can describe the full workflow for debugging a failing test suite in that project: which commands to run, which logs to inspect, what common failure modes to check, and how to verify the fix. This distinction is important because many useful agent behaviors are not just facts; they are repeatable processes.
The fourth layer is tools and execution. This is where the agent acts. Hermes can be configured to work with the terminal, files, external services, messaging interfaces, and other tools, depending on the setup.
The model provides reasoning and planning, but the tool layer allows the agent to interact with the environment and produce concrete changes. Without tools, the agent can only suggest actions. With tools, it can inspect files, run commands, call services, and participate in real workflows.
This layered view helps explain why Hermes is different from a basic prompt interface. A prompt interface mainly sends user input to a model and returns output.
Hermes adds the surrounding state and operational structure. It gives the agent an identity, stores context, loads reusable procedures, and connects the model to tools that can act on the environment.
The interaction between these layers is where the system becomes useful.
For example, assume a developer asks Hermes to debug a failing API endpoint. The identity layer may tell the agent to behave like a pragmatic backend engineer. The memory layer may provide project-specific facts, such as the framework being used, the test command, and known deployment constraints.
The skills layer may provide a reusable debugging procedure for this type of service. The tools layer allows the agent to inspect files, run tests, and check logs. The final behavior comes from the combination of all four layers, not from the model alone.
This also explains why different Hermes profiles can behave differently even if they use the same model provider. A programmer profile, a researcher profile, and a content profile can have different SOUL.md files, memories, skills, and enabled tools. Each profile accumulates context for its own role rather than mixing all workflows into a single shared agent state.
For developers, this is a useful design pattern. Instead of thinking only about “which model should I use?”, it becomes important to think about the full agent environment around the model:
- What identity should guide the agent’s behavior?
- What information should persist across sessions?
- Which workflows should become reusable skills?
- Which tools should the agent be allowed to access?
- Which tasks should be isolated into separate profiles?
These questions are practical engineering decisions. They affect reliability, safety, and usefulness more than the model choice alone in many workflows. A strong model with poor memory, vague identity, and uncontrolled tools can still behave inconsistently. A well-configured persistent agent gives the model more structure and makes repeated workflows easier to manage.
This mental model will be useful for the rest of the guide. In the next sections, we will go deeper into each part of the system, starting with how Hermes is structured at a high level and then moving into identity, memory, skills, and self-improvement in more detail.
5. How a Hermes Task Runs: From User Request to Persistent State
When a user sends a request to Hermes, the agent not only forwards that message to a language model. It first prepares the working context for the model. This context may include the agent’s identity, relevant memory entries, available tools, skill descriptions, current session state, and configuration settings. The model then uses this context to decide how to respond or which tool action should be taken next.
The task usually follows a loop. Hermes receives the user request, builds the context, calls the model, executes any requested tool calls, returns the observations to the model, and continues until the task is completed or the run reaches a stopping condition.
Figure 5. Hermes Agent Runtime Loop.
This loop is important because most useful agent work is not completed in one model response. A coding task may require reading files, checking project structure, running tests, inspecting errors, editing code, and verifying the result.
A research task may require searching sources, comparing claims, filtering weak evidence, and preparing a structured summary. In both cases, the model needs to reason, act, observe the result, and adjust its next step.
The practical value of Hermes comes from what happens before, during, and after this loop.
Before the model call, Hermes controls what context is loaded. This helps the agent start with relevant information instead of relying only on the current user message.
For example, a programming profile may load its engineering identity, project-specific memory, and a relevant debugging skill before attempting a code task.
During the loop, Hermes manages tool execution. The model may request an action, but the runtime is responsible for carrying it out through the configured tools and execution environment.
This separation matters because the model is not directly operating the system by itself. It is producing tool requests, while Hermes manages how those requests are executed and how the results are returned.
After the task, Hermes can preserve useful information. If the agent discovers a stable project detail, a recurring command, or a better procedure, that information can be saved in memory or turned into a reusable skill. This is where the task result becomes more than a single answer. Part of the experience can become available to future sessions.
A simple debugging workflow shows the pattern clearly. The user asks Hermes to investigate a failing test. Hermes loads the developer profile, checks relevant memory, inspects the repository, runs the test command, observes the error, applies a fix, and verifies the result. If the test command or failure pattern is useful for future work, Hermes can store it in memory or update an existing debugging skill.
Figure 6. Example Hermes Debugging Task Flow.
This is the main operational difference between a simple chat interface and a persistent agent runtime. The task not only produces an output for the current session. It can also update the agent’s working context for future tasks.
This does not mean every task should create new memory or skills. In practice, the useful information should be stable, reusable, and specific enough to help later. Temporary details, uncertain assumptions, and one-off outputs should not be stored automatically. A persistent agent becomes more useful when its state remains clean and relevant.
From this perspective, Hermes is best understood as a system that wraps a language model inside a controlled task loop. The model reasons about the next step, while Hermes manages context, tools, observations, session state, and persistent updates. This runtime structure is what allows Hermes to support longer-running workflows instead of treating every interaction as an isolated prompt.
6. The Identity Layer: What SOUL.md Does
Before discussing memory and skills in detail, it is important to start with the identity layer. In Hermes, this layer is mainly defined through a file called SOUL.md.
The purpose of SOUL.md is to describe how the agent should behave. It defines the agent’s role, tone, priorities, communication style, and operating constraints. This file is loaded before the agent starts working, so it acts as a stable behavioral frame for the rest of the system.
This is different from memory.
Memory is about what the agent knows. Skills are about how the agent performs repeatable tasks. SOUL.md is about how the agent should approach work in the first place.
For example, a Hermes profile configured as a programming assistant may have a SOUL.md file that tells it to behave like a pragmatic staff engineer. It may instruct the agent to read existing code before making changes, prefer small patches over large rewrites, run tests before reporting completion, and explain trade-offs briefly.
A research profile would need a different identity. It may be instructed to prioritize source quality, cite claims, separate confirmed facts from speculation, and avoid presenting weak evidence as settled. A design profile may focus on visual clarity, technical explanation, consistent style, and deciding when an image is useful or unnecessary.
This identity layer is useful because the same model can behave very differently depending on the surrounding instructions. Without a stable identity file, the agent may rely too heavily on the current user message and behave inconsistently across sessions. With SOUL.md, the agent has a persistent role definition that remains available across tasks.
Figure 7. SOUL.md as the Identity Layer.
A simple SOUL.md for a programming profile might look like this:
# SOUL.md
You are a pragmatic staff engineer.
You read existing code before writing new code.
You prefer small, safe changes over large rewrites.
You run relevant tests before saying a task is complete.
You explain trade-offs clearly and avoid unnecessary abstraction.
When debugging, first reproduce the issue, then inspect the smallest
relevant part of the codebase, then propose and verify a fix.This is not meant to be a long prompt full of motivational language. A useful SOUL.md should be specific, operational, and easy to follow. The agent should be able to translate it into concrete behavior during real tasks.
There are a few practical rules that help when writing this file.
- First, define the role clearly. “You are a helpful assistant” is too generic. “You are a backend engineering assistant for Python services” gives the model a more useful starting point.
- Second, define priorities. For example, a coding agent may prioritize correctness, minimal changes, and tests. A research agent may prioritize source quality, freshness, and citation accuracy. A content agent may prioritize clarity, structure, and consistency with an existing writing style.
- Third, define constraints. Constraints are often more useful than style preferences. Examples include: do not make large code changes without explaining the reason, do not fabricate citations, do not store secrets in memory, do not mark work as complete before verification, and ask for clarification when the task depends on missing external context.
- Fourth, keep the file maintainable. Since SOUL.md acts as a persistent identity file, it should not become a dumping ground for every project detail. Project-specific facts belong in memory. Repeatable procedures belong in skills. The identity file should only contain the stable behavioral rules that should apply across many tasks.
Figure 8. Example SOUL.md Screenshot.
This becomes more important when using multiple Hermes profiles. Each profile can have its own SOUL.md, which means each agent can have a different role and behavior pattern. A programmer, researcher, and designer can all use the same underlying model provider, but behave differently because their identity files, memories, skills, and tools are different.
For example:
- programmer/SOUL.md → focuses on code inspection, tests, and small patches
- researcher/SOUL.md → focuses on source quality, citations, and synthesis
- designer/SOUL.md → focuses on visual clarity, diagrams, and style consistency
This separation is one of the practical benefits of Hermes profiles. Instead of forcing one general agent to handle every type of work, each profile can be configured around a specific operating mode. The identity layer gives that profile a stable starting point before memory, skills, and tools are applied.
It is also worth noting that SOUL.md should be reviewed over time. If the agent repeatedly behaves in a way that does not match your expectations, the issue may not only be the model. The identity file may be too vague, too broad, or missing an important constraint. Updating SOUL.md is often a more direct fix than repeatedly correcting the agent in individual sessions.
In this sense, SOUL.md is one of the simplest but most important configuration files in Hermes. It does not store knowledge, and it does not execute tasks by itself. Its role is to define the behavioral frame that shapes how the agent uses everything else: memory, skills, tools, and profiles.
7. Hermes Memory: From Short Notes to Searchable History
Memory is one of the main reasons Hermes should be understood as a persistent agent rather than a normal chat interface. Without memory, the agent can still answer questions and use tools, but each session remains mostly independent. With memory, useful context from previous work can become part of future interactions.
In Hermes, memory is not only a place to store random notes. It is part of the agent’s operating context. The goal is to preserve information that is stable, reusable, and helpful for future tasks. This can include user preferences, project conventions, environment details, repeated failure patterns, command snippets, and important decisions made during earlier sessions.
A useful way to think about Hermes’ memory is to separate it into three levels.
Figure 9. Hermes three-level memory system.
Level 1: compact memory
The first level is compact memory that can be loaded directly into the agent context. This is where the most important and stable information should live.
For example, the agent may remember that a project uses pnpm, that tests should be run with a specific command, that the user prefers short technical explanations, or that a certain deployment step should not be skipped.
This level of memory is intentionally small. That is a useful constraint. If everything is stored as always-on memory, the prompt becomes noisy and expensive. More importantly, the agent may start paying attention to details that are no longer relevant. Compact memory forces the system to keep only the information that should influence many future tasks.
Level 2: searchable session history
The second level is the searchable session history. Hermes can store previous conversations and make them searchable later. This is useful for information that does not need to be present in every prompt, but may still be useful when the agent needs to recover prior context.
For example, a developer may ask:
What did we decide last time about the authentication middleware?Or:
Find the previous debugging session where we fixed the Docker startup issue.In these cases, the relevant information may not belong in compact memory, but it should still be recoverable. Searchable history gives the agent access to older context without forcing all previous conversations into the current prompt.
Level 3: external memory
The third level is external memory. Hermes can also work with external memory providers, depending on configuration. This is useful when the user needs a deeper or more structured persistent memory system than local notes and session search.
External memory can help when the agent needs to retrieve relevant information from a larger store of previous interactions or user-specific knowledge.
This layered design is important because different types of information need different storage behavior.
Good vs Weak Memory Entries
Figure 10. Good vs Weak Memory Entries.
Some information should always be available. For example, if the user consistently prefers technical explanations without marketing language, that preference should influence most writing tasks. If a project has a specific test command, that command may be important in many future development sessions.
Other information should only be retrieved when relevant. A detailed debugging conversation from three weeks ago should not be injected into every prompt. It should be searchable when a similar issue appears, but it should not permanently occupy the agent’s main context.
This is the main trade-off in agent memory design: relevance versus capacity. Small memory is fast and always available, but it can only hold a limited amount of information. Searchable history can hold much more, but the agent must actively retrieve it. External memory can be more flexible, but it adds another system that needs to be configured and managed.
For developers, the most practical question is not “Can the agent remember everything?” A better question is: “What should the agent remember by default, and what should it retrieve only when needed?”
A good compact memory entry is usually stable, specific, and reusable. For example:
This repository uses pnpm for package management. Use pnpm test to run the main test suite.This is useful because it can guide future tool use. It is also specific enough to reduce repeated setup context.
A weak memory entry is usually vague or temporary:
The user was debugging something today.This does not provide enough operational value. It may also become irrelevant quickly.
Another weak memory entry would be:
The current error might be caused by the database.Unless confirmed, this is an assumption, not a stable fact. Storing assumptions as memory can make the agent worse over time, because it may treat uncertain information as reliable in future sessions.
Memory consolidation
Hermes also needs memory consolidation. Over time, memory can become crowded. If the agent keeps adding small notes without merging or removing old ones, the memory layer becomes noisy. Consolidation means rewriting several related observations into a shorter and more useful form.
For example, the agent may initially store several separate notes:
The backend uses FastAPI.
Tests are run with pytest.
Integration tests require the test database.
The user prefers small patches.After consolidation, this could become:
Backend project: FastAPI service tested with pytest. Integration tests require the test database. Prefer small, targeted patches when editing this repo.This compressed version is more useful because it preserves the important information while reducing memory overhead.
Memory should also avoid secrets. API keys, passwords, tokens, private credentials, and sensitive configuration values should not be stored as natural language memory. They belong in secure environment variables, secret managers, or configuration files designed for that purpose. A persistent agent that can store memory needs clear rules about what should never be saved.
In practice, Hermes’ memory is most useful when it is treated as an operational layer, not as a diary. The point is not to record every interaction. The point is to preserve information that improves future execution.
For a programming agent, useful memory might include:
Use `make test-api` before editing backend endpoints.
The project stores API route definitions under `src/routes/`.
Do not modify generated files under `dist/`.
The user prefers minimal diffs and explicit test output before final responses.For a research agent, useful memory might include:
Prioritize primary sources, official docs, and papers over secondary summaries.
Separate confirmed facts from speculation.
Include citations for model releases, benchmark results, and pricing claims.For a content or design agent, useful memory might include:
Use a technical, moderately formal tone.
Avoid punchline-style standalone lines.
Prefer diagrams that explain system flow or architecture.These examples show why memory matters for specialized profiles. Each agent role benefits from a different remembered context. A programmer profile should not necessarily share all of its memory with a researcher profile, because the two agents operate under different assumptions and workflows.
This is also why memory needs review. Persistent memory can improve the agent, but it can also accumulate noise. A practical Hermes setup should include occasional inspection of memory files and stored notes. If a memory is outdated, too vague, or no longer useful, it should be removed or rewritten.
The value of Hermes’ memory is not that the agent remembers everything. Its value is that the agent has a structured way to preserve the information that should influence future work. When used carefully, memory reduces repeated context setup, improves consistency across sessions, and gives the agent a better starting point for long-running workflows.
8. Self-Evolving Skills: Turning Repeated Workflows Into Reusable Procedures
Memory helps Hermes remember facts. Skills help it remember procedures and workflows.
This distinction is important. A memory entry can tell the agent that a project uses pytest, that the user prefers short technical explanations, or that a specific folder contains API routes. A skill goes further. It describes how to perform a repeatable workflow: which steps to follow, what tools to use, what errors to check, and how to verify the result.
In Hermes, skills are one of the main mechanisms behind the idea of a self-improving agent. The agent is not only expected to solve a task once. When it completes a non-trivial workflow, finds a working path after errors, or receives a correction from the user, it can turn that experience into a reusable skill. The next time a similar task appears, Hermes can load the relevant skill instead of starting from the same blank process again.
A skill is typically represented as a Markdown file with metadata and instructions. The metadata helps the agent decide when the skill is relevant. The body of the skill describes the workflow itself.
A simplified example might look like this:
---
name: debug-fastapi-tests
description: Use when debugging failing FastAPI backend tests.
version: 1.0.0
author: agent
---
## When to use
Use this skill when a backend test fails in the FastAPI service.
## Procedure
1. Run the focused failing test first.
2. Read the full stack trace before editing code.
3. Identify whether the failure is caused by route logic, dependency injection,
database state, or test setup.
4. Apply the smallest safe fix.
5. Re-run the focused test.
6. Run the broader backend test command before reporting completion.
## Pitfalls
- Do not edit generated files.
- Do not skip the database fixture setup.
- Do not assume the failing test is wrong before checking the implementation.
## Verification
The focused test passes, and the broader backend test command completes successfully.
This is not just a note. It is an operational procedure that the agent can follow during future tasks. The value comes from converting previous work into a structured, reusable format.
Figure 11. Memory vs Skills.
The practical benefit of skills becomes clearer when we look at repeated developer workflows. Many tasks do not require a completely new plan every time. They require a reliable process adapted to a specific environment.
For example:
- Debug a failing backend test.
- Review a pull request.
- Generate API documentation.
- Prepare a release checklist.
- Summarize a research paper.
- Create a diagram in a specific style.
- Write a newsletter section using a consistent structure.
Each of these workflows has steps, constraints, common mistakes, and verification criteria. If the agent has to rediscover them every time, it wastes context and increases the chance of inconsistent behavior. If the workflow is stored as a skill, the agent can begin with a stronger procedure.
This is especially useful for tasks that involve tools. A skill can tell the agent which command to run, which files to inspect, what output to look for, and when to stop. It can also document known pitfalls that are easy to forget during a long task.
For example, a repository-specific testing skill may contain:
Use `pnpm test:api` for backend API tests.
Use `pnpm test:unit -- <file>` for focused unit tests.
Do not run the full end-to-end suite unless explicitly requested.
Check `tests/fixtures/` before changing mocked data.This kind of skill reduces repeated setup and makes the agent’s behavior more consistent.
Hermes also uses a practical loading strategy for skills. The agent does not need to load the full content of every skill into the prompt at all times. That would quickly become too expensive and noisy. Instead, skills can be exposed progressively. The agent can first see skill names and descriptions, then load the full content only when a skill appears relevant.
Figure 12. Progressive Skill Loading.
This progressive approach matters because skill libraries can grow over time. If every skill were always loaded, the agent would become slower, more expensive, and less focused. By loading skills only when needed, Hermes can maintain a larger library while keeping the active context manageable.
The self-evolving part comes from how skills can be created and updated. When Hermes completes a useful workflow, the agent can write a new skill. When an existing skill is incomplete or outdated, the agent can patch it. When a skill becomes too broad, it can be split. When two skills overlap, they can eventually be consolidated.
In practice, skill creation should not happen after every task. A useful skill should usually meet a few conditions:
- The workflow is likely to repeat.
- The steps are specific enough to be actionable.
- The skill captures something more useful than a simple memory note.
- The procedure includes verification, not only instructions.
- The skill does not encode temporary assumptions as permanent rules.
For example, “User asked about FastAPI today” is not a skill. “How to debug failing FastAPI tests in this repository” can be a skill if it contains the relevant commands, files, pitfalls, and verification steps.
This is also where user correction becomes valuable. If the agent solves a task in a way that is almost correct but misses an important convention, the user can correct it. Hermes can then incorporate that correction into a memory entry or patch an existing skill. Over time, this turns repeated feedback into a more reliable workflow.
A common pattern looks like this:
- The agent attempts a task.
- The agent hits an error or receives user correction.
- The correct process is discovered.
- The agent stores the reusable process as a skill.
- Future similar tasks activate the skill earlier.
Figure 13. Self-Evolving Skill Loop.
The quality of the skill matters more than the number of skills. A small set of well-written skills can be more useful than a large library of vague procedures.
A good skill should be easy for the agent to recognize, specific enough to execute, and clear about verification. Weak skills can create the opposite effect: they may load at the wrong time, add unnecessary context, or push the agent toward outdated procedures.
For developers and AI practitioners, this makes skills similar to lightweight operational playbooks. They are not model weights, and they are not fine-tuning. They are structured instructions that sit around the model and guide its behavior during repeated workflows. This makes them easier to inspect, edit, version, and share.
This is one of the reasons Hermes is interesting from an agent engineering perspective. It treats repeated experience as something that can be externalized into files. Instead of hiding all adaptation inside the model, Hermes stores part of the adaptation as readable procedures. A developer can open a skill, review it, improve it, or remove it if it no longer matches the workflow.
That reviewability is important. Self-improvement in an agent system should not mean uncontrolled self-modification. It should produce artifacts that can be inspected. Skills give Hermes a practical form of procedural memory, but they still need curation. As the skill library grows, some skills become stale, some overlap, and some may stop matching the user’s current workflow.
This is why the next section is important. If an agent can create skills, it also needs a way to manage skill quality over time. Hermes addresses this through the Curator, which acts as a maintenance layer for the skill library.
9. The Curator: Keeping the Skill Library Clean
Self-evolving skills are useful only if the skill library remains clean. If an agent can create new skills after solving tasks, the number of skills can grow quickly. Some of these skills will be useful. Others may be too narrow, duplicated, outdated, or based on a workflow that is no longer relevant. Over time, this can make the agent less effective.
This is a common problem in persistent agent systems. Accumulated context can improve the agent, but unmanaged accumulation can also create noise. The same applies to skills. A growing skill library needs maintenance; the agent may load the wrong procedure, follow an outdated process, or waste context on skills that are no longer useful.
Hermes addresses this through a maintenance mechanism called the Curator.
The Curator is responsible for reviewing and managing agent-created skills over time. Its role is not to create new capabilities from scratch, but to keep the skill library healthy. It can identify stale skills, archive unused ones, review overlapping skills, and help maintain the quality of the procedures the agent depends on.
This is important because skills are part of the agent’s operating context. A weak memory entry can make the agent remember the wrong fact. A weak skill can make the agent repeat the wrong process. For example, if a skill contains an outdated test command, an old deployment path, or a debugging procedure that no longer matches the project, the agent may continue using that workflow even after it stops being useful.
The Curator helps reduce this risk by treating the skill library as something that needs lifecycle management.
A useful way to think about the Curator is as a background maintenance layer for procedural memory. Skills can move through different states depending on how often they are used and whether they still appear useful. A recently used skill remains active.
A skill that has not been used for a while may become stale. A skill that remains unused for longer can be archived. Archived skills are not necessarily deleted forever; they are moved out of the active skill library so they do not keep influencing future tasks unnecessarily.
Figure 14. Hermes Skill Lifecycle With Curator.
This lifecycle is useful because not all skills should have the same status forever. Some procedures are stable and should remain available for a long time. Others are temporary.
For example, a skill created to migrate a project from one framework version to another may be useful during the migration but unnecessary afterward. A skill created for a specific debugging problem may be useful only if that issue is likely to recur.
Without a maintenance process, the agent may keep treating both types of skills as equally relevant.
The Curator also helps with overlap. When an agent creates skills autonomously, it may create several skills that describe similar procedures. For example, one skill may describe how to debug API tests, another may describe how to debug backend test failures, and a third may describe how to inspect FastAPI errors. If these skills overlap heavily, the agent may become less certain about which one to use.
In such cases, skill consolidation may be better than keeping all of them. A well-structured skill library should make it easy for the agent to select the right procedure. Too many narrow or overlapping skills make selection harder.
The Curator can also patch skills when they are close to being useful but need improvement. This is different from deleting or archiving them. For example, a skill may have the right general procedure but an outdated command. In that case, patching the command is better than removing the entire skill.
This is one of the main reasons skill artifacts should be readable. Since skills are stored as files, they can be inspected, edited, versioned, and reviewed. A persistent agent should not only modify its behavior invisibly. It should produce artifacts that developers can open and understand.
Figure 15. Curator Maintenance Flow.
An important design detail is that the Curator should not be treated as an uncontrolled deletion mechanism. In a practical agent system, removing learned procedures automatically can be risky. A skill may be rarely used but still important. For example, a deployment rollback skill may be used only during incidents, but it should not disappear simply because it is not used every week.
This is why pinning matters. Critical skills can be protected so they remain available even if they are not used often. Pinning is useful for procedures that are rare but important, such as release checklists, recovery procedures, security review steps, or any workflow that the user explicitly wants to preserve.
Archiving is also safer than deletion. If a skill is archived, it can be restored later if needed. This is a practical design choice because it gives the system a way to reduce active-context noise without permanently losing potentially useful work.
Snapshots and rollback are also important. Before a maintenance pass changes the skill library, the system should preserve the previous state. This allows the user to recover from a bad curation decision. In any self-modifying or self-maintaining system, reversibility is a useful safety property. The agent may improve its own workspace, but the user should still be able to inspect and reverse changes.
The Curator is especially important when Hermes is used over a long period of time. During the first few sessions, the skill library may be small enough to manage manually. After weeks or months of use, the agent may have created many project-specific, role-specific, or workflow-specific skills. At that point, manual inspection becomes more difficult, and some automated maintenance becomes useful.
For developers and AI practitioners, the Curator represents an important part of agent engineering: persistence must include cleanup. Memory, skills, and session history are valuable because they accumulate experience. But accumulation without maintenance creates clutter. A persistent agent needs mechanisms for both learning and forgetting.
This is also why the Curator should be evaluated carefully. The goal is not to maximize the number of skills. The goal is to keep a useful set of skills that are specific, current, and easy for the agent to select. A smaller set of high-quality skills is usually better than a large collection of vague procedures.
In practice, a healthy Hermes skill library should have a few properties:
- Skills are specific enough to activate at the right time.
- Skills contain verification steps, not only instructions.
- Outdated commands are patched or removed.
- Overlapping skills are consolidated when possible.
- Rare but important skills are pinned.
- Archived skills can be restored.
- Users can inspect what the agent has created or changed.
The Curator does not make self-evolving skills automatically correct. It provides a maintenance layer around them. The agent can still create a weak skill, patch the wrong detail, or preserve a procedure that should be removed. Human review remains important, especially for skills that affect code execution, production systems, security, or external services.
However, the Curator makes the self-improvement loop more practical. It acknowledges that learning is not only about adding new knowledge. It is also about removing noise, updating old procedures, and keeping the active skill library aligned with current workflows.
This becomes increasingly important as the agent is used across more tasks, more profiles, and longer-running projects. A persistent agent needs memory and skills, but it also needs hygiene. The Curator is the part of Hermes that addresses this problem for skills.
10. GEPA and Offline Self-Evolution
The previous sections covered the runtime learning loop in Hermes: memory preserves facts, skills preserve procedures, and the Curator keeps the skill library cleaner over time. This provides Hermes with a practical form of self-improvement in normal use.
However, runtime learning has an important limitation. The agent may create or update a skill based on its own interpretation of what happened during a task. That interpretation can be useful, but it is not the same as a systematic evaluation.
An agent can complete a task and still produce a weak skill. It can overgeneralize from one example. It can treat a temporary workaround as a general rule. It can update a skill based on incomplete evidence. It can also assume that its own approach was better than it actually was.
This is the reason offline optimization matters.
Hermes has a companion self-evolution workflow based on GEPA (Genetic-Pareto Prompt Evolution). GEPA is not part of the normal Hermes runtime loop. It is better understood as an offline optimization process that can analyze execution traces, evaluate candidate changes, and propose improved versions of skills or related agent components.
The difference between runtime learning and offline optimization is important.
Runtime learning happens while the agent is being used. It is immediate, practical, and based on real interaction. For example, Hermes may solve a debugging task, discover the correct command sequence, and save that process as a skill.
Offline optimization is more deliberate. It takes existing artifacts, such as a skill, prompt, or tool description, and evaluates how they perform across a set of examples. Instead of relying only on the agent’s own confidence, the optimization process can compare variants and keep the versions that perform better under defined evaluation criteria.
Figure 16. Runtime Learning vs Offline Optimization.
A simple way to explain GEPA is this: it looks at how an agent system behaved, studies where it failed, and proposes textual changes that may improve future performance.
This is different from fine-tuning model weights. GEPA does not require updating the underlying language model. Instead, it works on the text-based parts of the system: prompts, instructions, skills, tool descriptions, and other editable components. For Hermes, this makes it a natural fit because many of the important agent behaviors are already represented as readable files and instructions.
In a Hermes context, the optimization target might be a skill. For example, assume the agent has a skill for debugging FastAPI tests. The skill may work for simple failures, but performs poorly when the failure is related to fixtures, dependency injection, or database state. Instead of manually rewriting the skill from scratch, an offline optimization process can evaluate the current skill against examples, inspect where it fails, and generate candidate improvements.
A simplified GEPA-style workflow for Hermes would look like this:
- Select a skill, prompt, or tool description to optimize.
- Build an evaluation set from synthetic cases, real session traces, or curated examples
- Run the current version and collect execution traces.
- Analyze failures and weak outputs.
- Generate candidate variants.
- Evaluate the variants against the same criteria.
- Keep the best-performing version if it passes constraints.
- Submit or review the change before it becomes part of the active system.
Figure 17. GEPA Offline Optimization Pipeline.
The key detail is the use of traces. A trace can include the model’s reasoning pattern, tool calls, tool outputs, errors, intermediate results, and final answers. This gives the optimizer more information than a simple success/failure score. Instead of only knowing that the result was wrong, the optimizer can inspect how the system got there.
For example, a trace might show that the agent loaded the right skill but skipped the verification step. Another trace might show that the skill description was too broad, causing it to activate for the wrong task. Another may show that the tool instructions were unclear, leading the agent to run the wrong command.
These are different failure modes, and they require different fixes.
- A weak skill description may need a clearer activation condition.
- A weak procedure may need more precise steps.
- A missing verification section may need an explicit completion check.
- A tool description may need clearer input and output expectations.
- A prompt may need stronger constraints around source quality, tests, or citation handling.
This makes GEPA relevant for compound AI systems, where the final behavior depends on multiple text-based components working together. In a persistent agent, the model is only one part of the system. The surrounding instructions, skills, tools, and evaluation rules also matter.
For developers, the practical value of this approach is that it gives a middle path between manual prompt editing and full model fine-tuning. If an agent workflow is underperforming, the first solution does not always need to be fine-tuning, RL, or switching to a larger model. Sometimes the bottleneck is the skill, the instruction structure, the tool description, or the evaluation setup.
GEPA is useful when the problem is repeated and measurable enough to evaluate. It is less useful for vague preferences or tasks where there is no clear definition of improvement.
Good candidates for offline optimization include:
- A skill that often activates correctly but misses important steps.
- A research workflow that produces inconsistent summaries.
- A code-review skill that misses recurring categories of issues.
- A documentation skill that does not follow the expected structure.
- A tool description that causes the model to call the tool incorrectly.
- A prompt that works on easy examples but fails on edge cases.
Weak candidates include:
- One-off tasks.
- Subjective preferences without evaluation examples.
- Workflows with no clear success criteria.
- Skills that are not used often enough to justify optimization.
- Problems caused by missing tool access rather than bad instructions.
This distinction matters because GEPA is not a general replacement for engineering judgment. It needs an evaluation target, examples, and constraints. Without those, the optimizer may produce changes that look better in isolation but do not improve the actual workflow.
A practical Hermes optimization setup should include constraint gates. For example, an optimized skill should preserve its original purpose, stay readable, avoid growing too large, and pass the relevant evaluation checks. If the skill affects code execution, it should include verification steps. If it affects research, it should preserve citation discipline. If it affects production-related workflows, it should require human review before being trusted.
This review step is important. Offline self-evolution should not mean that the agent silently rewrites its own operating instructions and immediately depends on them. A safer workflow is to generate candidate improvements, review the diff, test the new version, and then decide whether it should become active.
Figure 18. Safe Skill Optimization Review.
GEPA also fits well with the file-based design of Hermes skills. Because skills are written as readable Markdown files, an optimized skill can be reviewed like code or documentation.
This is more transparent than a hidden model update. A developer can inspect what changed, understand why the new version may behave differently, and revert the change if it causes problems.
This is one of the practical advantages of externalized agent behavior. When improvement is stored in skills, prompts, and tool descriptions, the improvement process can be audited. It can be versioned. It can be discussed in pull requests. It can be rolled back.
For a beginner using Hermes for the first time, GEPA is not the first feature to focus on. It is usually more useful to start with a clear SOUL.md, clean memory, and a small set of well-written skills. Once a workflow is repeated often enough and the failure modes become visible, offline optimization becomes more relevant.
In other words, GEPA is most useful after the agent has accumulated enough real workflow evidence to optimize against. It is not a shortcut around understanding the task. It is a way to improve the text-based components of the agent once you can define what “better” means.
For Hermes, this completes the self-improvement picture:
- SOUL.md defines the agent’s behavior.
- Memory preserves useful facts.
- Skills preserve reusable procedures.
- The Curator maintains the skill library.
- GEPA can evaluate and improve selected skills offline.
Together, these components show a practical pattern for persistent agents. Runtime learning helps the agent capture experience. Curation keeps that experience manageable. Offline optimization helps refine the parts that need more systematic evaluation.
This does not make the agent automatically reliable. It does, however, give developers a more inspectable and iterative path for improving agent behavior than repeatedly rewriting prompts manually or relying only on larger models.
11. Practical Setup: Installing Hermes Agent
After covering the main concepts behind Hermes, we can move into the practical setup. The goal of this section is not to configure every advanced feature immediately. The first goal is simpler: install Hermes, choose a model provider, verify that the agent can respond, and confirm that the local setup is healthy.
This matters because many agent setups become difficult to debug when users add too many features too early. Before connecting Telegram, creating profiles, scheduling jobs, or installing extra skills, it is better to get a clean terminal-based conversation working.
For most developers, the simplest starting point is a local CLI setup. Hermes can later be extended into messaging platforms, scheduled jobs, and multi-profile workflows, but the CLI is the easiest place to verify the core system.
Step 1: Choose the installation path
Hermes provides more than one installation option. For a versioned Python package install, you can use:
pip install hermes-agentAfter that, you can optionally run:
hermes postinstallThis path is useful if you prefer package-based installs and do not need to track the latest changes from the main repository.
The other common option is the git-based installer. This is useful if you want the latest version from the main Hermes repository:
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
Figure 19. Installing Hermes agent with the git-based installer.
After the installer finishes, reload your shell so the hermes command becomes available:
source ~/.bashrcOr, if you use Zsh:
source ~/.zshrcThe installer prepares the basic local environment for Hermes. Depending on the installation path and platform, this may include setting up the Hermes command, installing dependencies, creating the local Hermes directory, and preparing the environment for model/provider configuration.
Once you finish setting up your account and choose the path you want, this screen will appear on your terminal:
Figure 20. Setting up Hermes agent main settings.
At this point, it is useful to verify that the command is available:
hermes --helpIf the command is not found, the most likely issue is that the shell did not reload the updated PATH. Open a new terminal window or source the relevant shell configuration file again.
Step 2: Run the setup wizard
Once Hermes is installed, run:
hermes setupThis starts the main setup wizard. The wizard walks through the initial configuration and helps prepare Hermes for normal use.
Figure 21. Hermes Setup Wizard.
The setup step is important because Hermes needs more than the package installed. It also needs to know which model provider to use, how to access that provider, and which basic tools should be enabled.
If you already know which model provider you want to use, you can configure the model setup directly with:
hermes modelThis command is useful when switching providers or correcting a model configuration without rerunning the entire setup flow.
This command is useful when switching providers or correcting a model configuration without rerunning the entire setup flow.
Step 3: Choose a model provider
Hermes is designed to work with different model providers. The exact provider you choose depends on your workflow, budget, and access. Some users may prefer a direct API key. Others may prefer OAuth-based login or a provider aggregator. Some may want to use a local or self-hosted model.
For the first setup, avoid over-optimizing the model choice. Pick one provider that you already have access to, configure it correctly, and verify that a normal conversation works.
The most important thing at this stage is not choosing the “best” model. It is confirmed that Hermes can complete a basic interaction reliably. Once that works, you can experiment with stronger models, cheaper models, fallback routes, or local endpoints.
After choosing the provider, Hermes may ask for credentials depending on the provider type. API keys and tokens should be treated as secrets. Do not paste them into memory files, screenshots, blog images, or public configuration examples. Use the setup flow, environment variables, or the documented configuration path instead.
In this blog, I will use the Nous Portal to choose from the 300 models, and I will go with the free stepfun/step-3.7-flash model, since it is free and will be enough for this blog. For real use cases, I will go with SOTA models such as Opus 4.8 or gpt-5.5.
Figure 22. Selecting the default model for the hermes agent.
Step 4: Start the first chat
After installation and provider configuration, start Hermes from the terminal:
hermes
Figure 23. Hermes Agent starting terminal.
Then send a simple test prompt:
Hello. Briefly confirm that you are working and tell me what tools are available.The goal is to verify that the agent can respond, that the model provider is configured correctly, and that the terminal interface is functional.
Figure 24. First Hermes Terminal Chat
If the agent responds normally, the core setup is working. If it fails, do not move immediately into profiles, gateways, or scheduled jobs. Fix the base setup first.
A useful diagnostic command is:
hermes doctorThis checks the environment and reports missing or misconfigured parts. It is usually the first command to run when Hermes is installed, but not behaving as expected.
Step 5: Confirm the setup before adding more features
At this point, a minimal working setup should have three properties:
Hermes is installed. A model provider is configured. A terminal chat works successfully.
Once these are confirmed, you can start adding more layers: editing SOUL.md, configuring memory, creating profiles, connecting Telegram, installing skills, and setting up scheduled tasks.
It is better to add these layers gradually. If something breaks after adding a new feature, you can identify the cause more easily. If you configure everything at once, debugging becomes harder because the failure could come from the model provider, tool permissions, profile configuration, gateway setup, environment variables, or a scheduled job.
A good first setup flow looks like this:
Install Hermes
→ Configure provider
→ Start terminal chat
→ Run a simple task
→ Check diagnostics
→ Then add profiles, messaging, skills, and automation
Figure 25. Minimal Hermes Setup Flow
This staged approach is especially useful for developers who plan to use Hermes as a persistent agent. Since Hermes can accumulate memory, create skills, and operate through external interfaces, the foundation should be stable before long-running workflows are added.
For the rest of this guide, we will assume that Hermes is installed, the CLI works, and the agent can complete a basic conversation. In the next section, we will look at the local ~/.hermes/ directory, because understanding where Hermes stores configuration, memory, skills, sessions, and logs makes the rest of the system easier to reason about.
12. Understanding the ~/.hermes/ Folder
After installing Hermes, it is useful to understand where the agent stores its local state. This is especially important for developers, because Hermes is not only a command-line chat interface. It is a persistent agent system, which means it needs a local place to store configuration, identity, memory, skills, sessions, logs, and scheduled jobs.
By default, this local workspace lives under:
~/.hermes/You can think of this directory as the agent’s home directory. It contains the files that define how Hermes behaves, what it remembers, which skills it can use, and how it should connect to model providers or external tools.
The exact structure can vary depending on the installation, version, enabled features, and profile setup, but a typical Hermes home may include files and directories like this:
~/.hermes/
├── config.yaml
├── .env
├── SOUL.md
├── memories/
├── skills/
├── sessions/
├── cron/
├── logs/
├── cache/
├── plugins/
└── state database files
Figure 26. The ~/.hermes/ Directory Tree
The first file to understand is config.yaml. This is the main configuration file for non-secret settings. It can contain model/provider settings, feature flags, tool configuration, MCP-related configuration, and other runtime behavior depending on the user’s setup. If Hermes is not behaving as expected, config.yaml is one of the first files to inspect.
Figure 27. The Hermes config.yaml file.
The second important file is .env. This file is used for environment variables and secrets, such as API keys, tokens, and provider credentials. It should be treated carefully. Do not include it in screenshots, blog posts, GitHub repositories, or shared profile distributions unless it has been fully sanitized.
A useful rule is simple:
- config.yaml = non-secret configuration
- .env = secrets and environment variables
This distinction matters because persistent agents often interact with external systems. A model provider key, API token, or messaging platform token should not be stored in memory or written into a normal Markdown note. It belongs in the environment or a secret management path.
The next important file is SOUL.md. As discussed earlier, this file defines the agent’s durable identity. It controls the role, tone, communication style, priorities, and broad operating behavior of the Hermes instance. If you want Hermes to behave like a pragmatic engineering assistant, a careful research assistant, or a concise personal agent, SOUL.md is where that baseline behavior is defined.
It is useful to keep SOUL.md focused on durable identity rather than project-specific instructions. A good SOUL.md describes how the agent should behave across many tasks. It should not become a large file containing every repository command, temporary note, or one-off workflow detail. Those belong in memory, skills, or project-specific context files.
The memories/ directory stores persistent memory. This is where Hermes can keep useful information that should survive across sessions. Depending on the configuration, this may include user preferences, project facts, recurring constraints, or other stable contexts that help the agent work more consistently.
Memory should be treated as an operational layer, not a dumping ground. If this folder becomes full of vague notes, temporary assumptions, or outdated facts, the agent may start with a worse context rather than a better context. It is useful to inspect memory periodically and remove or rewrite entries that no longer help.
The skills/ directory contains reusable procedures. These are one of the most important parts of Hermes. A skill may describe how to debug a specific type of failure, write documentation in a certain format, review a pull request, generate a report, or perform another repeated workflow.
Skills are different from memory. Memory stores facts. Skills store procedures.
For example, a memory entry may say:
This backend project uses pytest.A skill may say:
When debugging failing backend tests, first run the focused test,
inspect the stack trace, check fixtures, apply the smallest safe fix,
then rerun the focused and broader test suite.This is why the skills/ directory is worth inspecting. It shows how the agent is building procedural knowledge over time. If a skill is wrong, too broad, or outdated, you can edit it directly instead of repeatedly correcting the agent in conversation.
The sessions/ directory stores conversation/session history. This helps Hermes preserve past interactions and retrieve older context when needed. Not every past conversation should become compact memory, but older sessions can still be useful when the agent needs to recover what happened previously.
For example, a user may later ask:
What did we decide in the previous debugging session?Or:
Find the session where we fixed the deployment script issue.Searchable session history gives Hermes a way to retrieve that context without loading every old conversation into the active prompt.
The cron/ directory is related to scheduled work. Hermes can run recurring or delayed jobs, and scheduled task definitions need a place to live. This becomes important when you move from interactive agent use to proactive workflows, such as daily research summaries, weekly repository reports, or recurring reminders.
The logs/ directory is useful for debugging. If Hermes fails to start, cannot access a provider, has tool execution issues, or behaves unexpectedly, logs may help identify what happened. For a developer, logs are especially useful because they turn agent behavior into something inspectable rather than opaque.
The cache/ directory is used for the cached state. In most cases, users do not need to edit cache contents manually. However, knowing that it exists helps when debugging storage, cleanup, or repeated behavior issues.
The plugins/ directory is related to enabled plugin functionality. Depending on the Hermes configuration, plugins may add extra capabilities or maintenance behavior. As with other agent extensions, it is better to enable plugins gradually and verify each one before relying on it in long-running workflows.
Hermes may also maintain state database files. These are used internally to track the persistent state. In general, you should not edit these files manually unless the documentation or a specific debugging workflow tells you to. For normal usage, interact with Hermes through the CLI and supported commands rather than directly modifying internal databases.
Figure 28. What Lives Inside ~/.hermes/
Understanding this folder also helps explain profiles. A Hermes profile is effectively a separate agent home. Each profile can have its own configuration, identity, memory, skills, sessions, cron jobs, and state. This is useful when you want isolated agents for different roles. For example, a coding assistant and a research assistant should not necessarily share the same memories, tools, or skills.
A simplified profile structure may look like this:
profiles/
├── coder/
│ ├── config.yaml
│ ├── .env
│ ├── SOUL.md
│ ├── memories/
│ ├── skills/
│ └── sessions/
│
└── researcher/
├── config.yaml
├── .env
├── SOUL.md
├── memories/
├── skills/
└── sessions/The exact path depends on how Hermes manages profiles in your installation, but the concept is the same: each profile keeps its own working state. This separation makes the agent easier to reason about. A research profile can accumulate source-quality rules and citation preferences, while a coding profile can accumulate project commands, debugging procedures, and test workflows.
Figure 29. Multiple Hermes Profiles as Separate Homes
There are a few practical habits that make the ~/.hermes/ directory easier to manage.
First, inspect the configuration before editing the behavior. If the agent is using the wrong model, tool, or provider, the issue may be in configuration rather than memory or skills.
Second, keep secrets out of memory and screenshots. The .env file should be handled like any other credentials file. If you are writing a blog post, crop or blur anything that could expose API keys, tokens, usernames, private paths, or sensitive project names.
Third, review skills periodically. Skills are powerful because they are reusable, but they can also become outdated. If the agent keeps repeating a bad workflow, inspect the relevant skill file.
Fourth, do not treat the home directory as a black box. One of the advantages of Hermes is that much of the agent state is represented in files that developers can inspect. This makes the agent easier to debug and easier to trust than a system where all behavior is hidden behind a remote interface.
Finally, avoid editing internal state files casually. Files like SOUL.md, memory files, skills, and configuration are meant to be understandable. Internal databases and caches are different. They are part of the runtime state and should usually be managed through Hermes commands.
Understanding ~/.hermes/ is a practical step toward using Hermes well. Once you know where the agent stores configuration, identity, memory, skills, sessions, and logs, the system becomes easier to debug and customize.
In the next section, we will use this knowledge to create the first useful agent configuration instead of leaving Hermes as a generic assistant.
13. Creating Your First Useful Agent
Once Hermes is installed and the local folder structure is clear, the next step is to configure a useful agent rather than using Hermes as a generic assistant.
A good first target is a developer assistant profile. This is practical because software work has a clear context, repeatable workflows, verifiable outputs, and well-defined constraints. The agent can learn project structure, remember commands, develop debugging skills, and use tools in a way that can be reviewed.
The goal is not to create a fully autonomous coding agent immediately. A better first setup is a narrow assistant that helps with one repository or one class of tasks, while keeping its identity, memory, and skills easy to inspect.
Start with one focused profile
If you are experimenting with Hermes for the first time, avoid creating many profiles immediately. Start with one profile that has a clear purpose.
For example:
developer-assistantThis profile can be configured around a simple role:
A pragmatic engineering assistant that helps inspect repositories,
run tests, debug failures, write documentation, and preserve useful
project-specific procedures.If you want to create a dedicated profile from the CLI, Hermes provides profile commands. A simple example would be:
hermes profile create developer-assistant --description "Helps with coding, debugging, tests, and repository documentation."If you already configured a base Hermes profile and want to reuse its model/provider setup, you can clone the current configuration when creating a new profile:
hermes profile create developer-assistant --clone --description "Helps with coding, debugging, tests, and repository documentation."The reason to use a profile is isolation. A developer profile should have different memory and skills from a research profile or a content profile. This makes the agent easier to reason about. Project-specific commands, test workflows, and debugging notes should not be mixed with unrelated research or writing preferences.
Figure 30. Creating developer profile in Hermes Agent.
Define the agent’s identity in SOUL.md
After creating the profile, the first file to configure is SOUL.md. This file should define the durable behavior of the agent. For a developer assistant, the identity should be specific enough to guide real tasks, but not so long that it becomes difficult to maintain.
A practical SOUL.md might look like this:
# SOUL.md
You are a pragmatic software engineering assistant.
Your priorities are correctness, small safe changes, and clear verification.
When working with a codebase:
- Read existing code before proposing changes.
- Prefer focused edits over broad rewrites.
- Identify the relevant test command before editing.
- Run or recommend verification steps before marking work complete.
- Explain trade-offs briefly and avoid unnecessary abstraction.
When debugging:
- Reproduce the issue when possible.
- Read the full error message and stack trace.
- Inspect the smallest relevant part of the codebase first.
- Avoid assuming the test is wrong before checking the implementation.
Safety constraints:
- Do not store secrets in memory.
- Do not modify generated files unless explicitly requested.
- Do not claim a fix is verified unless tests or checks were actually run.This is not meant to be a clever prompt. It is an operating contract for the profile. It defines the role, priorities, and boundaries that should apply across many tasks.
Figure 31. The Developer Assistant SOUL.md.
The identity file should stay focused on stable behavior. Do not put every project detail into SOUL.md. Repository commands, local setup notes, and repeated debugging patterns belong in memory or skills.
A useful separation is:
SOUL.md → how the agent should behave memory → what the agent should remember skills → how the agent should perform repeated workflows
Add a small amount of useful memory
After the identity file is configured, add only the memory that will help the agent start working effectively. For a developer profile, good initial memory might include:
The user prefers small, targeted code changes over large rewrites.
The user prefers technical explanations without promotional phrasing.
When working on repositories, identify the test command before changing code.
Do not store API keys, tokens, or secrets as memory.If you are configuring the agent for a specific repository, you can add repository-level memory after the agent inspects the project. For example:
This project uses pnpm for package management.
The backend API routes are under src/routes/.
Use pnpm test:api for backend API tests.
Generated files under dist/ should not be edited manually.These are good memory entries because they are stable, specific, and operational. They help the agent make better decisions in future tasks.
Avoid memory entries like:
The user was debugging a backend issue today.
The error might be related to the database.
The current branch seems messy.These are weak memory entries. They are either temporary, uncertain, or too vague to improve future work.
Figure 32. First Developer Memory Entries
Give the agent a real first task
The first useful task should be small, verifiable, and connected to the profile’s purpose. Avoid starting with a broad request like:
Understand this whole codebase and improve it.That task is too open-ended for a first run. A better first task is specific:
Inspect this repository and identify how to run the main test suite.
Do not modify files. Summarize the project structure and the commands
you found.This task is useful because it lets the agent inspect the repository without making changes. It also produces information that may become memory later.
A second task can be slightly more action-oriented:
Find one small documentation improvement in the README.
Make the smallest useful edit, then summarize what changed.A debugging task can also work if it is narrow:
Investigate why this focused test is failing.
First run the relevant test, then inspect the error, then propose the
smallest safe fix.
Figure 33. First Useful Hermes Task
The point of the first task is to establish a working pattern. Hermes should inspect before acting, explain what it found, and only preserve information that is useful for future sessions.
Ask Hermes to preserve stable findings
After the agent completes a useful inspection or debugging task, decide what should become persistent.
For example, if Hermes finds the correct test command, you can ask:
Save the confirmed test command and relevant project conventions as memory.
Do not save temporary observations or guesses.This gives the agent explicit guidance about what should be preserved. It also reinforces the distinction between stable facts and temporary task details.
A good saved memory might be:
For this repository, run pnpm test:api to execute backend API tests.A bad saved memory would be:
The test failed today and might be caused by middleware.The first memory entry is reusable. The second is temporary and uncertain.
Let repeated workflows become skills
Once the same type of task appears more than once, it may be worth turning the process into a skill. For example, if Hermes repeatedly helps debug backend test failures, you can ask it to create a skill:
Create a skill for debugging backend API test failures in this repository.
Include when to use it, the commands to run, common pitfalls, and
verification steps.A useful skill should include:
- When to use the skill
- Required context
- Step-by-step procedure
- Common pitfalls
- Verification criteria
- What not to do
For example, the skill might tell Hermes to first run the focused test, inspect the stack trace, check fixtures, apply the smallest safe fix, rerun the focused test, and only then run the broader suite.
Figure 34. First Generated Developer Skill
The important point is that skills should emerge from repeated workflows. Do not create a large skill library before the agent has done real work. A skill is most useful when it captures a process that has already proven useful.
Review the generated skill before trusting it
When Hermes creates or patches a skill, inspect it like you would inspect a script or a project checklist. The skill may be useful, but it can also contain wrong assumptions.
Check for the following:
- Is the activation condition clear?
- Are the steps specific enough?
- Does it include verification?
- Does it avoid unsafe commands?
- Does it contain temporary assumptions?
- Does it match the current project?
A generated skill should not be treated as automatically correct just because the agent wrote it. It is a reusable procedure, so mistakes inside it may affect future tasks.
This is why starting small is important. It is easier to review one developer skill than a large library of agent-generated procedures.
A minimal first-agent workflow
A practical first Hermes agent workflow can be summarized like this:
- Create or select one focused profile.
- Write a concise SOUL.md for that role.
- Add only stable, reusable memory.
- Ask the agent to inspect a real project without making changes.
- Save confirmed project facts as memory.
- Use the agent for one small verifiable task.
- Convert repeated workflows into skills.
- Review generated skills before relying on them.
Figure 35 . First Useful Hermes Agent Workflow
This first-agent setup gives Hermes enough structure to become useful without making the system hard to debug. The profile has a defined identity, a small amount of memory, and a path for turning repeated work into skills.
Once this works, it becomes much easier to add more specialized profiles. The next section will expand on this idea by showing how multiple Hermes profiles can be used to separate coding, research, design, and personal automation workflows.
14. Working With Multiple Profiles
After creating one useful Hermes agent, the next step is to decide whether you need more than one profile.
A profile is a separate Hermes agent environment. Each profile has its own configuration, identity file, memory, sessions, skills, scheduled jobs, gateway state, and environment variables. This makes profiles useful when different workflows need different behavior and different persistent state.
For example, a coding assistant and a research assistant should not necessarily share the same memory. A coding assistant may need to remember repository commands, testing workflows, local development constraints, and debugging procedures. A research assistant may need to remember preferred sources, citation rules, summarization format, and topic scope. If both roles share one memory and one skill library, the agent can become harder to control over time.
Profiles solve this by separating the agent state by role.
A practical Hermes setup might use profiles like this:
- coder → works on repositories, tests, debugging, documentation
- researcher → tracks papers, tools, releases, and technical sources
- designer → creates diagrams, visual explanations, and image briefs
- assistant → handles personal automation, reminders, and summaries
Each profile can use the same underlying Hermes runtime, but each one can have its own SOUL.md, memory files, skills, sessions, model configuration, API keys, and messaging gateway.
Figure 36. One Hermes Runtime, Multiple Profiles
Creating a new profile
A simple profile can be created from the CLI:
hermes profile create coderAfter creating the profile, Hermes exposes it as its own command. For example:
coder setup
coder chatThis means you do not always need to pass profile flags manually. The profile becomes a named agent command with its own state.
For a more descriptive profile, include a short role description:
hermes profile create researcher --description "Reads papers, official docs, and technical sources, then writes concise findings."Descriptions are useful because they make the profile’s purpose explicit. They also become more important when profiles are used in multi-agent or routing workflows, where an orchestrator needs to decide which profile is suitable for a task.
Cloning an existing profile
Sometimes you want a new profile to start with the same provider, model, environment variables, or basic skill setup as an existing one. In that case, cloning can be useful:
hermes profile create work --cloneThis will create a new profile named work and clone only the configuration-level files from the currently active profile. A cloned profile can copy the current profile’s configuration, environment file, identity file, and skills, while still giving the new profile its own sessions and memory. This is useful when you want a new agent with the same basic setup but a different role.
For example, you might clone a base profile into:
coder
researcher
designerThen edit each profile’s SOUL.md and memory files separately.
This keeps setup time low without forcing all agents to share the same identity or memory.
Editing each profile’s identity
Each profile should have its own SOUL.md. For a coding profile, the identity may focus on correctness, minimal diffs, tests, and reading existing code before editing:
# SOUL.md
You are a pragmatic software engineering assistant.
Prioritize correctness, small safe changes, and verification.
Read existing code before editing.
Identify the relevant test command before changing code.
Do not claim work is complete unless verification was run or clearly recommended.For a research profile, the identity should be different:
# SOUL.md
You are a careful technical research assistant.
Prioritize primary sources, official documentation, and papers.
Separate confirmed facts from speculation.
Cite claims that depend on external sources.
Summarize findings clearly without promotional language.For a design or diagram profile, the identity might focus on visual clarity and consistency:
# SOUL.md
You are a technical diagram assistant.
Create diagrams that explain architecture, workflows, and system behavior.
Prioritize clarity, readable labels, and consistent visual structure.
Avoid decorative complexity that makes the concept harder to understand.The important point is that a profile should not only have a different name. It should have a different operating frame. Otherwise, multiple profiles become mostly cosmetic.
Keeping memory separate
Profiles are most useful when their memories stay separate. A coding profile can remember:
This repository uses pnpm.
Backend tests run with pnpm test:api.
Do not edit generated files under dist/.
The user prefers small diffs and explicit verification.A research profile can remember:
Prioritize official docs, papers, and primary sources.
Include citations for model releases, benchmark claims, pricing, and dates.
Separate confirmed facts from interpretation.A design profile can remember:
Use clean technical diagrams with readable labels.
Prefer architecture and workflow diagrams over decorative illustrations.
Keep visual style consistent across a blog series.Keeping these memories separate prevents unrelated context from leaking into the wrong workflow. A coding agent does not need to load diagram preferences every time it debugs a failing test. A research agent does not need to remember local backend commands. A design agent does not need repository-specific deployment notes.
Profiles are not sandboxes
One important detail is that profiles isolate Hermes state, but they do not automatically sandbox filesystem access. This means a profile can have its own memory, skills, config, and sessions, but that does not necessarily restrict what files the agent can access through tools. On a local terminal backend, the agent may still have the same filesystem access as the user account running Hermes.
This distinction matters.
A profile answers this question:
Which identity, memory, skills, sessions, and config should this agent use?A sandbox answers a different question:
Which files, commands, and system resources is this agent allowed to access?These are related, but they are not the same. If you want a profile to start in a specific project folder, configure the working directory explicitly. For example:
coder config set terminal.cwd /absolute/path/to/projectThis gives the coding profile a predictable starting point when it uses terminal tools.
However, setting a working directory is not the same as enforcing a strict filesystem boundary. If you need stronger isolation, use a proper sandboxing mechanism, container, restricted user account, or limited execution environment.
Figure 37. Profiles vs Sandboxes
Choosing how many profiles to create
It is easy to create too many profiles too early. A better approach is to start with one profile, use it for a real workflow, and create another profile only when there is a clear reason.
A new profile is useful when:
- The role needs a different SOUL.md.
- The workflow needs different memory.
- The tools or API keys should be different.
- The skill library should be separate.
- The profile will run through a different messaging bot or gateway.
- The tasks have different risk levels.
A new profile is probably unnecessary when:
- The task is only slightly different.
- The same memory and skills are still useful.
- The distinction is only cosmetic.
- The profile would not have a different role or configuration.
For example, it makes sense to separate coder and researcher. It may not make sense to create coder-api, coder-tests, coder-docs, and coder-refactor on day one unless each of them genuinely needs separate memory, skills, tools, or operating rules.
Using different gateways per profile
Profiles also matter when Hermes is connected to messaging platforms such as Telegram, Discord, Slack, WhatsApp, or Signal. Each profile can run its own gateway process and use its own bot token. This allows different agents to appear as different bots.
For example:
coder gateway start
researcher gateway startIn this setup, the coding profile and research profile can receive messages separately, preserve separate histories, and respond using their own identity and memory.
This is useful if you want:
- One Telegram bot for coding tasks
- One Telegram bot for research summaries
- One Telegram bot for personal automation
Do not reuse the same bot token across unrelated profiles. Each messaging bot should map cleanly to one profile so that conversations, memory, and gateway state remain easier to reason about.
Figure 38. Separate Messaging Bots for Separate Profiles
A practical multi-profile setup
A simple and useful multi-profile setup might look like this:
coder/
Purpose: repository work, debugging, tests, documentation
Memory: project commands, conventions, generated-file rules
Skills: debugging tests, writing docs, reviewing changes
researcher/
Purpose: technical research and source-based summaries
Memory: citation rules, preferred sources, topic scope
Skills: paper summary, repo analysis, release tracking
designer/
Purpose: diagrams and visual explanation
Memory: visual style preferences, brand constraints, image format rules
Skills: architecture diagrams, workflow diagrams, figure promptsThis structure keeps the profiles distinct without overcomplicating the system.
A useful rule is to create profiles around durable roles, not around temporary tasks.
For example, “researcher” is a durable role. “Summarize this one paper” is a task. “Coder” is a durable role. “Fix today’s bug” is a task. Profiles should represent long-running ways of working.
Managing profiles over time
As the number of profiles grows, profile management becomes part of the workflow.
Useful commands include:
hermes profile list
hermes profile show coder
hermes profile use coderThese help you inspect available profiles, view profile details, and set the active default profile.
Profile management should be treated like managing environments. Each profile has its own state, so changes should be made deliberately. If a profile starts behaving poorly, inspect its SOUL.md, memory files, skills, and configuration before assuming the model is the problem.
In many cases, the issue is not the model itself. The issue may be outdated memory, an overly broad skill, a vague identity file, or a working directory that points to the wrong project.
Practical guidance
For most users, the best starting point is:
- Start with one profile.
- Make it useful.
- Then add a second profile only when the role genuinely needs separate state.
A good first expansion is usually:
- coder → for repository and coding work
- researcher → for papers, tools, docs, and technical summaries
A design or content profile can come later if the workflow repeats often enough.
The main benefit of profiles is not the number of agents. The benefit is cleaner state. Each profile can accumulate the memory, skills, and identity that belong to its role without contaminating other workflows.
Used carefully, profiles make Hermes easier to scale from one useful assistant into a small set of specialized agents. Used too early or too casually, they can add complexity without improving the system.
15. Connecting Hermes to Telegram or Messaging Apps
So far, we have treated Hermes mostly as a local CLI agent. That is the right place to start, because it keeps the setup simple and makes debugging easier. However, Hermes becomes more useful when it is reachable from the same places where you already communicate and coordinate work.
This is where messaging gateways become important.
A messaging gateway connects Hermes to an external messaging platform such as Telegram, Discord, Slack, WhatsApp, Signal, or another supported platform. Instead of opening a terminal every time, you can message the agent from your phone, a group chat, or a team channel. Hermes receives the message, routes it into the correct agent session, runs the task, and sends the response back to the chat.
For a persistent agent, this is not just a convenience feature. It changes how the agent fits into daily work.
A CLI agent is useful when you are already at your machine. A messaging agent is useful when you want to send a task from anywhere, receive scheduled outputs, follow up on a long-running task, or use different profiles as different assistants.
For example:
- Send a research task to a researcher profile from your phone.
- Ask a coding profile to summarize a repository issue.
- Receive a daily digest in Telegram every morning.
- Use a personal assistant profile for reminders and small automations.
- Route different bots to different Hermes profiles.
The important point is that messaging should be added after the base CLI setup works. If Hermes cannot run a normal terminal chat reliably, connecting it to Telegram or another platform will only make debugging harder.
Step 1: Decide which profile should become a bot
Before configuring Telegram or any messaging platform, decide which Hermes profile should be exposed through the gateway.
For example, you may have:
- coder → repository work, debugging, documentation
- researcher → papers, tools, releases, and technical summaries
- assistant → personal automation, reminders, and recurring updates
Each of these profiles may need a different messaging setup. A coding agent may be better kept private. A research bot may be useful in a team group. A personal assistant may only need direct messages.
Do not connect every profile to messaging on day one. Start with one profile and verify that it works.
A good first choice is usually:
researcherThis is lower risk than exposing a coding profile with filesystem and command execution access. A research profile can still be useful through messaging without immediately giving the bot broad operational power.
Figure 39. Messaging Gateway as an Interface Layer.
Step 2: Create a bot on the messaging platform
For Telegram, the usual flow starts with creating a bot through BotFather.
The process is:
- Open Telegram.
- Message BotFather.
- Create a new bot.
- Choose a bot name and username.
- Copy the bot token.
The token is the credential Hermes uses to connect to the bot. Treat it like a secret. Anyone with the token may be able to control the bot, depending on the platform and configuration.
Do not paste the token into:
- SOUL.md
- MEMORY.md
- skills
- blog screenshots
- GitHub repositories
- public config examples
The token belongs in the environment or the platform setup flow, not in memory or documentation.
Figure 40. Telegram Bot Creation With BotFather
Step 3: Configure the Hermes gateway
Once the bot exists, configure the Hermes gateway:
hermes gateway setupThis starts an interactive setup flow for messaging platforms. During the setup, choose the platform you want to connect, provide the required credentials, and configure the access rules.
For Telegram, the setup usually involves:
- bot token
- allowed users or allowed chats
- direct message behavior
- group chat behavior
- home channel configuration, if needed
The access-control step is important. A messaging bot should not necessarily respond to everyone who can find it. For a private assistant, restrict access to your own Telegram user ID. For a team bot, explicitly define which users or groups can trigger the agent.
Figure 41. Hermes Gateway Setup
You will also need to pass the allowed Telegram user IDs. To do so, you can get your allowed user ID following these steps:
- Open Telegram.
- Search for **@userinfobot**.
- Start the bot.
- It will reply with your numeric Telegram ID.
After configuration, start the gateway:
hermes gateway startThen check the status:
hermes gateway statusIf you are testing in the foreground instead of running it as a service, you can run:
hermes gatewayThis is useful during debugging because logs and errors are visible directly in the terminal.
Step 4: Test a private chat first
Before adding the bot to a group, test it in a private chat.
Send a simple message:
Hello. Confirm which Hermes profile you are connected to.Then test a slightly more useful task:
Summarize what you can do in this profile and list any active tools or constraints.The purpose is to confirm three things:
- The bot receives messages.
- Hermes routes the message to the correct profile.
- The response comes back to the same chat.
Figure 42. First Telegram Message to Hermes
If the bot does not respond, check the problem in layers:
- Is the gateway running?
- Is the bot token correct?
- Is the user authorized?
- Is the message being delivered to the bot?
- Is the correct profile active?
- Are there errors in the gateway logs?
Do not immediately change the model, memory, or skills. Messaging failures are usually gateway, token, authorization, or delivery issues.
Step 5: Configure group chat behavior carefully
Group chats need more careful configuration than private chats.
In a private chat, every message is likely intended for the bot. In a group chat, most messages may not be intended for the agent. If the bot responds too freely, it can create noise and interrupt normal discussion.
A safer group configuration is to require explicit mentions.
For example, a group message should trigger the agent only when the user writes something like:
@researcher_bot summarize today’s AI releasesOr replies directly to the bot.
This is especially important if multiple Hermes bots are in the same group. Without clear routing, more than one bot may try to respond to the same message.
For group use, the practical rule is:
- Use mentions for routing.
- Keep normal group chatter ignored.
- Use one bot token per Hermes profile.
Step 6: Use one bot token per profile
If you run multiple Hermes profiles as messaging bots, each profile should use its own bot token.
For example:
- coder profile → **@coder_bot**
- researcher profile → **@researcher_bot**
- assistant profile → **@assistant_bot**
This keeps routing easier to reason about. It also prevents token conflicts. If two running gateways try to use the same Telegram bot token, the platform may reject concurrent polling, or Hermes may block startup to prevent the conflict.
A clean setup looks like this:
- **@coder_bot **→ coder profile → coder memory + coder skills
- **@researcher_bot **→ researcher profile → researcher memory + researcher skills
- **@assistant_bot** → assistant profile → assistant memory + assistant skills
Avoid this:
- **@one_shared_bot **→ coder + researcher + assistant profiles
A shared bot can work in some designs, but it increases the risk of state mixing and routing confusion. For most users, one bot per profile is easier to debug and maintain.
Figure 43. Separate Messaging Bots for Separate Profiles
Step 7: Run gateways per profile
If you want to run a gateway for a named profile, use the profile flag.
For example, to start a researcher profile gateway:
hermes -p researcher gateway startTo check its status:
hermes -p researcher gateway statusTo stop it:
hermes -p researcher gateway stopFor the default profile, the commands are:
hermes gateway start
hermes gateway status
hermes gateway stopThis makes it possible to run several profile gateways on the same machine, each with its own configuration and bot credentials.
A simple multi-profile gateway setup might look like this:
hermes -p coder gateway start
hermes -p researcher gateway start
hermes -p assistant gateway startIf you run this kind of setup regularly, use scripts or service management rather than manually starting each process every time.
Step 8: Set a home channel for scheduled outputs
Messaging becomes more useful when combined with scheduled jobs.
For example, a researcher profile can run a daily briefing task and deliver the result to a Telegram chat. For that to work cleanly, Hermes needs to know where background outputs should be sent.
Inside the messaging chat, set the home channel:
/sethomeAfter that, scheduled jobs and background outputs can be routed to that chat, depending on the gateway and job configuration.
This is useful for workflows such as:
- daily AI research digest
- weekly repository summary
- morning planning brief
- content idea generation
- release monitoring
Figure 44. Scheduled Output Delivered to Messaging
Step 9: Define what the bot should not do
A messaging bot is easier to trigger than a CLI agent. That makes boundaries more important.
For each bot, define what it should not do.
For a research bot:
- Do not publish findings without user review.
- Do not cite sources that were not actually checked.
- Do not treat search snippets as final evidence.
For a coding bot:
- Do not run destructive commands from chat.
- Do not modify production files without explicit approval.
- Do not claim tests passed unless they were run.
For a personal assistant bot:
- Do not expose private data in group chats.
- Do not summarize sensitive information into shared channels.
- Do not store secrets or one-time personal details as memory.
These boundaries can be placed in SOUL.md, profile memory, gateway configuration, or tool permission settings depending on the type of rule. The important point is to decide them before the bot becomes part of daily use.
Troubleshooting common issues
If the gateway is configured but the bot does not respond, check the basics first:
- Is the gateway process running?
- Is the correct profile gateway running?
- Is the bot token correct?
- Is the user or chat authorized?
- Is the bot receiving messages from the platform?
- Is the message ignored because mention-only mode is enabled?
- Is another profile using the same token?
- Are there errors in the gateway logs?
If the bot works in private messages but not in a group, the issue is usually group delivery, bot privacy settings, permissions, authorization, or mention filters. Group bots often need explicit mentions, correct privacy settings, and sometimes admin permissions depending on the platform behavior.
If multiple bots are in one group, use explicit mentions and unique bot tokens. This makes routing deterministic and reduces the chance that the wrong profile responds.
Practical recommendation
For most users, the best setup order is:
- Get Hermes working in the CLI.
- Create one focused profile.
- Configure one messaging bot for that profile.
- Test private chat.
- Add group chat only if needed.
- Add scheduled outputs after the bot is stable.
- Add more profile-specific bots gradually.
This staged approach keeps the system easier to debug.
Messaging should not be treated as a replacement for good profile design. The bot is only an interface. The Hermes profile still controls the agent’s identity, memory, skills, tools, and behavior. A poorly configured profile will remain poorly configured even if it is reachable from Telegram.
Used carefully, messaging makes Hermes feel more like a persistent assistant than a local CLI tool. You can send tasks from your phone, receive scheduled outputs, route different roles to different bots, and interact with long-running workflows without opening a terminal every time.
16. Practical Workflow 1: Hermes as a Coding Assistant
A good first practical use case for Hermes is repository work. Coding tasks are a useful test for persistent agents because they combine several properties that ordinary chat assistants struggle with: local context, project conventions, repeated commands, tool use, verification, and memory.
A coding assistant should not only generate code. It should inspect the repository, understand the existing structure, identify relevant commands, make small changes, run checks where possible, and preserve stable knowledge for future tasks.
Hermes is well-suited to this pattern because it can combine a developer profile, persistent memory, reusable skills, file operations, terminal access, and session history. The goal is not to make the agent fully autonomous from the beginning. The goal is to create a controlled coding workflow where the agent gradually learns how a specific project works.
Start with a dedicated coding profile
The first step is to keep coding work inside a dedicated profile, such as:
hermes profile create coder --description "Repository work, debugging, tests, and technical documentation."If the profile already exists, use it directly:
hermes -p coder chatThe coding profile should have its own SOUL.md, memory, skills, and sessions. This prevents repository-specific details from mixing with research notes, writing preferences, or personal automation tasks.
A coding profile should be configured conservatively. It should prioritize inspection, small changes, verification, and explicit reporting. A simple SOUL.md for this profile might include:
# SOUL.md
You are a pragmatic software engineering assistant.
Priorities:
- Understand the existing code before editing.
- Prefer small, focused patches over broad rewrites.
- Identify the relevant test or validation command before changing code.
- Explain what changed and how it was verified.
- Do not claim a task is complete unless verification was run or clearly marked as not run.
Constraints:
- Do not run destructive commands unless explicitly approved.
- Do not edit generated files unless explicitly requested.
- Do not store secrets, tokens, or private credentials in memory.
- Ask for clarification when the task depends on missing project context.
Figure 45. Coding Profile Setup
This profile identity matters because coding agents can easily become too aggressive. If the agent assumes it should immediately edit files, refactor broad areas, or run expensive commands, the workflow becomes harder to control. The identity file should make the default behavior clear: inspect first, then act.
Run Hermes from the repository root
For coding tasks, start Hermes from the project directory whenever possible:
cd /path/to/project
hermes -p coder chatStarting from the repository root gives the agent a clear working directory. It also makes terminal commands and file paths easier to reason about.
A useful first prompt is not “fix everything.” It is a read-only inspection task:
Inspect this repository without modifying files.
Your task:
1. Identify the main language/framework.
2. Identify the package manager.
3. Find the main test command.
4. Summarize the top-level project structure.
5. Tell me what files or commands you inspected.
Do not edit files yet.This is a good first task because it establishes project context without introducing risk. The agent learns where things are, which commands matter, and what assumptions are safe to store later.
Figure 46. First Repository Inspection
The output from this first inspection should be treated as provisional until verified. If Hermes identifies a test command, ask it to confirm the command from project files such as package.json, pyproject.toml, Makefile, README.md, or CI configuration.
For example:
Verify the test command from project files before saving it as memory.
Show the file where the command is defined.This avoids storing guesses as long-term memory.
Save only stable project facts
After the repository inspection, save only the facts that are stable and useful.
Good coding memory entries include:
## Project memory
- This repository uses pnpm for package management.
- Main backend tests run with `pnpm test:api`.
- API route definitions are under `src/routes/`.
- Generated files under `dist/` should not be edited manually.Weak memory entries include:
- The project looks complicated.
- The current branch seems messy.
- The last bug might be related to middleware.The first set helps future execution. The second set creates noise.
A useful prompt after inspection is:
Save only the confirmed stable project facts as memory:
- package manager
- main test command
- generated-file rule
- important source directories
Do not save temporary observations, guesses, current branch details, or the current error.
Figure 47. Saving Stable Repository Facts
This is one of the main advantages of using Hermes as a coding assistant. Once the test command and project conventions are saved, future sessions do not need to rediscover them from scratch.
Use a safe task pattern
For coding work, use a consistent task pattern. A useful structure is:
- Inspect relevant files.
- Explain the likely change.
- Make the smallest safe edit.
- Run focused verification.
- Report what changed and what was verified.
- Save stable learning only if it will help future tasks.
This pattern keeps the agent from jumping directly into implementation before understanding the context.
A good coding task prompt might look like this:
Fix the failing validation test in this repository.
Workflow:
1. First inspect the relevant test and implementation files.
2. Reproduce the failure if possible.
3. Explain the likely cause before editing.
4. Apply the smallest safe fix.
5. Re-run the focused test.
6. Summarize the diff and verification result.
Do not run broad refactors.
Do not edit unrelated files.
Do not save anything to memory unless it is a stable project convention.This prompt is longer than a normal chat prompt, but it gives the agent the operational boundaries it needs.
Figure 48. Safe Coding Task Flow
For the first few coding tasks, avoid large requests such as:
Refactor the whole backend.
Improve the architecture.
Clean up this repository.
Make the code production-ready.These tasks are too broad. They usually require product context, architectural judgment, and human review. They are better handled as planning tasks first, not direct edit tasks.
A safer version is:
Inspect the backend structure and identify three small refactoring opportunities.
Do not edit files. For each opportunity, explain the risk, expected benefit,
and how it could be verified.This lets Hermes help with planning before making changes.
Turn repeated debugging into a skill
After Hermes completes a few similar debugging tasks, create a skill.
For example:
Create a skill for debugging backend API test failures in this repository.
The skill should include:
- when to use it
- relevant commands
- files to inspect first
- common failure categories
- what not to edit
- verification stepsA generated skill might look like this depending on your project:
---
name: debug-backend-api-tests
description: Use when debugging failing backend API tests in this repository.
version: 1.0.0
author: agent
---
## When to use
Use this skill when a backend API test fails locally or in CI.
## Procedure
1. Run the focused failing test first.
2. Read the full error output and stack trace.
3. Inspect the test file before editing implementation code.
4. Check route handlers, validation logic, fixtures, and dependency setup.
5. Apply the smallest safe fix.
6. Re-run the focused test.
7. Run the broader backend API test command before reporting completion.
## Pitfalls
- Do not edit generated files under `dist/`.
- Do not assume the test is wrong before checking the implementation.
- Do not update snapshots or fixtures unless the expected behavior changed intentionally.
## Verification
The focused test passes, and the broader backend API test command completes successfully.
Figure 50. Debugging Skill for a Repository
This is where Hermes becomes more than a one-off assistant. The debugging workflow becomes procedural memory. The next time a similar issue appears, the agent can start from a known process rather than reconstructing the workflow from the current prompt.
Use Hermes for documentation tasks
Documentation is another good coding workflow because it is useful, low risk, and easy to review.
A safe first documentation task:
Inspect the repository and improve the README setup section.
Constraints:
1. Do not change code.
2. Only update the README.
3. Keep the edit small.
4. Preserve the existing style.
5. Mention any commands you verified from project files.This kind of task is useful because it exercises repository inspection and file editing without touching production logic.
After Hermes completes the task, ask:
Summarize the documentation change.
List the files edited.
State whether any commands were verified from project files.
Do not save this task as memory unless it revealed a stable project convention.
Figure 51. Hermes Documentation Update
If documentation tasks repeat, create a documentation skill:
Create a skill for updating repository documentation.
Include:
- when to use it
- how to inspect existing docs
- how to preserve style
- how to verify commands before documenting them
- what not to changeA documentation skill can help the agent produce consistent README updates, API docs, changelogs, or setup instructions.
Use Hermes for code review
Another useful workflow is review rather than editing.
For example:
Review the current git diff.
Focus on:
1. correctness
2. edge cases
3. tests
4. unnecessary complexity
5. possible regressions
Do not modify files.
Return findings grouped by severity.
Include the file and line when possible.This is a strong workflow because it keeps the agent in an advisory role. It can inspect the diff, reason about risk, and produce a structured review without changing the repository.
Figure 52. Hermes Code Review Workflow
If this workflow becomes frequent, turn it into a skill:
Create a code review skill for this repository.
The skill should define:
- severity levels
- review categories
- when to request tests
- how to cite files and lines
- what kinds of comments to avoidA review skill can make the agent more consistent across pull requests.
Use verification as the boundary for completion
For coding agents, verification should be the boundary between “I made a change” and “the task is complete.”
A final response should include:
- Files changed
- Summary of the change
- Verification command run
- Result of verification
- Anything not verified
- Suggested next step, if needed
A good final response from Hermes should look like:
Changed:
- src/routes/users.ts
Summary:
- Added validation for missing email before creating a user.
Verification:
- Ran pnpm test:api -- users.test.ts
- Result: passed
Not verified:
- Full end-to-end suite was not run.
Next step:
- Run pnpm test:e2e if you want broader coverage.A weak final response would be:
Done. The issue should be fixed.This does not provide enough evidence.
The profile’s SOUL.md and coding skills should reinforce this reporting format. Over time, Hermes should learn that coding work is not complete until the result is inspectable and verification status is clear.
Use Git as the review boundary
When Hermes modifies files, use Git as the review layer.
Before asking the agent to edit:
git statusAfter the agent edits:
git diff
git statusThen ask Hermes:
Review your own diff.
Check for:
1. unrelated changes
2. unnecessary complexity
3. missing verification
4. files that should not have been edited
Do not modify files during this review.This creates a useful two-pass workflow: one pass for implementation, one pass for review.
For higher-risk repositories, create a separate branch or worktree before using the agent. Avoid letting a persistent coding agent make changes directly on an important branch without review.
What to save after a coding task
After a coding task, there are three possible outputs:
- Memory
- Skill
- Nothing persistent
Save to memory when the agent learns a stable fact:
The repository uses `pnpm test:api` for backend tests.Create or update a skill when the agent learns a repeatable procedure:
How to debug backend API test failures in this repository.Save nothing when the information is temporary:
This specific test failed today because of a local branch change.This distinction keeps the profile clean.
A useful closing prompt after a successful task is:
Review what you learned from this task.
Classify each item as:
1. memory
2. skill update
3. session-only detail
Only save items that are stable and reusable.
Do not save temporary errors, branch-specific observations, or guesses.
Figure 53. Coding Task Persistence Decision
Recommended first coding workflows
A practical sequence for using Hermes as a coding assistant is:
- Inspect repository structure without edits.
- Identify package manager and test commands.
- Save confirmed project facts as memory.
- Make one small documentation update.
- Review the generated diff.
- Debug one focused failing test.
- Create a debugging skill after the workflow repeats.
- Use code review mode on a small pull request or diff.
This sequence is deliberately conservative. It lets Hermes build useful context without immediately giving it broad autonomy.
Practical guidance
Hermes is most useful as a coding assistant when the workflow is explicit, narrow, and verifiable.
Good tasks:
Inspect this repository and identify the test commands.
Update the README setup section using commands verified from project files.
Debug this focused failing test and apply the smallest safe fix.
Review this git diff for correctness and missing tests.
Create a skill for the repeated debugging workflow we just used.Weak tasks:
Improve the whole codebase.
Refactor the architecture.
Make this production-ready.
Fix all bugs.
Clean everything up.The weak tasks are not impossible, but they are too broad for early agent use. They should be decomposed into inspection, planning, implementation, and verification steps.
The main value of Hermes in coding workflows is not that it writes code once. The value is that it can gradually learn how your project works: which commands matter, what files should not be touched, which workflows repeat, and how you expect changes to be verified.
A useful coding agent should become more project-aware over time, but still remain reviewable. Memory should hold stable facts. Skills should hold repeated procedures. Git should remain the review boundary. Tests should remain the verification boundary. Human approval should remain the boundary for high-risk changes.
17. Practical Workflow 2: Hermes as a Research Agent
A research agent is one of the most useful Hermes profiles to create after the coding assistant. Research work depends heavily on continuity: recurring topics, preferred sources, citation habits, evaluation criteria, and a consistent output format.
A normal chat assistant can summarize a paper or search for a topic once. A persistent research agent should do more than that. It should remember what kinds of sources you trust, how you want claims handled, which topics you track, and how research outputs should be structured.
The goal is not to let the agent browse randomly and produce generic summaries. The goal is to create a repeatable research workflow that is source-aware, structured, and reviewable.
For AI practitioners, this can be useful for:
- tracking new model releases
- summarizing research papers
- monitoring GitHub repositories
- comparing tools and frameworks
- following technical documentation changes
- preparing newsletter or blog research notes
- creating weekly research digests
A research profile is also lower risk than a coding profile in many cases. It may use web search, browser tools, files, memory, and skills, but it does not necessarily need broad write access to a codebase. This makes it a good profile for learning how Hermes handles persistent workflows without immediately introducing high-risk automation.
Create a dedicated researcher profile
Start by creating a separate profile:
hermes profile create researcher --description "Researches AI, ML, software tools, papers, and technical sources."If you already have a configured base profile and want to copy its model/provider setup, create the researcher profile from the current active profile:
hermes profile create researcher --clone --description "Researches AI, ML, software tools, papers, and technical sources."Or, if you want to clone from a specific profile:
hermes profile create researcher --clone-from default --description "Researches AI, ML, software tools, papers, and technical sources."After creating it, start a chat with the profile:
hermes -p researcher chat
Figure 54. Creating a Researcher Profile
The point of creating a separate profile is to isolate research-specific identity, memory, skills, sessions, and tools. The researcher should not inherit repository-specific debugging notes from the coding profile unless you intentionally add them.
Define the researcher identity in SOUL.md
The researcher profile needs a different identity from the coding profile.
A coding profile usually prioritizes small patches, tests, and verification. A research profile should prioritize source quality, citation discipline, uncertainty handling, and synthesis.
A practical SOUL.md for a research profile might look like this:
# SOUL.md
You are a careful technical research assistant for AI, machine learning,
software engineering, and developer tools.
Your priorities:
- Prefer primary sources: official docs, papers, release notes, GitHub repos,
technical blogs from authors, and standards documents.
- Separate confirmed facts from interpretation.
- Cite claims that depend on external sources.
- Do not present weak evidence as settled.
- Summarize what changed, why it matters, and what remains uncertain.
- Keep outputs concise, structured, and useful for technical readers.
When researching:
- Identify the source type before relying on it.
- Prefer recent sources for fast-moving topics.
- Cross-check important claims when possible.
- Flag when information may be incomplete, outdated, or based on limited evidence.
- Avoid copying long passages from sources.
Do not fabricate citations, dates, benchmark results, prices, or technical claims.
Figure 55. Researcher SOUL.md
This identity file should make the researcher more conservative than a general assistant. In research workflows, the main failure is not only getting an answer wrong. It is presenting weak or incomplete evidence with too much confidence.
Add research-specific memory
The researcher profile should start with a small amount of memory. Do not overload it with every topic you are interested in. Begin with stable preferences that should apply across research tasks.
A useful USER.md for a researcher profile might include:
# USER.md
- The user prefers technical, moderately formal explanations.
- The user dislikes vague promotional language and punchline-style phrasing.
- The user prefers source-grounded research with citations for factual claims.
- The user wants uncertainty clearly separated from confirmed facts.
- The user is interested in AI agents, LLM systems, RAG, model training,
agent memory, evaluation, and open-source AI tools.A useful MEMORY.md might include:
# MEMORY.md
## Research workflow memory
- Prefer primary sources over secondary summaries.
- For model releases, check official announcements, documentation, model cards,
GitHub repos, and papers when available.
- For benchmark claims, record the benchmark name, model version, date,
source, and any stated evaluation conditions.
- For pricing, API limits, or product availability, treat information as
time-sensitive and verify from official sources.
- For papers, summarize the problem, method, main results, limitations,
and practical relevance.
Figure 56. Researcher Memory Setup
Good research memory entries are stable and methodological:
Prefer papers and official docs over social media summaries.
For model-release claims, verify date, version, license, and source.
Separate confirmed results from author claims or community interpretation.Weak research memory entries are vague or temporary:
The user read a paper today.
This model seems interesting.
There was some drama on X about a benchmark.Those may belong in the current session, not long-term memory.
Configure the research workflow
A research agent should not be asked to “find everything.” That produces noisy output. It should be given a clear research scope, source policy, and output format.
A good first task is:
Research the latest Hermes Agent documentation and summarize the current
capabilities relevant to developers.
Scope:
1. Installation and setup.
2. Profiles.
3. Memory.
4. Skills.
5. Messaging.
6. Scheduled jobs.
Source policy:
- Prefer official Hermes documentation and GitHub sources.
- Do not rely on unsourced social posts.
- Cite each factual claim that depends on external sources.
Output format:
- Key findings
- Practical implications for developers
- Limitations or unclear areas
- Links/sources usedThis prompt gives the agent enough structure to avoid producing a generic overview.
Figure 57. Structured Research Prompt
A weaker prompt would be:
Tell me everything about Hermes Agent.This is too broad. It does not define source quality, depth, output structure, or what the user needs the research for.
A better research prompt usually includes:
- topic
- scope
- source requirements
- recency requirements
- output format
- what to exclude
Use a repeatable research output format
A research profile becomes much more useful when it returns outputs in a consistent format.
For example, for a model release:
## Summary
Short description of what was released.
## What changed
- Model/version:
- Release date:
- Provider/lab:
- License or access:
- Context length:
- Tooling/API changes:
- Notable benchmark or capability claims:
## Why it matters
Practical implications for developers and AI practitioners.
## Limitations and uncertainty
What is not confirmed, what needs testing, or what depends on vendor claims.
## Sources
Cited sources used in the answer.For a paper summary:
## Problem
What problem the paper is addressing.
## Method
The main technical idea.
## Results
Main reported findings and evaluation setup.
## Limitations
What the paper does not solve or what assumptions it makes.
## Practical relevance
Why developers or AI practitioners should care.
## Sources
Paper link and any related official resources.For a GitHub repository review:
## What the project does
Short technical description.
## Why it is relevant
What problem it solves and who might use it.
## Repository health
Stars, activity, issues, license, installation clarity, docs quality.
## Technical notes
Architecture, dependencies, supported platforms, APIs, limitations.
## Risks or open questions
Maintenance risk, unclear license, missing tests, security concerns.
## Sources
Repository and related docs.
Figure 58. Research Output Templates
Templates reduce repeated prompt setup. They also make it easier to compare outputs across sessions.
Turn repeated research into skills
If the researcher profile repeatedly performs the same type of work, create skills.
For example, after a few paper summaries, ask Hermes:
Create a skill for summarizing AI research papers.
The skill should include:
- when to use it
- source requirements
- required fields
- how to separate claims from interpretation
- how to handle missing information
- the final output formatA research-paper skill might include:
---
name: summarize-ai-paper
description: Use when summarizing AI, ML, or agent-systems research papers.
version: 1.0.0
author: agent
---
## When to use
Use this skill when the user asks for a structured summary of a technical paper.
## Procedure
1. Identify the paper title, authors, venue or preprint status, and date.
2. Read the abstract, introduction, method, experiments, and limitations.
3. Extract the problem, method, evaluation setup, main results, and limitations.
4. Separate reported claims from your own interpretation.
5. Avoid overstating benchmark results.
6. Include citations or links for the paper and any related official resources.
## Output format
- Problem
- Method
- Results
- Limitations
- Practical relevance
- Sources
## Pitfalls
- Do not summarize only from social posts.
- Do not treat author claims as independently verified results.
- Do not omit limitations.
Figure 59. Research Skill Example
Other useful research skills include:
- track-model-release
- review-github-ai-tool
- compare-two-frameworks
- summarize-technical-docs
- prepare-newsletter-research-notes
- extract-claims-from-paper
As with coding skills, do not create a large skill library before real workflows repeat. Let skills emerge from actual usage.
Use the researcher profile for paper workflows
A good paper workflow is not only summarization. It should identify what the paper claims, what evidence supports the claim, and what remains uncertain.
A practical prompt:
Summarize this paper for developers and AI practitioners.
Focus on:
1. The problem the paper addresses.
2. The core technical idea.
3. The evaluation setup.
4. The main reported results.
5. The limitations.
6. What this changes in practice.
Separate author claims from your own interpretation.
Do not overstate the result.If the paper has code or a project page, add:
Also check whether the authors provide code, model weights, datasets,
or reproducibility notes. Include the status in the summary.
Figure 59. Paper Research Workflow
This kind of workflow is useful for blog writing, newsletter research, and technical decision-making.
Use the researcher profile for release tracking
Model and tool releases are time-sensitive. A researcher profile should treat them differently from stable background knowledge.
A good release-tracking prompt:
Research this model release and prepare a technical brief.
Check:
1. Official announcement.
2. Documentation or model card.
3. GitHub repository, if available.
4. License or usage terms.
5. API or deployment details.
6. Benchmark claims and evaluation setup.
7. Practical implications for developers.
Do not rely only on social media summaries.
Flag anything that is unclear or not independently verified.A good output should include:
- what was released
- who released it
- release date
- access method
- technical specs
- claimed capabilities
- limitations or unclear areas
- developer relevance
- sources
Figure 60. Model Release Research Flow
This is one of the areas where persistence is useful. The agent can remember your preferred release-tracking template and reuse it later.
Use the researcher profile for tool comparison
Another useful workflow is comparing two tools or frameworks.
A good prompt:
Compare Tool A and Tool B for developers building production AI agents.
Compare:
1. Core purpose.
2. Architecture.
3. Setup complexity.
4. Supported integrations.
5. Memory/state handling.
6. Tool execution model.
7. Deployment options.
8. Strengths and limitations.
9. Best fit use cases.
Use primary sources where possible.
Return a balanced technical comparison, not a promotional summary.The output should avoid declaring a universal winner. Most tools are better or worse depending on constraints.
A useful comparison structure:
## Summary table
## Tool A: strengths and limitations
## Tool B: strengths and limitations
## Where Tool A fits better
## Where Tool B fits better
## Open questions
## Sources
Figure 61. Research Comparison Workflow
This kind of workflow is useful for practitioners who need to choose tools, write technical posts, or brief a team.
Save only reusable research preferences
After a research task, ask Hermes to classify what should persist.
For example:
Review what you learned from this research task.
Classify each item as:
1. user preference
2. reusable research workflow
3. topic-specific fact
4. session-only detail
Only save stable preferences or reusable workflows.
Do not save temporary news, guesses, or unverified claims as memory.Save as memory when the finding is a stable preference or method:
- For model releases, always check official announcement, docs, model card, license, and benchmark methodology when available.
Save as a skill when the workflow repeats:
- How to prepare a technical model-release brief.
Leave in the session when the detail is time-sensitive or one-off:
- This specific release was announced today.
- This benchmark claim is currently disputed.
- This GitHub repo had 4.2k stars at the time of checking.
Figure 62. Research Persistence Decision
This is important because research memory can become outdated quickly. Model prices, benchmark rankings, API limits, supported features, and licenses can change. Time-sensitive facts should usually be cited in the output rather than stored as durable memory.
Use sessions as research history
Hermes sessions are useful for research because not every detail is worth memorizing. A researcher profile may need to recover previous work:
Find the session where we compared agent frameworks last week.Or:
What sources did we use when summarizing the GEPA paper?This is where session search is more appropriate than compact memory. The agent can recover old context without injecting every past research task into the current prompt.
A useful pattern is:
- Memory: Stable research methods and user preferences.
- Skills: Repeatable research procedures.
- Sessions: Completed research tasks, source trails, and previous outputs.
Practical first research workflows
A good starting sequence for a Hermes researcher profile is:
- Create a researcher profile.
- Write a source-quality-focused SOUL.md.
- Add a small amount of research memory.
- Ask the agent to research one narrow topic.
- Require primary sources where possible.
- Use a structured output template.
- Save only reusable research preferences as memory.
- Turn repeated research formats into skills.
- Use session search to recover prior research when needed.
Figure 63. First Research Agent Workflow
This workflow keeps the researcher profile useful without making it noisy.
Practical guidance
Hermes works well as a research agent when the research task is narrow, source requirements are explicit, and the output format is defined.
Good research tasks:
Summarize this paper for AI practitioners using a fixed template.
Compare these two tools using official docs and GitHub sources.
Research this model release and separate confirmed facts from claims.
Prepare a technical brief on this new agent framework.
Track what changed in this project since the last release.Weak research tasks:
Tell me everything about this topic.
Find the best AI tool.
Summarize what people are saying.
What is the truth about this controversy?The weak tasks are too broad or underspecified. They can still be handled, but they should be rewritten into scoped research tasks with clear source requirements.
A useful researcher profile should become more consistent over time. It should remember how you want research handled, reuse templates for repeated outputs, and preserve source discipline. It should not become a place where every temporary news item or unverified claim is stored as long-term memory.
The main value of Hermes as a research agent is not only that it can gather information. It is that it can gradually standardize how research is performed: which sources to prefer, how to handle uncertainty, how to format outputs, and when a repeated research process should become a reusable skill.
18. Scheduling Work With Hermes Cron
So far, the workflows in this guide have been mostly interactive. The user sends a task, Hermes runs the task, and the result comes back in the same session. This is useful for coding, research, documentation, and profile-specific assistance.
Cron changes the operating model.
With scheduled jobs, Hermes can run tasks automatically at a specific time, on a recurring schedule, or after a delay. This is what moves Hermes from a reactive assistant into a workflow runner. Instead of manually asking for the same research brief every morning, the task can be scheduled once and delivered when it is due.
This is useful for workflows such as:
- daily AI research digest
- weekly repository health summary
- morning planning brief
- recurring content idea generation
- release monitoring
- dependency update checks
- paper tracking
- scheduled reminders
The important detail is that cron should be added only after the base Hermes setup is working. You should already have a working profile, a configured model/provider, and ideally a messaging gateway if you want results delivered to Telegram, Discord, Slack, or another platform.
What Hermes cron does
Hermes cron lets you define jobs that run automatically. A job usually contains:
- schedule
- task prompt
- profile context
- optional skills
- delivery target
- job state
The schedule controls when the job runs. The prompt tells Hermes what to do. The active profile controls the agent identity, memory, skills, tools, and configuration. The delivery target controls where the result should go.
A scheduled job can be one-shot or recurring.
A one-shot job runs once:
- in 30 minutes
- tomorrow at 9 am
- at a specific ISO timestamp
A recurring job runs repeatedly:
- every morning at 8 am
- every 2 hours
- 0 9 *
- 0 8 1–5
The cron expression format is useful when you want precise schedules. For example:
- 0 8 * → every day at 08:00
- 0 8 1–5 → every weekday at 08:00
- 0 18 5 → every Friday at 18:00
Figure 64. Hermes Cron Job Anatomy
Start with a manual workflow first
Before scheduling a task, run it manually. For example, if you want a daily AI research digest, first ask the researcher profile to produce one manually:
hermes -p researcher chatThen send a prompt like:
Create a concise technical briefing on AI agent and open-source LLM updates from the past 24 hours.
Requirements:
1. Prefer official announcements, papers, GitHub repositories, and primary sources.
2. Include 3 to 5 important updates.
3. For each update, include the source, what changed, and why it matters.
4. Separate confirmed facts from interpretation.
5. Keep the briefing concise and technical.Review the output. If the format is too broad, tighten the prompt. If it cites weak sources, improve the source policy. If it misses important fields, update the output structure.
Only schedule the task after the manual version works.
This avoids a common mistake: scheduling a vague task and then receiving vague output every day.
Figure 65. Manual First, Schedule Second
Create a scheduled job from chat
Hermes can create cron jobs from natural-language instructions in chat. For example, inside a researcher profile, you can say:
Every weekday at 8am, create a concise technical briefing on AI agents,
open-source LLMs, RAG, and agent memory.
Use official announcements, papers, GitHub repositories, and primary sources
where possible. Include 3 to 5 important updates. For each update, include:
1. What changed.
2. Why it matters for developers or AI practitioners.
3. Source link.
4. Any uncertainty or missing information.
Deliver the result to Telegram.This is convenient because the agent can use the cron job tool to create the schedule for you.
However, natural language scheduling should still be reviewed. After creating the job, list the jobs and check the next run time, delivery target, and prompt.
hermes -p researcher cron listIf the schedule is wrong, edit or recreate the job before relying on it.
Figure 66. The created scheduled job appears in the scheduled lists.
Create a scheduled job with /cron
For more explicit control, use the /cron slash command.
For example:
/cron add "0 8 * * 1-5" "Create a concise weekday technical briefing on AI agents, open-source LLMs, RAG, and agent memory.
Requirements:
- Prefer official announcements, papers, GitHub repositories, and primary sources.
- Include 3 to 5 important updates.
- For each update, include what changed, why it matters, the source, and any uncertainty.
- Keep the output concise and technical.
- Do not include weak social media claims unless they are clearly labeled as unverified.
Deliver to Telegram."This version makes the schedule explicit:
- 0 8 1–5: which means every weekday at 08:00.
Figure 67. Creating a Cron Job With /cron
A cron prompt should be self-contained. Do not write:
Do my usual research digest.That relies on implicit context. A scheduled job may run in a fresh session, so the prompt should contain enough instructions for the agent to complete the task without guessing.
A better prompt defines:
- topic
- time window
- source policy
- number of results
- output format
- delivery target
- what to exclude
Use profile-specific cron jobs
Cron should usually run inside a specific profile.
For example, a research digest should run under the researcher profile:
hermes -p researcher cron listA coding summary should run under the coder profile:
hermes -p coder cron listThis matters because the profile controls the identity, memory, skills, and tools available to the scheduled job. A researcher profile may have source-quality rules and research-summary skills. A coder profile may have repository memory and debugging skills. A personal assistant profile may have reminder or planning preferences.
A practical mapping looks like this:
- researcher profile → daily research digest
- coder profile → weekly repository health summary
- assistant profile → morning planning brief
- designer profile → weekly diagram idea generation
Figure 68. Profile-Specific Scheduled Jobs
Scheduling a job in the wrong profile can produce inconsistent output. For example, a research digest created under the coding profile may inherit coding-specific memory or skills that are not relevant.
Deliver outputs to messaging
Scheduled jobs are much more useful when they are delivered somewhere you already check.
If you are using Telegram, first make sure the gateway is configured and running:
hermes -p researcher gateway startThen, in the Telegram chat where you want outputs to arrive, send:
/sethomeThis marks the current chat as the home channel for that profile. After that, scheduled outputs can be delivered there, depending on your job configuration.
If a job runs but nothing arrives in Telegram, check the delivery target, gateway status, bot token, and chat permissions before changing the research prompt.
The gateway must be running
A normal CLI chat session does not automatically fire scheduled jobs. If you expect jobs to run automatically, the Hermes gateway or scheduler process must be running.
For foreground testing:
hermes -p researcher gatewayFor a background service:
hermes -p researcher gateway startCheck status with:
hermes -p researcher gateway statusIf a job is not firing, start with:
hermes -p researcher cron listCheck whether the job is active, paused, completed, or misconfigured. Also compare the next run time with your local system time.
Figure 69. Cron Troubleshooting Checklist
Attach skills to scheduled jobs
Some scheduled jobs should load a specific skill.
For example, if you created a skill called:
model-release-briefYou may want a model-release monitoring job to use that skill whenever it runs.
The purpose of attaching a skill is to make the recurring workflow more consistent. Instead of putting the entire process into a long prompt every time, the cron job can load the relevant procedure.
A useful pattern is:
short cron prompt + attached skill + profile memory = consistent recurring output
For example:
/cron add "0 8 * * 1-5" "Prepare a weekday model-release brief for AI practitioners. Use the model-release-brief skill. Focus on official releases and major open-source updates from the past 24 hours. Deliver to Telegram."Even when using skills, keep the prompt self-contained enough to define the topic, time window, and delivery target. Skills should provide the procedure. The cron prompt should still define the specific task.
Use [SILENT] for monitoring jobs
Not every scheduled job should produce output every time. For monitoring tasks, it is often better to send a message only when something changed. Hermes supports a quiet pattern where the job can suppress delivery by returning a special silent marker.
A monitoring prompt can be written like this:
Check whether the target repository has a new release since the last run.
If there is a meaningful new release, summarize:
1. Version.
2. Release date.
3. Important changes.
4. Source link.
If there is no meaningful change, respond with only:
[SILENT]This prevents daily “nothing happened” messages.
Use this carefully. If the prompt accidentally includes [SILENT] in a longer explanation, delivery may be suppressed. Keep the instruction clear.
Figure 70. Monitoring Job With Silent Output
Use script-only jobs when no LLM is needed
Some scheduled jobs do not need an agent to reason. They only need a script to run on a schedule and deliver the output.
For example:
- check disk usage
- query a fixed API endpoint
- generate a static report
- run a local health check
- watch a file or folder
For these cases, Hermes can run script-only cron jobs without involving the LLM. This is useful when the task is deterministic, and the script output is already the final result.
A script-only job follows this pattern:
schedule → run script → stdout delivered to messaging platform → no model call
Figure 71. Script-Only Cron Job
This is often better than asking an LLM to do deterministic work. If the task can be solved with a small script, keep it as a script.
Practical cron examples
A useful researcher cron job:
/cron add "0 8 * * 1-5" "Create a weekday AI research briefing for developers and AI practitioners.
Scope:
- AI agents
- open-source LLMs
- RAG
- agent memory
- model evaluation
Source policy:
- Prefer official announcements, papers, GitHub repos, and documentation.
- Include source links.
- Avoid unverified social media claims unless clearly labeled.
Output:
- 3 to 5 important updates
- what changed
- why it matters
- uncertainty or missing information
Deliver to Telegram."
A useful coder cron job:
/cron add "0 17 * * 5" "Create a weekly repository health summary.Inspect the current repository and summarize:
1. Recent commits.
2. Test status if available.
3. Open TODO or FIXME comments.
4. Documentation areas that may need updates.
5. Risky or unclear changes.
Do not modify files.
Return a concise report with suggested next actions."
A useful content workflow:
/cron add "0 10 * * 1" "Generate 5 technical blog ideas based on recent AI agent and LLM infrastructure developments.For each idea include:
1. Working title.
2. One-sentence angle.
3. Why developers should care.
4. Suggested diagram.
5. Source direction to investigate.
Do not draft full posts."
These prompts are specific enough to produce useful scheduled outputs without relying on the agent to infer too much.
Avoid unsafe scheduled jobs
Scheduled jobs should be lower risk than interactive tasks. If a job can modify files, call external APIs, send messages, or trigger deployments, it needs stronger constraints.
Avoid scheduling tasks like:
- Automatically fix production bugs.
- Deploy changes every Friday.
- Refactor the repository every night.
- Send emails to customers without review.
- Delete unused files.
These tasks are risky because they can cause external side effects without human inspection.
Safer scheduled jobs include:
- summarize
- monitor
- report
- draft
- suggest
- compare
- flag changes
A good rule is:
Scheduled jobs should produce reviewable outputs before they produce irreversible actions.
If a job needs to write files, change infrastructure, or contact people, consider requiring approval or keeping it as an interactive task.
Figure 71. Safe vs Risky Scheduled Jobs
Check logs and job state
Cron jobs can fail for practical reasons: wrong schedule, paused job, gateway not running, missing delivery target, invalid token, missing skill, permission issue, or timeout.
Useful commands include:
hermes -p researcher cron list
hermes -p researcher cron run <job_id>
hermes -p researcher cron edit <job_id>
hermes -p researcher logs
hermes -p researcher skills listUse cron list to check job state and next run time. Use cron run to test a job manually. Use logs when the job runs, but the output does not arrive.
Also check the local timezone:
date
hermes -p researcher cron listIf your machine's time zone is not what you expect, jobs may run at the wrong local time.
Practical recommendation
A good order for adopting Hermes cron is:
- Run the workflow manually.
- Tighten the prompt.
- Create a dedicated profile for the workflow.
- Configure messaging delivery if needed.
- Schedule one low-risk job.
- Check cron list and gateway status.
- Review the first few outputs manually.
- Add skills only after the workflow repeats.
- Use monitoring and [SILENT] only when appropriate.
- Avoid write actions until the system is reliable.
Figure 72. Safe Hermes Cron Adoption Path
Cron is one of the features that makes Hermes feel like a persistent agent system rather than a chat tool. It allows a profile to keep working on recurring tasks, deliver outputs to messaging platforms, and reuse memory and skills over time.
The key is to schedule the right kind of work. Cron is best for structured, repeatable, low-risk tasks where the output can be reviewed. It is not the right starting point for high-risk automation or vague goals.
Used carefully, scheduled jobs can turn Hermes into a practical workflow runner for research, monitoring, reporting, and recurring summaries.
19. Best Practices, Limits, and When Hermes Makes Sense
Hermes is useful when it is treated as a persistent agent system, not as a normal chatbot with extra commands. Its main value comes from combining identity, memory, skills, profiles, tools, messaging, and scheduled jobs into one workflow. That also means it needs more care than a simple prompt-response tool.
The best way to start is narrow.
Create one focused profile first. Give it a clear SOUL.md, a small amount of memory, and one practical workflow. For example, start with a coder profile for repository inspection and small documentation updates, or a researcher profile for source-grounded technical summaries. Do not begin by creating ten profiles, dozens of skills, and scheduled jobs at the same time.
A focused profile is easier to debug. If the agent behaves poorly, you can inspect its identity file, memory, skills, tools, and recent sessions without searching through unrelated state. Once one profile works reliably, you can add more specialized profiles.
Memory should also stay small and high-signal. Use memory for stable facts that should influence future work: user preferences, project conventions, test commands, source policies, and repeated constraints. Do not use memory as a session transcript. Temporary errors, current branch details, one-off guesses, and time-sensitive research findings should stay in the session or final cited output.
A useful rule is:
- Memory → stable facts
- Skills → repeatable procedures
- Sessions → temporary context and past work
Skills should be created only when a workflow repeats. A skill is most useful when it captures an actual process the agent has already performed: debugging backend tests, reviewing a pull request, summarizing an AI paper, or preparing a model-release brief. A skill should include activation conditions, steps, common pitfalls, and verification criteria.
Generated skills should be reviewed before they are trusted. A bad skill can make the agent repeat a bad workflow. If a skill contains an outdated command, weak source policy, or unsafe assumption, the problem may reappear in future tasks. This is why the Curator matters: persistent systems need cleanup, not only accumulation.
Profiles are useful for separation, but they are not a security boundary by themselves. A profile can separate identity, memory, skills, sessions, config, and gateway state. It does not automatically sandbox filesystem access, commands, network access, or external side effects. If the agent has terminal access under your user account, it may still access what that account can access unless you add a real sandbox, restricted user, container, or permission boundary.
This distinction matters especially for coding and automation workflows.
For coding, keep Git as the review boundary and tests as the verification boundary. Let Hermes inspect repositories, propose small changes, update documentation, review diffs, and debug focused failures. Avoid giving broad instructions like “clean up the whole codebase” or “make this production-ready” without breaking them into inspection, planning, implementation, and review steps.
For research, keep source quality as the boundary. A research profile should prefer primary sources, official docs, papers, model cards, release notes, and GitHub repositories. It should separate confirmed facts from interpretation and avoid storing time-sensitive claims as durable memory. Research memory should capture method and preference, not every news item.
For cron and scheduled jobs, start with low-risk outputs. Good first jobs summarize, monitor, report, draft, or flag changes. Riskier jobs deploy, delete, modify production systems, send external messages, or call APIs with side effects. Those should require review and stronger controls.
Figure 73. Hermes Agent Operating Checklist
Hermes fits best when the workflow repeats and context matters. Good use cases include repository assistance, technical research monitoring, documentation, content pipelines, recurring briefings, personal automation, and specialized profile-based assistants. In these cases, persistence provides value because the agent can remember stable context and reuse procedures.
Hermes is less useful for one-off questions, vague goals, or tasks where persistence adds no value. If the task can be answered in one prompt and does not need memory, skills, tools, or scheduled execution, a normal chat assistant may be simpler. Hermes is also a poor fit for high-risk automation where no one can inspect memory, skills, tools, or scheduled jobs.
The main limitation is that self-improvement is not the same as correctness. Hermes can remember the wrong thing, create a weak skill, follow outdated instructions, or run a scheduled job with an underspecified prompt. Persistence makes the system more capable, but it also makes mistakes more durable if they are not reviewed.
This is why Hermes should be used as an inspectable agent environment. Its useful artifacts are readable: SOUL.md, memory files, skills, sessions, config, logs, and cron jobs. Developers should inspect and maintain these artifacts the same way they would inspect scripts, configuration, or operational playbooks.
The broader lesson is that practical agents are moving beyond isolated chat sessions. A useful agent needs identity, persistent context, reusable procedures, tool access, and scheduled execution. Hermes brings these pieces together in an open-source framework that developers can inspect, modify, and run across different workflows.
The result is not a fully autonomous replacement for human judgment. It is a system for making repeated work more structured. Used carefully, Hermes can reduce repeated context setup, standardize recurring workflows, and make an agent more useful over time without hiding all adaptation inside the model.
Want to build this step by step?
The full **Hermes Agent 101 course includes a 3-hour recording, a 150-page guide**, and practical workflows for persistent agents, memory, skills, profiles, Telegram, coding, research, and cron automation.
메타데이터
- post_id
- a14d5537c8f3
- slug
- hermes-agent-101-a-practical-guide-to-persistent-and-self-improving-agents-a14d5537c8f3
- url
- https://levelup.gitconnected.com/hermes-agent-101-a-practical-guide-to-persistent-and-self-improving-agents-a14d5537c8f3
- canonical_url
- https://levelup.gitconnected.com/hermes-agent-101-a-practical-guide-to-persistent-and-self-improving-agents-a14d5537c8f3
- author_url
- https://medium.com/@yousefhosni
- status
- ok
- fetched_at
- 2026-07-08 20:12:56
