This is a submission for the Hermes Agent Challenge: Write About Hermes Agent
Most write-ups about Hermes Agent tell you the same true thing: it's a self-improving, self-hosted agent that learns across sessions and gets better the longer it runs. That's accurate. It's also the easy half of the story.
The half almost nobody writes is this: a system that compounds capability compounds everything else too — cost, drift, and the size of the trust you've extended it. Self-improvement is not a free upgrade that arrives while you sleep. It's a loan. The agent draws down capability now and bills you later in tokens you didn't predict, skills you didn't review, and code running on your server that you didn't write.
I want to give that second half an honest, engineering treatment — the kind I'd want before putting an autonomous agent on a box I own. If you're new to agents, the first two sections bring you up to speed in plain language. If you've already deployed a few, skip to "The liability side," which is where the interesting, under-discussed problems live.
The thesis in one line: Hermes is the most honest implementation of compounding autonomy I've seen — and compounding is exactly the property you have to manage, not just enjoy.
TL;DR
- Hermes's superpower is compounding: it writes its own reusableskills(plain markdown) and reuses them, so the cost of re-solving a task trends toward zero.- Compounding is a property, not a feature — the same loop also compoundscost drift,skill rot/drift, and yourtrust surface. Those three are what every popular write-up skips.- The good news: because the learning is legible(readable files, queryable memory), it's governable. Below is a failure-mode taxonomy, an illustrative cost model, and a 6-step framework you can apply this week.
If you've only used chatbots, here's the one idea that matters.
A normal LLM call is stateless. You ask, it answers, the slate wipes. Tomorrow it has forgotten not just your name but the entire solution it worked out for you an hour ago. Every session pays full price to rediscover what it already knew.
Hermes is built around the opposite assumption. It runs as a long-lived process on infrastructure you control — a VPS, a Docker container, an SSH host, a serverless backend. Because it's a process and not a request, it can keep things between sessions. Specifically, three things:
That's the whole magic, demystified:
┌─────────────────────────────────────────────┐
│ │
▼ │
┌─────────┐ do the task ┌──────────────┐ │
│ task │ ───────────────▶ │ reasoning │ │
└─────────┘ └──────┬───────┘ │
│ │
"this worked, keep it" │
▼ │
┌───────────────────┐ │
│ write / refine │ │
│ a SKILL (.md) │───┘
└───────────────────┘
next time the task appears, load the skill
instead of re-deriving the solution
The skill file itself is unglamorous on purpose. Conceptually:
---
name: weekly-revenue-brief
description: Assemble the Monday revenue summary for the team
---
1. Pull last 7 days of orders from the data source.
2. Compare against the prior 7 days; flag any metric moving >15%.
3. Summarize in 5 bullets, lead with the biggest mover.
4. Deliver to the #leadership channel before 9am.
The first time, the agent reasons its way to that procedure from scratch — expensive, slow, uncertain. Every time after, it loads four lines of markdown and executes. That is the compounding asset. Re-derivation cost drops toward zero. Hold onto that sentence; it's the hinge of everything that follows.
It's worth being concrete about why this is more than a nice feature, because the value is what justifies tolerating the costs later.
1. Re-derivation is the silent tax of stateless agents. Think about what a stateless agent actually spends tokens on. A huge fraction is re-establishing context and re-solving solved problems. A skill is a cache for reasoning, not just data. Once "how to assemble the Monday brief" is a skill, the model spends its tokens executing a known plan instead of inventing one. Fewer tokens, fewer steps, fewer chances to wander.
2. The artifacts are inspectable. Because skills are markdown and memory is a queryable store, you can actually read what your agent has learned. Compare that to fine-tuning, where "what the model learned" is diffused across billions of weights you can't audit. Hermes's learning is legible. (This matters enormously later, when we talk about governance — you can't govern what you can't read.)
3. It parallelizes. Hermes can spawn isolated subagents with their own execution context, so a long task can fan out (one subagent drafts while the main agent compiles) and the results fold back in. Pair that with natural-language scheduling ("every morning at 8, brief me on yesterday's numbers") and you stop operating a tool. You start running a process.
4. You own the whole thing. MIT-licensed, on your hardware, model-agnostic (swap providers when one has an outage or a better price). No vendor can deprecate your agent out from under you.
Put together, the promise is real: an agent that's cheaper per task and more capable per week than the one you started with. The mistake is to stop the analysis there. The same mechanism that delivers all of that (persistent, self-authored, compounding artifacts) is also the one behind the bills nobody itemizes.
Here's the reframe. Compounding is not a feature; it's a property of the system. And properties don't take sides. The same loop that compounds capability compounds three liabilities, and they're the three things the popular write-ups skip.
The happy story says self-improvement makes the agent cheaper. Often true per task. But two things move in the other direction at the same time, and they can win.
Doing the math (an illustrative model, not a benchmark). Numbers make this concrete. Take one recurring task and price it at illustrative blended rates of $3 per million input tokens and $15 per million output tokens. The point isn't the exact figures — it's the shape of the curve.
Marginal cost per run — the asset side working as advertised:
| Mode | Input tok | Output tok | Cost / run |
|---|---|---|---|
| Stateless re-derivation (re-plan every time) | 9,000 | 2,500 | $0.065 |
| Skill-cached execution (load the skill, run it) | 3,500 | 900 | $0.024 |
That's ~63% cheaper per run once the skill exists. Real, and worth having. But now let time pass and watch the two countervailing forces:
The compounding bill — same task, later:
| Stage | Effective in / out tok | Runs / day | Daily cost |
|---|---|---|---|
| Old stateless chatbot (only runs when you type) | 9,000 / 2,500 | 5 | $0.33 |
| Lean autonomous agent (scheduled, pruned skills) | 3,500 / 900 | 30 | $0.72 |
| Bloated agent (200 unpruned skills add discovery + wrong-skill retries) | 6,000 / 1,400 | 80 | $3.12 |
Two things jumped. First, skill-library bloat erased part of the per-run savings ($0.024 → ~$0.039) because the agent now spends tokens deciding which of 200 skills applies and occasionally firing the wrong one. Second — and this dominates — autonomy multiplied the run count. The cheapest-per-run configuration can still be the most expensive per month, and a single runaway recursive night (subagents spawning subagents) turns $3/day into the $47 surprise. That tail isn't in the table because tails never are until they bill you.
So "self-improvement makes it cheaper" is only half right. Yes, the cost of any single task falls. But the baseline creeps up, the tail risk grows, and whether you actually save money comes down to three unglamorous habits: pruning old skills, capping spend, and keeping the agent on a short leash. None of those happen on their own. You have to do them.
This is the bill I see discussed almost nowhere, and it's the one that bites at day 90, not day 1.
A self-authored skill is code that no human reviewed, with no tests, no owner, and no expiry. Now run time forward:
total_price
"). The API changes. The skill doesn't know. It now produces confidently wrong output — and because the agent The deep point: a self-improving system optimizes for "did this work just now," not "is this still correct." Those two questions drift apart over time, and nothing in the loop notices on its own. Legacy code at least holds still while it rots. A self-improving agent's skill set keeps moving, so your mental model of what it does goes stale even faster than the skills themselves.
Strip away the framing and look at what you've actually deployed: a process that writes new code and persists it on a server you own, then runs that code, on a schedule, with whatever credentials you gave it.
That's a remarkable amount of capability, and it creates a trust surface most agent write-ups don't name:
None of this means "don't run it." It means the correct emotional posture toward a self-improving agent is the one you'd have toward a sharp, fast, sleep-deprived junior engineer with production access: enormous upside, and you do not skip code review.
Naming failure modes is how you get to design against them. Here's the set that actually shows up, mapped to cause and the control that addresses it.
| Failure mode | What it looks like | Root cause | Primary control |
|---|---|---|---|
| Cost blowout | |||
| Surprise bill from an overnight/recursive run | Unbounded autonomy + delegation | Hard spend cap; step/recursion limits; budget alerts | |
| Skill rot | |||
| Confidently wrong output after an external change | Stale procedure trusted over re-derivation | Skill expiry/review dates; smoke tests on critical skills | |
| Skill drift | |||
| Behavior slowly changes for no clear reason | Refinement overfit to recent noise | Version control on the skills dir; diff review of self-edits | |
| Skill collision | |||
| Same input, different behavior on different runs | Overlapping/contradictory skills | Periodic skill audit; dedupe and namespace | |
| Durable injection | |||
| Malicious behavior that survives restarts | Persistence of a poisoned skill/memory | Sandboxed backend; input provenance; approval-gated writes | |
| Silent failure | |||
| Task "succeeds" but output is garbage | No verification step in the loop | Output checks; human-in-the-loop on high-stakes actions | |
| Context bleed | |||
| Cross-task contamination of state | Shared memory across unrelated work | Profile isolation; scoped subagents |
If your reaction to that table is "this is just normal production engineering," — yes. That's the headline. The mature way to think about Hermes is not "magic learning AI" but "a new kind of production system with a new failure surface that you engineer for like any other."
Good news: because Hermes's learning is legible (markdown skills, queryable memory), every one of those failure modes has a practical control. Here's the framework I'd apply, ordered by leverage.
1. Put the skills directory under version control.
This single step converts an opaque self-modifying system into a reviewable one. git init
the skills dir. Now every skill the agent writes or refines is a diff you can read, blame, and revert. Self-improvement becomes a series of pull requests from your agent to your repo. Review them like you'd review a teammate's.
2. Bound autonomy before you bound anything else.
Set a hard spend cap and a step/recursion limit first, then expand. The default posture for an always-on, delegating agent should be "small budget, narrow scopes," widened deliberately. Cost is the failure you can fully prevent with config.
3. Sandbox by default; grant scopes like you grant SSH keys.
Pick an isolated backend (Docker is the easy, strong default given how many of us already run it). Give read-only credentials until a write capability has earned its keep, and gate genuinely consequential actions behind human approval. Treat "what can this agent touch" as a security decision, because it is one.
4. Give skills an expiry and a smoke test.
A skill that depends on an external system should carry a review date and, ideally, a one-line check it can run to confirm its assumptions still hold ("does the API still return this field?"). This is the antidote to silent rot — the agent should be able to notice when its own procedure went stale.
5. Audit the skill library on a schedule — using the agent itself.
Once a week, have Hermes inventory its own skills: flag duplicates, contradictions, and unused entries, and propose prunes. The same self-improvement loop that creates drift can be pointed at detecting it, if you ask. Compounding capability includes the capability to clean up after itself — but only if governance is one of its jobs.
6. Watch four numbers.
You don't need a dashboard, just attention to: tokens/day (is baseline cost creeping?), skill count (is the library growing faster than it's pruned?), skill-edit frequency (is something drifting?), and human-override rate (are you correcting it more or less over time?). Those four tell you whether the compound is working for you or against you.
If you do nothing else: version-control the skills dir and cap the budget. Those two cover the majority of the real-world risk for an afternoon of effort.
Hermes Agent earns its reputation. The design choices that matter — legible markdown skills instead of opaque weights, a process you own instead of an API you rent, isolation backends as first-class options, learning that happens in files you can read — are the right choices, and they're what let you govern the thing at all. Most "self-improving agent" pitches ask you to trust a black box. Hermes hands you the box open.
But the line the ecosystem keeps repeating, "it just gets better the longer it runs," is half engineering reality and half marketing convenience. Here's the whole of it: the agent gets more capable, more expensive, more drift-prone, and more powerful all at the same time. Which of those wins out is decided by you, not by the loop.
So here's the decision rule I'd actually give a colleague:
Self-improvement is the most exciting property in agents right now. Treat it like compound interest: extraordinary when it's working for you, brutal when you've stopped paying attention to which direction it's pointed. Hermes gives you, unusually, the instruments to check. Use them.
Thanks for reading. If you've deployed a long-running agent and watched its skill library grow, I'd genuinely like to hear which of these bills hit you first — drop it in the comments.