Hermes and Forge: where the designs differ, and why
· Prabhu Eshwarla
Hermes is an open-source agent harness from Nous Research. The team at Artie published a detailed account of running it across their company, which is the best public description I have seen of what a harness looks like in daily use, and it is what I am working from here.
A harness decides what a model is allowed to do and what its output should look like. Forge does something adjacent and narrower: it decides what reaches a model at all, who may ask, and what record exists afterwards. The designs overlap in places and diverge sharply in others. This is where, and why we chose as we did.
| Hermes | Forge | |
|---|---|---|
| Per-team agents | Profiles | Projects |
| Reusable procedures | Skills | Four executors |
| Acting unprompted | Cron | Deliberately not |
| Persistent memory | Yes, revised nightly | Deliberately not |
| Model choice | Any provider | Any provider, set per organisation |
| What reaches the model | Not addressed | Masked before egress |
| Who may see what | Not addressed | Per project |
| Record of what happened | Telemetry | Audit record |
Profiles and projects
A Hermes profile is an agent with a personality, a domain, and access to what that domain needs. Artie run separate ones for planning, code, sales, design and operations.
A Forge project is the same idea: its own instructions, its own documents, its own members, and its own settings for what may reach a model. A finance project and a contracts project behave differently because someone shaped them differently.
The difference is what the boundary is for. A profile scopes what an agent is good at. A project scopes that and who can open it. Being in the organisation does not grant access to a project, and an administrator who can see that the project exists cannot read what is in it. That distinction does not matter when a team of seventeen shares a codebase. It is the entire question when the documents belong to somebody's client.
Skills, and the question we ask first
A skill is a written procedure: what to check first, which sources are authoritative, what the output should look like, how to verify it. Versioned in Git, read by every profile.
It is a good design, and the discipline around it is better. Artie were deliberate about writing few, on the grounds that an agent flipping through hundreds of skills burns tokens on the deciding:
if the value is obvious, the cost is justified. If the value is vague, it doesn't get built.
That is a better rule than most engineering strategies. But here is what a skill cannot do.
A skill is a procedure you hope the model follows. A program is a procedure it cannot deviate from.
A skill that says "total the column and report it in this format" will usually produce the right total. Usually. Ask a model to combine 132 rows and it will sometimes give you 98 of them, confidently, in the right format. That happened to one of our users last week, and the format was perfect.
So we ask a different question before asking how the model should do the job. Any step is run by one of four things:
- Rules: logic already written down, expressed as conditions
- A program: real computation over your own data
- AI: where the input is unstructured, such as a document, an email or free text
- A person: where the step needs judgement, a relationship, or accountability
Pick the most deterministic one that can do the job. Determinism costs nothing at run time and returns the same answer twice, which is what makes a process explainable afterwards.
A skill lives entirely inside the third of those four, and for work that genuinely needs a model it is the right tool. We have nothing better than a well-written project prompt to offer in its place.
Our argument is about the other three. Much of what gets written into skills is not judgement work. Combining two lists, reconciling an invoice against a purchase order, checking a threshold, reformatting a table. Each of these has exactly one right answer. Handing them to a model, however well instructed, means accepting that it will sometimes be wrong in a way nobody notices, because the output still looks right.
Skills tell the model how to do the job. We ask whether the model should be doing that step at all. The method behind that question is written up at the judgment line.
Memory, and why we left it out
Hermes agents keep a memory and revise it on a schedule, promoting what proved useful and dropping what did not. It is the most interesting idea in Artie's account and it is a real capability.
We decided against it, and the reason is narrow. A Forge answer either cites the documents it came from or says the material does not support one. A memory means an answer can draw on something with no document behind it. It also compounds an existing risk: documents are already a place where instructions can be smuggled in, and a memory that learns from documents turns one poisoned file into a belief that outlives the session it arrived in.
For an agent working on its own team's codebase, that trade is worth making. For answers about a client's contract, citation is the thing we are least willing to give up.
Autonomy
Hermes agents run on a schedule and act without being asked. Forge workflows advance when a person moves them, or when a rule or a program completes a step, and anything consequential waits for an approval.
This is the same trade as memory. Unprompted action is valuable when the work is yours and the blast radius is your own repository. When the output goes to a client, the question stops being whether the agent can act and becomes who answers for it when it was wrong.
What a harness does not address
Nothing in a harness decides what reaches the model. Artie's agents have the codebase, the docs, the CRM and the internet, and send what they need. For internal work on your own material that is exactly right.
For business AI on other people's material, three things are missing, and none of them is a harness's job:
What leaves. In Forge, personal details are masked before anything reaches a model. If a provider retains the request, what they hold is a token rather than a name.
Who may see what. Access is granted per project, not per company, and an administrator gets oversight without the ability to read a colleague's work.
What happened. Telemetry tells you tokens spent and whether a task succeeded. A record tells you who reached what, when, and under which rules. Those answer different questions, and only the second survives being asked six months later.
When you want each
If your team works on its own code and documents, cost is the pressure, and you have engineers, a harness is the right answer and you should build one. Three hours and a cheap machine is a genuinely good trade.
If the material belongs to somebody else, the binding constraint is not what an agent can do. It is what may reach a model, who can see it afterwards, and whether any of it can be shown to a client later. That is a different problem, and it is the one we build for.
