August 23, 2026

Hermes and Building Agents That Work Autonomously

Notes from using Hermes Agent: how the agent loop works with toolsets, skills, and persistent memory, systemd deployment, plus honest strengths and limitations for a single homelab machine.

Most AI chatbots stop at an answer. Real work — writing scripts, moving files, running commands, watching services — needs execution, not text. Hermes Agent by Nous Research is built for that: an agent that carries out multi-step technical tasks on local infrastructure, with terminal, filesystem, and browser access.

Why an Agent That Works on Its Own

Homelab chores are repetitive by nature: backups, monitoring, updates, research, writing reports. The classic answer is cron scripts plus manual notes — both fragile and easy to forget. Hermes sits one layer above that: you give it a high-level instruction — “collect these research findings and write a summary” — and it breaks the task into steps, picks the right tool, executes, and reports back. What separates it from an ordinary chatbot: tools that actually run, and procedural memory that makes execution repeatable.

How It Works: Agent Loop, Tools, Memory

The core is an agent loop. Each session builds a system prompt and iterates: the model is called with available tools; a requested tool call runs and its result returns to the model; iteration continues until a final answer. Context approaching the token limit is compressed automatically so long sessions keep working. On top sit mechanisms that make it useful for long-running work:

  • Built-in toolsets: terminal, file operations, web search and browser, vision, Python execution, subagent delegation, memory, and cron. Toolsets can be toggled per platform, so the attack surface can be narrowed.
  • Skills (SKILL.md): step-by-step procedures stored as files and loaded into future sessions. When it solves a hard problem or gets corrected, that knowledge is persisted, and the agent gets better at the same tasks over time.
  • Persistent memory: facts about the environment, preferences, and lessons learned are stored across sessions, so context is not rebuilt from scratch every time.
  • Delegation: isolated subagents for parallel work via delegate_task, without flooding the main session’s context.
  • Cron and gateway: recurring schedules (including no-agent script-only watchdog jobs), plus messaging platforms such as Telegram and Discord — one agent, many surfaces.
  • Profiles: independent instances with separate config, sessions, skills, and memory, handy for separating work roles.

Setup & Systemd Supervision

Hermes installs with the official bootstrap script into ~/.hermes:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Initial configuration goes through hermes setup; model and provider selection through hermes model. Hermes is not locked to one vendor: OpenRouter, Anthropic, OpenAI, DeepSeek, and local models are supported, and the model swaps without changing anything else.

To keep the Web Dashboard running continuously on port 9119, create a user systemd service at ~/.config/systemd/user/hermes-dashboard.service. %h in ExecStart resolves to the user’s home directory:

[Unit]
Description=Hermes Agent Web Dashboard
After=network.target

[Service]
ExecStart=%h/.hermes/hermes-agent/venv/bin/hermes dashboard --no-open
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

Enable and start the service:

systemctl --user enable --now hermes-dashboard.service

Dashboard access should be limited to a private network (for example Tailscale), because the interface controls an agent with full host access.

Strengths I Rely On

  • Real execution, not advice: commands run, files get edited, and every tool result comes back as evidence, so work completes in one flow.
  • Learning through skills: once a procedure is proven, it is stored; recurring tasks do not need to be re-explained from scratch.
  • Cross-session context: persistent memory plus searchable session history, so interrupted work resumes without losing context.
  • Provider flexibility: switching models for heavy or cheap tasks touches nothing else.
  • One agent, many surfaces: CLI, messaging, cron schedules, and parallel subagents are managed from the same instance.

Limitations

  • Real token cost: an agent burns far more tokens than a single-answer chatbot — every step calls the model. Daily usage needs monitoring, especially on paid APIs.
  • Tool access means host access: destructive commands are gated behind confirmations, but the agent ultimately runs with full permissions. Irreversible operations still need manual review.
  • Quality follows the model: step planning is only as good as the model behind it. For critical tasks, the model choice is a real decision, not a detail.
  • Context limits: long sessions depend on compression, and compressed context can lose small details that matter.
  • Not a replacement for a human reviewer: for irreversible decisions or tasks beyond tool reach, the human still decides.

Conclusion

On a single homelab machine with personal use, Hermes helps because its core difference is real: execution rather than answers, plus procedural memory that compounds. But it is not a substitute for operational discipline — it still needs a deliberately chosen model, a token budget, and review of risky actions. If the script-and-cron foundation already exists, Hermes is the layer that makes it easier to direct and monitor.

References