Hermes: Why Does an AI Tool Need Two Goal Engines?
Most AI assistants work the way you'd expect a vending machine to work: you put a question in, an answer comes out, and that's the transaction. The newer crop of agent tools complicates this slightly — they can use tools, take a few steps, ask follow-up questions — but the underlying model is the same. One loop. One way to "be done."
Hermes Agent, the open-source project from Nous Research that has been quietly accumulating users since its February 2026 release, makes a different choice. It ships with two mechanisms for getting an agent from a starting prompt to a finished result. They have different names, different shapes, different documentation pages, and they almost never appear together in the same example. The interesting question isn't which one is better. The interesting question is why both exist.
That question turns out to be a doorway into something larger: a quiet but real shift in how the people building agent infrastructure think about what an "agent" actually is. Hermes makes a category choice — and it does so in public, in code.
Two ways to finish a job
The first mechanism is called `/goal`. The shape is essentially a while-loop with a judge. You give the agent a goal in plain language ("find me the three best EU-based VPS providers under €15/month with IPv6"). The agent works on it, produces a response, and after each turn an external judge model receives three inputs — the original goal text, the agent's most recent response (capped at roughly 4KB), and a small system prompt — and returns a JSON object: `{done: true|false, reason: "..."}`. If `done` is false, the loop continues. If true, the session ends. By default the loop is capped at 20 turns, configurable upward.
This judge is deliberately small and deliberately separate. It doesn't share state with the agent; it doesn't have access to the agent's tools; it just looks at what the agent produced and decides whether the goal is met. If the judge crashes, the loop simply continues — fail-open. The continuation is implemented as a simulated user message ("keep going"), which keeps the agent's system prompt unchanged, which keeps the prompt cache valid, which keeps the cost predictable.
The second mechanism is the kanban board. There is no loop. Instead, Hermes maintains a SQLite database — `~/.hermes/kanban.db` — that holds tasks as records moving through states: `triage` → `todo` → `ready` → `running` → `blocked` → `done`. A dispatcher process polls the database every sixty seconds. When it finds a task in `ready`, it claims it with a compare-and-swap update (so two dispatchers can't grab the same task) and spawns a worker — a separate OS process with its own working directory, its own tool registry, and its own conversation history. When the worker is done, it updates the row to `done` and exits. When it needs human input, it parks the task in `blocked` until a human moves it on.
The shape is completely different. `/goal` is one agent, one conversation, one judge, one outcome. Kanban is N agents, N workspaces, N concurrent conversations, coordinated through a state machine that survives crashes and reboots because it's on disk.
Hermes never describes these two together. They live in different sections of the documentation. That separation is the first clue.
Why two is the point
Software has a long tradition of choosing one abstraction and forcing everything through it. ORMs treat everything like tables. UNIX treats everything like files. Single-paradigm choices have real benefits — simpler mental models, fewer integration questions — but they also have real costs whenever the world refuses to fit the chosen shape.
Agent frameworks have mostly picked one shape so far. LangChain treats every workflow as a chain. AutoGen treats everything as a multi-agent conversation. Most "AI assistant" products treat everything as a chat session that ends when the user stops typing. The implicit claim is: if our shape is general enough, all your problems are versions of our problem.
Hermes' design says the opposite. "Finish this single task" and "coordinate five workers across a sprint" are not the same problem in different sizes. They're different problems, and trying to handle the second with the same machinery as the first produces brittle, hard-to-reason-about systems.
Consider what `/goal` is good at: a clearly bounded objective, a single agent, a verifier that can look at one output and say whether the job is done. "Find a hotel in Lisbon under €120 for the last weekend of June, walking distance from the metro, with a working air conditioner — I trust you." That's a `/goal`. A judge can read the result and decide. Twenty turns is plenty. Parallelism would add nothing — you don't need three agents searching for one hotel.
Now consider what kanban is good at: a development sprint where two agents are reviewing code, one is updating documentation, one is regenerating the API client from an OpenAPI spec that just changed, and one is sitting in `blocked` because it needs a human to confirm the migration plan. None of these can be expressed as "agent works until judge says done." They have dependencies. They run in parallel. Some of them need to pause for a human. They might run for hours, span a reboot, and resume.
A while-loop with a judge cannot represent this. A state machine on disk can. Trying to bolt parallel multi-agent coordination onto `/goal` would be like trying to model a relational database with a single very long string — possible, in theory, but the abstraction is now lying about what's happening.
So Hermes ships both. The architectural statement embedded in that choice is: the goal-completion shape depends on the task shape, and the runtime should expose that, not hide it. This is the opposite of the standard agent-framework promise ("one abstraction for all your AI workflows"). It is, in a way, more honest.
The word "runtime" is doing real work
Nous Research consistently calls Hermes a "tools runtime." Not an assistant. Not an agent. Not a copilot. A runtime.
Their own description of the architecture starts here:
> "Self-registering functions grouped into toolsets and executed through a central registry/dispatch system."
This is language borrowed deliberately from systems programming. A runtime is what runs underneath things — it manages memory, schedules work, mediates between programs and the operating system. JavaScript has a runtime. The JVM is a runtime. CPython is a runtime. When you say "runtime" you are pointing at a specific layer of the stack: the layer that executes, not the layer the user talks to.
Several concrete design choices follow from this framing. Tools register themselves through AST parsing — a script declares a `@tool` decorator on a function, and Hermes discovers it on startup. There is no manual tool list, no JSON schema you maintain by hand. Memory is not a "feature" you turn on; it is a primitive woven into context injection, prefetch, and compaction at every turn. The dispatcher and worker processes are not optional add-ons; they are the way the runtime actually executes long-running tasks. Even Hermes' approval workflow for dangerous commands — the model proposes, the user confirms, the runtime gates the execution — treats safety as a runtime concern, not an application-level concern.
The chat interface, accessible through Telegram or Discord or Slack, is explicitly a thin frontend on top of the runtime. You can stop using Telegram tomorrow and the runtime would still be there. This is not how most "AI assistants" work. In ChatGPT or Claude, the chat is the product; the execution layer underneath is hidden, owned by the vendor, and not really yours.
Hermes inverts that. The execution layer is the product. The chat is just one way to talk to it.
OpenClaw lives on a different floor
The most common framing in comparison articles is "Hermes vs. OpenClaw" — both are open-source, both run on your own hardware, both have devoted communities. The framing implies they're competing for the same job.
They're not, and the confusion comes from how similar they look at first glance.
OpenClaw — recently and astonishingly the most-starred open-source project on GitHub, passing React in March 2026, currently around 347,000 stars as of late May 2026 — describes itself as a gateway. One central process that connects 23+ messaging platforms (WhatsApp, Telegram, Signal, iMessage, Discord, Slack, Matrix, WeChat, and more) to AI agents. It supports local models through Ollama and LM Studio. It is MIT-licensed. It is, by any reasonable measure, the largest open-source AI project in the world right now.
It also has no equivalent of `/goal`. No equivalent of kanban. No goal-completion mechanism at all. The platform layer decides which agent handles which incoming message, and after that the underlying language model is on its own.
That's not a flaw. It's a category choice. OpenClaw answers the question "how does a message reach my agent?" — across phones, across apps, across protocols. It does not answer the question "how does my agent finish a multi-step task?" That second question is left entirely to the LLM, which means it lives or dies on how good the model is at sustained task completion without scaffolding.
Hermes answers the second question and barely touches the first. It has channel adapters, yes, but the channel adapter is a thin wrapper — the interesting machinery is the runner, the memory, the kanban dispatcher.
So a fair comparison is not "which is better" but "what are they each for." The two systems sit on different floors of the same building. OpenClaw is the lobby — the place where messages from twenty-three different doors arrive and get routed to the right room. Hermes is one of the rooms — specifically, the room where a long, durable, possibly parallel task gets done.
Many users run both. OpenClaw as the inbound channel, Hermes as the execution engine that some of those messages trigger. The two systems don't conflict because they don't claim the same layer.
Aïda — the personal-assistant platform that has appeared on Het Schrijfhuis before — is in the same category as OpenClaw, not Hermes. It speaks Telegram, it has MCP tools, it has crons, but the question of how a task gets completed is delegated to the language model. There's no judge, no kanban, no dispatcher. Aïda and OpenClaw are different products with different feature sets, but they answer the same architectural question. Hermes asks a different one.
Is it usable now?
This is where honesty matters more than enthusiasm.
Hermes is open source under the MIT license, self-hostable, and will run on a €10/month VPS for personal use. The codebase is active — issues get triaged, PRs get reviewed, the documentation has improved noticeably since February. The technical fundamentals are real: the kanban layer survives crashes; the worker architecture scales horizontally; the `/goal` loop is simple enough to set up in an afternoon.
The friction is also real. The default iteration budgets are hard caps, not soft suggestions: 90 turns per agent session and 20 turns per `/goal` by default. When a sub-agent hits the ceiling mid-task, it stops, and the partial work is hard to recover. The Docker container runs as root — issues #3969 and #7826 remain open at the time of writing. For anything customer-facing or anything with real data, that's a blocker until it's fixed.
The cost structure is predictable but not free. With prompt caching enabled, a heavy user runs around €5-€68/month in API fees depending on traffic and which model is wired in. The fixed system-prompt overhead is high — agents like this need a lot of context just to know what tools they have — but caching means you pay for it once per conversation, not per turn.
So the honest answer is: Hermes is realistically usable now for technically inclined people who want to automate genuinely long-running autonomous tasks — code-review sprints, research pipelines, multi-stage data processing — and who are willing to host it themselves and accept that they're running pre-1.0 software. It is not yet ready for production deployments where uptime, multi-tenancy, or unattended security matter.
The interesting thing is that this is a perfectly reasonable place to be in May 2026. Hermes is not pretending to be more finished than it is. The documentation says, in essentially these words: this is infrastructure for people who want to build with infrastructure. If you want a polished assistant, look elsewhere — for now.
What the two engines actually say
The two-engine question is not a feature comparison. It's a position statement.
Most AI tools collapse the execution layer into the user-facing layer. You talk to a chatbot; somewhere underneath, something is happening; you don't see it and you can't reach it. The advantage is simplicity — you don't have to think about goal-completion mechanisms because the vendor made all those choices for you. The disadvantage is that when something goes wrong, or when your task doesn't fit the vendor's chosen shape, you have nowhere to go.
Hermes makes the execution layer visible and gives you two controls. The choice between `/goal` and kanban isn't a configuration setting; it's an architectural decision the user makes, every time, based on the shape of the task. A simple bounded goal goes to `/goal`. A multi-agent durable workflow goes to kanban. The runtime doesn't pretend they're the same.
That's a small thing on the surface. The implications are larger. It suggests a future where the interesting question about an AI tool isn't "what model does it use?" — that becomes commodity — but "what runtime assumptions does it make, and do those assumptions match the work I actually need to do?" The Kanaries comparison piece puts it well: the agent market is increasingly "not about tool calls, but about runtime assumptions under operational pressure."
If that's right, then Hermes' two engines are an early signal of the shift. The frameworks that hide their execution layer will keep doing fine for the cases their hidden choices happen to fit. The frameworks that expose it — and force the user to confront the choice — will be the ones you reach for when the standard shape stops working.
That moment, for most non-trivial workflows, comes faster than people expect.
Sources
Hermes documentation
- Hermes /goal feature docs — goal engine, judge model, turn budgets
- Hermes kanban feature docs — state machine, dispatcher, worker model
- Hermes Agent Loop Internals — 90-turn default, configuration
- Hermes tools runtime — runtime architecture, registry/dispatch
OpenClaw
- OpenClaw GitHub — gateway architecture, star history
- OpenClaw documentation — multi-channel routing
Comparisons and community analysis
- Kanaries: Hermes vs. OpenClaw — runtime-assumptions framing
- innFactory: OpenClaw vs. Hermes — practical comparison
- Magnus919: Hermes Kanban Guide — in-depth kanban walkthrough
