Hermes Agents Explainer

How Agents Work
in Hermes

Hermes agents — called minions — are subordinate AI sessions that Callum controls directly. A minion is a separate conversation with its own context, its own tool access, and its own isolation from Callum's memory. Frank talks to Callum; Callum talks to minions. That hierarchy is the whole model.

orchestration context isolation cost control delegation subagents

At a Glance

👤 Frank
Talks to Callum. Gives high-level goals. Doesn't manage minions directly.
🤖 Callum
The orchestrator. Spawns minions, delegates tasks, checks results, synthesizes findings.
👷 Minions
Subagents. Each has its own session, context window, and scoped tool access. They report back to Callum.
📋 Instructions
Written by Callum (or Frank) and injected into the minion's context at spawn time. The minion follows them blindly.
⚡ Key property: context isolation
A minion can't read Callum's memory. Callum must explicitly hand it the context it needs — files, summaries, URLs — before spawning it. This is a feature: it keeps low-stakes work from polluting high-stakes memory.
💸 Key property: cost control
Minions can run on cheaper models for low-stakes work. Callum (Sonnet 4 or Opus) doesn't need to burn expensive tokens on "read 50 URLs and summarize." A minion on MiniMax M2.7 can do it for cents.

How Hermes Agents Are Structured

A Hermes minion is a separate conversation session managed by the delegate_task primitive. Think of it as a forked conversation thread — Callum creates it, feeds it instructions and context, and then it runs independently until it returns a result.

The mental model: orchestration hierarchy

User layer
Frank: "research this topic"
goal + context
Orchestration layer
Callum: plans, writes instructions
prompt + tools + context
Worker layer
Minion: executes, returns result

What a minion session contains

Component Description
system prompt Role definition, constraints, and behavioral guardrails for the minion
instructions What to do, what to return, any formatting rules Callum specified
context Files, URLs, summaries, or data Callum pasted in — the minion's working memory
tool access Scoped per-minion; can be restricted (e.g., no file writes, no web, read-only)
model Can be cheaper than Callum's model for low-stakes, high-volume tasks
result Minion's final output is returned to Callum; Callum synthesizes and presents
⚠️
Context isolation is real. A minion has no access to Callum's memory by default. If it needs to know something, Callum must pass it explicitly — as text in the prompt, as files on disk, or as a fetched URL. Minions are intentionally sealed containers.

What Happens When Callum Creates a Minion

Step by step:

1. Callum decides to delegate

Something is too time-consuming, too noisy, or too risky to do inline. Callum identifies the task: "I need to read 30 URLs and extract the key claims."

2. Callum writes the instruction packet

This is the critical piece. The instruction packet includes:

3. Callum calls delegate_task

This spawns a new Hermes session with the instruction packet. The minion gets its own fresh context — it doesn't see what Callum has been thinking about.

ℹ️
The minion is independent while it runs. Callum can continue doing other work in parallel, or wait. When the minion finishes, its output comes back as a structured result.

4. Minion executes

The minion works within whatever tool access and model constraints were set. It produces a result — text, a file, a structured data object.

5. Callum receives and synthesizes

Callum gets the raw output, checks it, formats it, and presents the useful parts to Frank. Or uses it as input for the next step.

6. Minion session ends

The minion's session closes. Its context is discarded — unless Callum explicitly captured something from the output to store in memory.

Where Instructions Come From

Instructions are text — either written by Callum based on Frank's request, or written by Frank directly in the goal field when he invokes delegate_task.

Frank → Callum
Frank gives Callum a goal. Callum writes the minion instruction packet. This is the common path: Frank doesn't need to know the agent mechanics.
Frank → minion directly
Frank can call delegate_task himself and write instructions directly. This bypasses Callum's orchestration — useful for quick jobs where Frank knows exactly what he wants.
Skills as templates
Hermes skills can define agent templates: reusable instruction packets with placeholder fields. Callum can load a skill and fill in the blanks rather than writing instructions from scratch each time.
Cron jobs
Cron-triggered agents have instructions baked into their prompt at creation time. They run on a schedule and deliver results to a channel (Telegram, Discord, etc.).

Types of Agents in Hermes

Type How created Lifespan Runs on
delegate_task minion delegate_task call One-shot or long-running Any model (configurable)
Spawned Hermes process hermes chat --profile <name> Persistent session Any Hermes profile
Cron job cronjob create Recurring on schedule Any model (configurable)
Plugin / hook Event-triggered in Hermes Per-event, stateless Runs in-process

delegate_task minion

The main one. Callum (or Frank) calls delegate_task with a goal, context, and optional model/tools restrictions. The minion session runs to completion and returns a result. Up to 3 minions can run in parallel by default.

Spawned Hermes process

A fully separate Hermes session with its own profile, own config, own memory settings. Like having two different AI beings with different tool access and different personality configs. Useful for persistent workers that need to maintain state across many interactions.

Cron job

An agent that fires on a schedule. Instructions are baked in at creation time. Results delivered to a channel. Useful for recurring monitoring tasks: "check this RSS feed every hour and alert me on new posts."

Plugin / hook

Stateless event-driven agents. on_session_start, pre_llm_call, post_llm_call, on_session_finalize — these fire in response to Hermes events and can do focused work (inject memory, log traces, send notifications). Not really "agents" in the autonomous sense, but they participate in the same orchestration model.

Why Use Minions at All

📌 Context isolation
Low-stakes work doesn't pollute high-stakes memory. A minion that reads 50 webpages and extracts claims leaves no trace in Callum's memory unless Callum explicitly captures the result. Keeps memory clean.
💸 Cost
Expensive model (Opus/Sonnet) for thinking and planning. Cheap model (MiniMax M2.7) for grinding: bulk reads, summarizations, log parsing. Use the right tool for the job.
⚡ Parallelism
Multiple minions can run at the same time. Five research scouts each reading different sources, all reporting back to Callum simultaneously. Frank doesn't wait for one to finish before the next starts.
🔒 Safety
Minions can be given restricted tool access. A "safe web scout" might be allowed to read URLs but not write files. If it goes off the rails, it only affects its own sealed context.
🔄 Specialization
A minion can be tuned for a specific task type: a code reviewer that always uses the same instruction template, a inbox triager with its own prompt. Reuse without contaminating Callum's own context.
🚦 Redundancy
Ask the same question to two different minions on two different models and compare results. Not full verification, but a cheap sanity check before trusting a single output.

Minion Ideas for Callum

Concrete tasks where minions make sense. Listed with suggested model tiers — not hard rules.

Research scout
medium model
Reads 10–20 URLs on a topic and returns a structured summary with key claims and sources. Callum gives it a topic and a list of URLs; minion reads them all and writes back a digest. Keeps Callum's context clean.
Log goblin
cheap model
Parses log files and extracts errors, warnings, patterns. A messy 5,000-line server log gets fed to a minion; it returns the 20 lines that actually matter. Callum doesn't have to read noise.
Diff reviewer
medium model
Takes a git diff and writes a code review: what changed, what risks exist, what tests might be missing. Can run in parallel on multiple PRs. Callum decides which suggestions to act on.
Inbox triager
cheap model
Reads new emails and classifies them: "action needed", "FYI", "noise", "follow up". Returns a short ranked list with one-line summaries. Callum decides what to act on and what to archive.
Safe web scout
medium model
Reads a specific URL or set of URLs without any file-write or terminal access. A sealed browser. Returns the content; can't touch anything else on the system. Good for risky-looking links.
Cheap summarizer
cheap model
Takes a long document (transcript, article, PDF text) and returns a one-paragraph summary. Callum decides what to remember; the minion just does the compression work.

Cost Control in Practice

The core principle: use the cheapest model that can reliably do the job. Not every task needs Opus. Not every task needs Sonnet. A lot of tasks need "good enough at 1/10th the cost."

Model tiers for minions

Task type Model tier Why
Bulk reading, log parsing, basic summarization cheap (e.g. MiniMax M2.7) High volume, low nuance. Speed and cost matter more than depth.
Structured extraction, classification, simple synthesis medium (e.g. Sonnet 4) Needs reasonable reasoning but not frontier-level.
Code review, complex analysis, nuanced writing smart (e.g. Opus) Errors are costly. Trust threshold is high.
ℹ️
Frank's preference. Frank has mentioned wanting to use MiniMax M2.7 for low-stakes minion work — it's fast and cheap. That's exactly the right instinct. Reserve Sonnet and Opus for tasks where the cost is justified by the stakes.

Verification and Trust

Minions can be wrong. They can hallucinate, misread, miss nuance, or just do exactly what you told them instead of what you meant. Verification is not optional.

What to verify

✗ Don't trust claims blindly
A minion that says "I read 20 pages and found X" — did it actually read all 20? Did it miss the 21st that contradicts X? Check the work, not just the summary.
⚠️ Tool calls need auditing
A minion with tool access made calls. Check what it actually did — especially file writes, shell commands, or anything with side effects. A minion that was supposed to "just read" might have written files by accident.
✓ Cross-check high-stakes results
For important outputs, run the same task with two different minions on two different models and compare. Divergent results are a signal. Agreement doesn't mean correctness, but disagreement is informative.
✓ Callum synthesizes
Callum doesn't just pass minion output through. He reads it, evaluates it, flags uncertainty, and presents a synthesis — not a raw dump. That's part of the orchestration layer's job.
🔴
The failure mode to watch for: A minion reports back confidently with wrong information. This is especially dangerous when the minion had tool access and might have acted on bad data. Always verify before acting on minion output in the real world (email sends, file writes, API calls).

Quick Glossary

minion / subagent
A subordinate AI session spawned and managed by Callum (or Frank). Has its own context, isolated from Callum's memory.
delegate_task
The Hermes primitive that spawns a minion. Call this with a goal, context, and optional constraints (model, tools).
context isolation
Minions can't read Callum's memory. Callum must explicitly pass context as text or files. Keeps low-stakes work from polluting high-stakes memory.
orchestration
Frank → Callum → minions. Frank gives Callum goals; Callum breaks them down, delegates to minions, collects results, synthesizes.
instruction packet
The text Callum (or Frank) writes to define what a minion should do, how to do it, and what to return. The minion follows this exactly.
tool restrictions
Minions can be given scoped tool access — e.g., read-only web, no file writes, no shell. Reduces blast radius if something goes wrong.
spawned Hermes process
A fully separate Hermes session with its own profile and config. More persistent than a delegate_task minion. Can maintain state across many interactions.
cron job
An agent that runs on a schedule. Instructions are baked in at creation time. Results delivered to a channel (Telegram, Discord, etc.).
synthesis
Callum's job after receiving minion output: read it, evaluate it, check for errors or gaps, and produce a coherent response for Frank — not just raw passthrough.
model tier
cheap (M2.7) for grinding; medium (Sonnet) for reasoning; smart (Opus) for high-stakes. Use the right model for the task's actual requirements.