Hermes
Problem: A scheduled agent can appear autonomous while its context, authority, recovery, and outputs remain brittle.
Question: What does Hermes teach about operating an agent beyond an interactive chat?
Decision: Treat Hermes as a consumed runtime and a case study. Engineer the job contract instead of copying private configuration.
Hermes is an open-source agent runtime with tools, persistent state, messaging gateways, skills, and scheduled jobs. Its useful lesson is not a feature count. It is the operating boundary around long-running work.
Core Move
Separate the agent into five parts:
- Runtime — the provider-owned model loop, tools, gateway, scheduler, and sandbox.
- Job contract — the outcome, sources, permissions, budget, verifier, and stop rule.
- Durable state — the facts, progress, and failures that must survive a fresh session.
- Authority boundary — the actions the agent may take alone, must ask to take, or must refuse.
- Consumption loop — the reader or system that turns output into a decision, correction, or deletion.
Output that nobody reads or acts on is stored cost, not agency.
Why It Matters
Interactive agents inherit the conversation. Scheduled agents often do not. Each run may begin with a new context, a changed environment, and no awareness of the last failure.
Scheduled work therefore asks a stronger set of questions:
- Can the job reconstruct context from declared sources?
- Can it resume without repeating completed or failed actions?
- Can it detect stale paths, unavailable providers, and exhausted budgets?
- Can it fail closed before an unsafe side effect?
- Can a consumer tell whether the result changed anything?
The Scheduled-Agent Contract
| Field | Required answer |
|---|---|
| Outcome | What observable state should change? |
| Trigger | Which schedule or event starts the run? |
| Sources | Which current, reachable sources may it read? |
| State | What progress, evidence, and failure history must persist? |
| Tools | Which actions are allowed, idempotent, and reversible? |
| Authority | What may run alone, ask first, escalate, or refuse? |
| Budget | What caps tokens, money, calls, time, and retries? |
| Verifier | What evidence can fail the run? |
| Recovery | Where does it resume, roll back, or compensate? |
| Consumer | Who reads the result, and what decision can change? |
Failure Lessons
Fresh sessions punish hidden context
A job that relies on chat history, an implicit working directory, or operator memory will drift. Make scheduled input self-contained or retrievable through stable handles.
Configuration is not capability
A configured job is not REALITY. Capability becomes real only when a live run produces a valid artifact, survives its gates, and reaches a consumer.
One blocker can hide the next
Provider failure may hide a stale path. A stale path may hide a permission error. Classify failures by layer and re-run the full path after each correction.
Retries need idempotency
Fresh sessions and network failures create duplicate-action risk. Protect writes, sends, payments, and publications with idempotency keys or human gates.
Memory must earn its load
Store proven preferences, constraints, procedures, and unresolved state. Do not preserve whole conversation logs as default context.
Receipts need consumers
A report is unfinished until a named consumer accepts, rejects, routes, or deletes it. Measure consumed outcomes, not file count.
How to Use
- Start with one low-risk, reversible job.
- Run it manually with the same inputs the scheduler will receive.
- Restart from a fresh session and prove state recovery.
- Add budgets, failure classes, recovery, and an exact stop rule.
- Name the consumer and the decision the output may change.
- Schedule only after repeated manual runs produce the same proof shape.
- Review empty runs and unused outputs; shrink or kill work that creates no action.
Limits
- Hermes is a runtime, not a substitute for clear intent or domain judgment.
- Vendor commands, models, limits, and integrations change quickly. Verify official documentation.
- Messaging access does not justify broad write authority.
- More skills or tools can reduce routing clarity and increase the attack surface.
- A general agent should not absorb domains that need isolated data and authority.
Snapshot (2026-07): Hermes supports interactive and scheduled agent work through its runtime, gateway, tools, skills, and persistent-state features. Verify current feature details before operating it.
Changes my mind: A scheduled agent without durable state, explicit recovery, or a named consumer repeatedly produces safer and more valuable outcomes than this contract.
Retrieval
Pull this page when choosing Hermes, converting an interactive prompt into scheduled work, diagnosing a fresh-session failure, or deciding whether an autonomous job should survive.
Version delta: Replaced private configuration and feature-catalog guidance with a public operating case centered on boundaries, recovery, and consumed proof.
Context
- instance-of Agent Systems — compare agent runtimes.
- applies Agentic AI Systems — engineer the surrounding system.
- depends-on Agentic Prompt Loops — define triggers, state, budgets, and proof.
- pairs-with Delegation — set authority before connecting external tools.
Links
Questions
Next question: Which scheduled job has a named trigger but no named consumer?