Module 1: Foundations

What Is HermesAgent

Learning objectives

  • Explain the core mental model behind What Is HermesAgent
  • Apply What Is HermesAgent within Foundations
  • Identify important boundaries, trade-offs, and failure modes
  • Produce concrete evidence from the practice exercise
Framework-agnostic design reference from the vault

Related: Hermes Why It Exists | Hermes Core Concepts | Hermes Architecture Overview | Hermes vs Other Frameworks | Hermes Index


A Working Definition

HermesAgent is an agent framework: a runtime that wraps an LLM with structure — tool use, memory, planning, state, and a loop — so the model can act on the world rather than just answer a single message.

A precise one-line definition:

Hermes is a system that turns an LLM from a one-shot text predictor into a goal-driven, tool-using process.

That definition has four operative words. Take them one at a time.

System. Not a function. A function takes input and returns output. A system has internal state, a loop, components, and lifecycle. Hermes has all of those.

LLM. The model is the reasoning engine but not the whole system. Hermes is model-agnostic — you can swap GPT-4 for Claude for a local Llama and the rest of the architecture is unchanged. See Hermes LLM Configuration.

Goal-driven. Plain chat is utterance-driven: user says X, model says Y, conversation ends. Hermes accepts a goal ("summarize this directory and write a report") and works on it across multiple model calls until the goal is met or it gives up.

Tool-using. The agent does not only emit text. It can read files, call APIs, run code, search the web, query a database. The model's job is to decide which tool to use; the runtime's job is to execute the tool safely and feed the result back. See Hermes Tools Overview.


Hermes vs Generic LLM Usage

A direct LLM call:

response = llm.complete("Summarize this article: ...")
print(response)

A Hermes agent:

agent = Hermes(
    model="gpt-4",
    tools=[fetch_url, save_file, search_memory],
    memory=VectorMemory("./mem"),
)
result = agent.run("Find the top 5 papers on agent planning published in 2025, "
                   "summarize each, and save the report to reports/agent-planning.md")

The second example does not just get a longer prompt. It runs a loop: the model thinks, calls fetch_url, observes the HTML, calls search_memory, decides it has enough, calls save_file, returns. That loop is the fundamental difference.


Hermes vs Other Agent Frameworks

A short comparison; the deep version is in Hermes vs Other Frameworks.

FrameworkCenter of gravityMental model
Direct API callsThe prompt"I am calling a function"
LangChainComposable chains"I am building a graph of LLM-shaped nodes"
CrewAIRoles"I am hiring specialists"
OpenClawGateway + channels"I am running a small inbox/agent service"
HermesThe agent runtime"I am running a process that owns a loop, tools, memory, and a model"

Hermes is closer in spirit to OpenClaw than to LangChain — it cares about the runtime, not the chain DSL. But it differs in that Hermes is agent-first, not gateway-first: the unit of design is the agent, not the channel.


Philosophy

Three values run through the framework. They show up again and again in the design notes.

Autonomy

The agent decides what to do next. The framework does not force a fixed graph or a single tool call. If the agent thinks the right next step is "read the file again, then ask the user a clarifying question," it can. The cost is unpredictability; the gain is generality.

Modularity

Every part is replaceable. Model, memory backend, tool set, planner — none of them are baked in. This is engineering hygiene: when one part of the stack improves (a new model, a faster vector DB), you swap it without rewriting the agent. See Hermes Architecture Overview.

Tool-Driven Intelligence

The model is the brain; the tools are the hands. The framework treats tools as first-class citizens — every tool has a schema, a description, error handling, and a contract. An agent without tools is a chatbot. An agent with tools is software that does things. See Hermes Tools Overview.


What HermesAgent Is Not

Avoiding misconceptions matters, because the word "agent" is overloaded.

  • Not a chatbot. Chatbots are interaction-oriented; agents are goal-oriented. Hermes can power a chat interface, but its primitive is "achieve goal," not "respond to message."
  • Not a workflow engine. Workflow engines (Airflow, Temporal) execute a fixed DAG. Hermes builds the path at runtime by reasoning. They can be combined — see Hermes Hybrid Architectures.
  • Not a vector DB wrapper. Memory is one of several components; the framework still works without one.
  • Not a single model's SDK. Hermes is provider-agnostic. The model is a parameter.
  • Not magic. Every step is an LLM call plus deterministic Python. If you understand both, you understand the whole agent.

A One-Sentence Mental Model to Carry Forward

A Hermes agent is a while not done: observe → think → act → record loop, where the thinking is delegated to an LLM and the acting is delegated to tools.

Everything else — memory, planners, multi-agent, guardrails — is a refinement of that loop. Keep it pinned for the rest of the course.

See Hermes Execution Loop for the deep dive.


Related

  • Hermes Why It Exists — the problems that motivate the framework
  • Hermes Core Concepts — the vocabulary used everywhere else
  • Hermes Architecture Overview — the block diagram of the runtime
  • Hermes vs Other Frameworks — how Hermes compares with peers
  • Hermes Index — full topic map

Practice lab

Implement the smallest runnable agent workflow that demonstrates What Is HermesAgent. Trace inputs, state, model and tool calls, outputs, and cost; inject one failure and add a regression test that prevents it from returning.

Review questions

  1. What problem does What Is HermesAgent solve, and what assumptions does it rely on?
  2. Which boundary or failure case is easiest to miss, and how would you expose it?
  3. What alternative design would you consider, and what trade-off would change the decision?
  4. What artifact, trace, test, or metric proves that your implementation is correct?

Completion evidence

  • A working artifact, annotated trace, or reproducible experiment
  • At least one normal case and one deliberately failing or boundary case
  • A concise explanation of the design choice and its trade-offs
  • Saved output showing how correctness was evaluated