watch · learn · build

Hermes Agent Masterclass

Ten modules that take Hermes from a fresh install to a hardened multi-agent team. Watch Tonbi build the whole system, then open our transcript-derived field notes for the decisions, shortcuts, and gotchas worth remembering.

10 modules 5h 14m beginner → advanced

module 01 · start here

Installation, setup & basic commands

watch on YouTube ↗

Here's what you need to know

the short version

Get one clean chat working before you add complexity. Pick a provider, learn the few commands that keep you oriented, and give Hermes a concrete first task whose result you can verify.

02:12The payoff compounds. Hermes is most useful when repeated sessions build memory and reusable skills. If all you need is an occasional chatbot, the extra machinery may not earn its keep.
06:48Stabilize the base provider first. Choose a model you can reliably call, then add fallback credentials or routing. Do not debug gateways, tools, and provider auth at the same time.
13:08Memorize the operator basics. hermes starts chat; hermes gateway starts messaging; hermes doctor checks the install; hermes model reopens model configuration.
16:43You can steer without restarting. Switch models in-session with /model, compact a long context with /compress, and use background or queued prompts when you do not want to derail the active task.
19:40Know where state lives. The .hermes directory holds config, environment, memories, sessions, cron, and logs. Tonbi's rule: edit config and memory deliberately; let Hermes manage session and cron internals.
21:26Test with real work. A bounded research task proves web search, tool calling, and synthesis in one go—and exposes a broken setup faster than a casual “hello.”

module 02 · run it anywhere

VPS, Docker & messaging

watch on YouTube ↗

Here's what you need to know

the short version

Choose a backend by the blast radius and uptime you need: local for simplicity, Docker for containment, VPS for always-on access. One gateway can then expose the same agent through many messaging apps.

01:06Backend is an operating decision. Local is easiest, Docker keeps command execution off the host, and a VPS keeps Hermes awake when your laptop is closed.
03:13Persistence and isolation are separate. Configure the Docker backend so the sandbox keeps the files it needs between turns without handing it your whole host filesystem.
09:37Make an always-on host survive logout. Use SSH key authentication and install the gateway as a supervised service; enable linger when needed so the user service stays alive after SSH disconnects.
14:53The gateway is one room with many doors. Telegram, Discord, and the CLI can feed the same agent, memory, sessions, and skills. You do not need a separate Hermes install per channel.
15:55Treat bot tokens like passwords. Create the Telegram bot through BotFather, restrict who may talk to it, and never paste the token into prompts or public config.
17:40Discord's easy-to-miss step is intents. Enable the required message-content intents in the developer portal; skipping them produces a bot that connects but receives empty messages.

module 03 · make context compound

Memory, Honcho & Obsidian

watch on YouTube ↗

Here's what you need to know

the short version

Hermes memory is intentionally layered. Keep the tiny built-in files curated, search old sessions only when needed, add one provider for richer recall, and use an Obsidian vault for project-scale knowledge.

01:30The small cap is a feature. memory.md and user.md share a tightly bounded prompt budget, forcing Hermes to retain durable preferences, facts, corrections, and conventions instead of a junk drawer.
06:00Memory writes appear next session. Disk updates immediately, but the system prompt stays frozen for the current session so prompt caching remains useful. A same-session test can therefore look “forgotten” even when the write succeeded.
12:00Session search is the deep archive. FTS5 lets Hermes retrieve an old conversation on demand without paying to keep every session in the active prompt.
15:00Run one provider at a time. Honcho, Mem0, Hindsight, and SuperMemory augment the built-in layer; switching providers does not migrate the memory you accumulated in the previous one.
21:00Provider choice is about memory shape. Honcho emphasizes a modeled understanding of the user; other providers lean toward extraction, knowledge graphs, or partitioned containers. Pick the behavior you actually need.
26:00Obsidian is a skill, not a provider. Use it for structured, long-form project knowledge that would overwhelm the built-in cap. Point the skill at a vault path and let Hermes create linked Markdown files.

module 04 · procedural memory

Skills that grow with the agent

watch on YouTube ↗

Here's what you need to know

the short version

A skill is a reusable instruction package. The description gets it selected, the body teaches the procedure, and the Curator keeps custom skills from turning into an unmaintained pile.

02:00SKILL.md is the unit. Front matter names and describes the skill; the body contains the workflow. References, scripts, templates, and assets are optional supporting material.
04:00The description is the picker hint. Hermes sees names and descriptions before it reads a body. A vague description means the right skill may never load, no matter how good its instructions are.
05:30Progressive disclosure keeps context lean. Hermes can carry a large catalog because only the selected skill body enters the prompt; everything else stays on disk.
23:00Install narrowly and inspect sources. Prefer bundled or trusted hub skills, let the security scan run, and use /reload skills to pick up changes without restarting the whole agent.
25:30Agent-written skills are procedural memory. When a complex tool sequence works, capturing it as a skill makes the next run faster and more consistent than rediscovering the steps.
31:00Pin what must not drift. The Curator grades and consolidates custom skills; pin a business-critical workflow so automated housekeeping cannot rewrite or archive it.
39:00Know skill versus plugin. If you are teaching knowledge or a repeatable procedure, use a skill. If you are adding executable product surface, backend routes, or UI, build a plugin.

module 05 · spend intelligence wisely

Providers, models & local inference

watch on YouTube ↗

Here's what you need to know

the short version

Use an expensive model where judgment matters and cheaper models everywhere else. Hermes separates providers, credentials, fallbacks, and auxiliary tasks so cost control does not require giving up a strong primary agent.

01:12Provider and model are different decisions. The provider controls authentication, billing, and transport; the model controls capability, context, and price.
05:21Tier the work. Put routine title generation, session search, compression, and other auxiliary jobs on inexpensive models. Keep a better default or specialist model for tasks where mistakes cost more.
10:16Credential pools are resilience, not just billing. Rotate keys when one hits a rate limit; cron jobs and subagents inherit the pool automatically.
12:25Manual switching stays useful. Hermes does not offer arbitrary per-skill or complexity-based routing. Use /model mid-session when you know the next phase deserves a different model.
13:38Local tool calling needs the right server flags. In Tonbi's llama.cpp setup, quantized KV cache and flash attention make the model fit; the Jinja chat template is the easy-to-miss requirement for tools.
17:32Ollama's context default can break agents. Set a sufficiently large context length before blaming Hermes for truncated plans or failed tool loops.
20:04Hermes Proxy makes subscriptions reusable. It exposes a local OpenAI-compatible endpoint backed by your configured OAuth provider, so compatible tools can share that access without receiving the real credential.

module 06 · give the model hands

Tools & MCP servers

watch on YouTube ↗

Here's what you need to know

the short version

The model requests; Hermes executes. Keep that boundary explicit, expose only the tools a task needs, and treat every MCP server as new code entering the agent's trust surface.

03:04A tool has three pieces. The function does the work, the schema tells the model when and how to call it, and the registry makes it available. The model never executes the function directly.
04:00Design the failure shape. Return a clean, structured error so the model can recover, choose another tool, or ask for missing input instead of crashing the whole turn.
05:01Prefer structured tools over shell improvisation. Purpose-built file, search, and patch tools are easier to audit and give the model a clearer recovery path than a chain of opaque shell commands.
06:56Scope and sandbox answer different questions. Tool sets decide what the agent can reach; local, Docker, or SSH backends decide where execution happens.
10:00Use the safe set for untrusted work. Read-only research and media tools without file writes or shell access are a better default for public-facing or research-only agents.
12:12Do not connect every MCP tool. Add the right server, filter it to the smallest useful surface, prefer OAuth to copied long-lived tokens, and let package scanning inspect local launchers.
21:28Build a native tool for repeated, stable capability. A small API-backed function with a precise schema is a good fit when the agent should recognize and call the same operation automatically.

module 07 · remove yourself from the loop

Cron & automation

watch on YouTube ↗

Here's what you need to know

the short version

A good cron job is a self-contained runbook, not a reminder to an agent that remembers yesterday. Use scripts for free polling, wake the model only when judgment is needed, and pass upstream output directly into downstream jobs.

02:19Cron lives in the gateway. The always-on gateway checks the schedule and creates a fresh, isolated session for each run.
06:21Runaway self-scheduling is blocked. A cron execution cannot create more cron jobs, preventing a job-spawns-job loop from multiplying unnoticed.
09:10Use silent for healthy states. Monitoring jobs can suppress routine “all good” deliveries while failures still surface.
11:18Fresh sessions know nothing about “that issue.” Include the host, path, command, expected state, delivery target, and success/failure behavior in the job prompt.
12:39no_agent is the zero-model path. If a deterministic script can collect or check the state, let it run alone rather than spending tokens on narration.
14:50Put a cheap gate before expensive judgment. A pre-run script can return “wake agent: false” until something changes, then hand the changed state to the model for triage.
25:30context-from is enough for many pipelines. Feed the latest completed output of one or several jobs directly into the next prompt; this removes file-path bookkeeping and extra tool calls.

module 08 · parallelize the right work

Subagents & delegation

watch on YouTube ↗

Here's what you need to know

the short version

Delegate independent, messy work that benefits from a clean context or parallel execution. Brief each child like a stranger, keep its tools narrow, and reserve the stronger model for orchestration and final judgment.

02:21Delegation solves context poisoning and serial slowness. Tool traces and false starts stay in the child's clean room; only the final summary returns to the parent.
09:07Subagents know nothing. “Fix the error” is not a brief. Include the exact failure, files, project root, environment, constraints, and definition of done.
10:00Give each child the least surface it needs. Research may need only web; review may need only read access. Children cannot exceed the parent's tools and leaf children are blocked from sensitive shared operations by default.
11:12Use cheap children and a strong parent. Route token-heavy collection to one inexpensive delegation model, then let the primary model synthesize short summaries.
13:30Concurrency is bounded. The default batch is three; larger batches error rather than silently queueing. If the parent is interrupted, synchronous children are canceled too.
20:47Depth multiplies spend. Children cannot recurse by default. Orchestrator roles and higher spawn depth are opt-in because three branches across three levels can become 27 leaves.
22:00Background is not durable. background=true lets a child outlive the current turn, but not the session. Use cron or a durable workflow when the work must survive restart.
23:00Do not delegate tightly dependent work. Keep short, sequential, interactive tasks in one loop; use a script for deterministic mechanics and cron for scheduled or durable work.

module 09 · build a durable team

Profiles & Kanban

watch on YouTube ↗

Here's what you need to know

the short version

A profile is a whole persistent Hermes, not a temporary helper. Give each role its own state and model, contain its filesystem separately, then use Kanban when work must cross agents and survive restarts.

02:58One profile means one isolated Hermes home. It has its own config, model, memory, skills, sessions, cron, logs, gateway, and persona. Two concurrent agents must not share one home or SQLite state will collide.
13:21Each gateway needs its own bot token. Several profiles can run messaging gateways on one machine, but Hermes blocks a second process from claiming a token already in use.
16:15Profiles isolate state, not your disk. A local-backend profile can still read the host filesystem. Pin its working directory and use Docker or SSH when you need a real boundary.
17:34Profiles are portable. Export and import can package the agent's configuration, skills, cron, MCP setup, and persona as a reusable distribution.
18:48Use Kanban for durable cross-agent work. Subagents fit a task you watch finish in one session; the SQLite-backed board survives gateway restarts and lets a human comment, block, or unblock mid-flight.
20:00Routing reads descriptions, not names. Write each profile's one-line role precisely. The decomposer builds the task graph, then the router assigns tasks to the profile whose description fits.
21:00Workers update the board through gated tools. They show, create, complete, block, and comment through the Kanban tool set rather than shelling into the database.
23:00Model choice follows the assignee. There is no per-card override; route a task to a different profile when it needs a different model or tool surface.

module 10 · defense in depth

Security

watch on YouTube ↗

Here's what you need to know

the short version

There is no fully capable, fully safe agent. Start with who can reach it, then layer approvals, containment, secret filtering, injection defenses, network controls, and per-profile least privilege.

02:05Capability and safety move against each other. Tune the system for its real trust level—a private laptop, a team service, and a public gateway should not share one security posture.
05:00The gateway fails closed. Configure explicit platform or global user allowlists. With no matching permission, a message never reaches the agent.
07:51Pick approvals deliberately. Manual asks on risky commands, smart mode lets an auxiliary model approve clear low-risk actions and escalate uncertainty, and YOLO skips almost every prompt. Approval timeouts deny by default.
11:26YOLO still has a floor. Obvious system-wiping commands are rejected before the approval layer and have no agent-side override. If an operation is truly that destructive, do it manually outside the agent.
13:20Containment limits the blast radius. Local execution leans heavily on approvals; Docker can sacrifice a container instead of the host. Anything you explicitly mount or forward into that container is still readable and exfiltratable.
17:23Secrets and instructions are filtered before the model sees them. MCP subprocesses receive a stripped environment, known token patterns are redacted, and prompt-bearing files are scanned for injection and exfiltration patterns.
19:00Network controls matter too. SSRF protection blocks private and link-local ranges and rechecks redirects; use the shared website blocklist, and only allow private URLs when a trusted local service genuinely requires it.
20:08Tirith catches what simple patterns miss. Its pre-execution scan looks for homoglyph domains, pipe-to-interpreter commands, and terminal injection tricks.
22:00Apply least privilege per profile. A researcher can have a domain blocklist and safe tools; a coder can run inside Docker with manual approvals; a low-risk writer may need far less friction.