Most AI agents start from zero every time. Every session, every task, the agent re-learns what it was taught last week, because everything it knew lived in a prompt that has since been discarded. That is tolerable for a chat interface. It fails for work with exceptions, house rules and judgement calls, because the exceptions have to be restated forever.
Hermes agent development addresses that with a memory layer the agent owns. A Hermes agent records what it did, what it was corrected on, and what procedures it worked out, and reads that back on the next run. When it notices a repeated pattern, it writes a skill for it — a named, reusable procedure that is invoked directly rather than re-derived. Over months the agent accumulates a library specific to one business instead of a generic toolkit.
That is the claim. The rest of this page is the evidence for it, taken from the fleet that runs this studio rather than from a vendor brochure.
How a Hermes agent is actually assembled
Each agent on our fleet is four things on disk, and that shape is what makes the behaviour predictable:
- A SOUL.md — identity, mandate and hard limits. The research agent's mandate says it scans public sources, cites everything and never fabricates; the health-monitoring agent's says it reports and fixes nothing. Limits written here are limits, not suggestions in a system prompt.
- An AGENTS.md — the operating conventions for the environment it works in.
- A skills directory — between 13 and 29 skills per agent across our fleet, each a procedure the agent can invoke instead of improvising.
- Its own configuration — model, provider chain, schedule, delivery channels. Swapping a model is configuration, not a rebuild.
Persistent memory sits underneath all four. When a task arrives, the agent reads relevant prior context before planning: has this been done before, what worked, what was corrected. That lookup is the whole difference between an agent that improves and one that merely runs again.
Nothing here depends on a proprietary platform. The runtime is a Python virtual environment supervised by systemd, behind a Caddy reverse proxy, with PostgreSQL and Valkey for state — which is why a self-hosted deployment is the default rather than an upgrade tier. If you are weighing that against a managed product, the no-code agent platform comparisoncovers what you give up in each direction.
When Hermes is the right framework
Hermes fits when the workflow is single-agent and context-dependent: one agent that needs to remember preferences, learn from corrections and improve at a job it repeats. Patterns that work well:
- Inbox and triage — an agent that learns which messages need a human and drafts the rest in a recognisable voice.
- Research on a schedule — our own research agent has logged 721 findings and 310 separately-ledgered claims, each carrying a source; the claims-ledger architecture is how it is prevented from asserting anything it cannot cite.
- Recurring reporting — scheduled generation where the format and the metrics settle over time instead of being re-specified.
- Follow-up sequences — outreach that adapts from what previously worked, rather than firing a static template.
If the work needs several agents with handoffs and a gate between them, orchestration is the better shape — that is what OpenClaw is for. If it needs infrastructure, access control or audit trails the open frameworks do not provide, acustom build is the honest recommendation.
What actually goes wrong — from our own failure log
Vendor pages describe hallucination. Our surveyed fleet showed something else entirely: of 47 scheduled jobs, 34 were healthy, 6 were failing and 7 had never run. Every one of the six failures was infrastructural. The counts below are jobs carrying each error pattern, so they overlap — one job can be both misconfigured and blocked on its model.
| Failure class | Jobs affected | What it looks like |
|---|
| Model entitlement drift | 3 | A free-tier model slug revoked upstream; the API answers with a paid replacement slug instead of a completion |
| Delivery channel misconfiguration | 8 | A platform not enabled, or no delivery target resolved — the work ran and went nowhere |
| Upstream 5xx | 2 | Provider-side internal errors, transient and retryable |
| Provider unconfigured | 1 | No LLM provider selected for that agent at all |
Three engineering consequences follow, and they are what a Hermes build should include from day one: a fallback cascade so one revoked model slug cannot stop a job; a delivery assertion so a job that produces output with nowhere to send it is treated as failed; and a health check that reads every agent's last run rather than trusting silence. Our fleet runs a dedicated agent for exactly that last job — it reports on the others and fixes nothing, because an auditor that can act is not an auditor.
When Hermes is the wrong choice
Hermes is not the answer to everything, and the fastest way to waste a build is to reach for memory where none is needed.
If the workflow spans several systems with handoffs — a lead pipeline touching CRM, email, chat and scheduling, where different stages need different authority — orchestration with an approval gate between stages is the better architecture. If you are comparing graph-based orchestration specifically, the LangGraph write-upcovers where explicit state machines earn their complexity, andthe CrewAI alternatives comparisonsets Hermes against the role-based frameworks.
And if the task never varies — same input shape, same output, no judgement — a script is cheaper, faster and easier to debug at 2 a.m. Part of the free blueprint is saying which parts of a process should not be automated with an agent at all.