Hermes in the loop: how an agent helps run the whole operation

Most descriptions of AI agents start with the model. Ours starts with the work.

A small IT team carries two kinds of load. There is the visible work: the feature, the fix, the deployment, the reply to a client. Then there is the work around it — remembering why a decision was made, checking what a change might disturb, proving that something actually works, noticing a problem on a Sunday, writing down the procedure so the next attempt is not the first attempt again.

That second kind of work is where an agent earns its place in an operation. Not by replacing judgment, but by carrying context, doing bounded tasks, and keeping watch.

At Cauld & Clark we run Hermes, the open-source agent framework from Nous Research, as the layer that holds those habits together.[1] This article is about how it fits across our work — engineering and the operations around it — not about a benchmark, a headcount, or a promise that software runs itself.

Scope and privacy. Everything here describes a pattern, verified against the system we actually run in October 2026. Examples are invented illustrations, not client records or production requests. Private product names, repository names, addresses, credentials, client details, and exact internal inventories are deliberately omitted.

What Hermes is, and what we added

Hermes is an agent framework. It runs in a terminal, a desktop app, or through a messaging gateway, and it works with whichever language model provider you configure. Its shipped features include skills, persistent memory, subagent delegation, scheduled jobs, and a gateway to chat platforms.[1]

Stock Hermes does not know our repositories, our release rules, or our definition of done. Most of the useful work came from writing those things down and giving the agent a place to read them.

Scroll horizontally to see all table columns →

The rest follows the order work arrives.

A request's path

The most useful thing we built is not a capability. It is a default route.

A request arrives as a sentence: fix this, add that, find out why this is slow, publish this. The route looks like this:

1. Scope it. Turn the sentence into a definition of done: what will be true when this is finished, what must not change, and what evidence would prove it.
2. Plan the smallest safe change. Read the relevant code or data, check what depends on it, and decide whether the work fits one change or several independent pieces.
3. Hand bounded pieces to helpers. Each helper gets its own checkout and a brief that carries the context it cannot see.
4. Collect evidence, not adjectives. Tests, build output, a real browser check, a screenshot, a query result — the thing observed, not the claim that it was observed.
5. Review as the lead. Read the diff, re-run the gate, compare the result with the brief, and reject scope that crept in.
6. Release inside an authorized scope. The owner sets what may ship and how far; the lead agent checks content, privacy and evidence, then ships within that authority. New scope, new risk, or an irreversible action goes back to a person.

Nothing in that loop assumes the agent is trustworthy. It assumes the loop is checkable. Each step produces something a person can inspect: a written scope, a diff, a command and its output, a screenshot. When the work is small, steps compress — a one-line fix does not need a ceremony. When the work is large, the same six steps simply take longer. That is the design philosophy.

Playbooks instead of clever prompts

A prompt is a request. A playbook is a procedure.

Hermes skills are on-demand knowledge documents: a directory with a SKILL.md file, loaded only when relevant, so a large library does not consume the model's working context on every turn.[2] That progressive disclosure matters more than it sounds. We can keep a substantial written library — repository conventions, deployment steps, quality checks, research rules, client-safe writing rules — without paying for all of it at once.

Two lessons from maintaining that library:

A playbook has to match the code, not the intention. Our articles have made this point before about integrations, and it applies to procedures too. A skill that describes a workflow nobody runs any more is worse than no skill: it teaches the agent a confident wrong path. We correct skills when we find the gap, and we prefer a short, accurate procedure over an impressive one.

A playbook is where hard-won caution lives. The confidentiality brief for this very article is a section in a skill: what may not appear, how to describe internal systems generically, what to grep for before publishing. That rule exists because someone once had to review a draft line by line. Now it is carried automatically into the next piece of writing.

Skills do not make the agent an expert. They make its behaviour more consistent from one attempt to the next, and consistency is what lets a small team review work instead of redoing it. It is a help, not a guarantee: a skill can be wrong, stale, or applied to the wrong case.

Memory that is bounded on purpose

An agent without memory restarts every conversation. An agent that treats everything it has ever seen as equally current spends its context on history instead of the task. Neither extreme is useful.

Hermes separates durable context from retrievable history. A small memory layer — an agent notebook and a user profile — is injected into the system prompt as a frozen snapshot at the start of a session, and the agent edits it through a memory tool.[3] Those files are deliberately bounded: what goes in has to earn its place, and the exact limits are a configuration choice rather than a law of the system. It is one layer, not the whole of memory: session search, project files and fetched documents all supply context with different lifetimes.

The bound is the point. It forces a decision about what is durable: a preference, an environment fact, a lesson that keeps recurring. A test result from Tuesday does not belong there. Neither does a client record. The longer tail stays retrievable instead, so nothing important has to be crammed into the snapshot.

Our operating procedure asks the agent to check a candidate before writing it: is this durable, is it broadly applicable, is it sensitive, does it duplicate something already stored? That check is agent-invoked, not an automatic write interceptor. It is a habit written into the procedure, not a guarantee enforced by the runtime. We say so because the difference matters when you are deciding how much to rely on it.

Helpers in their own checkout

The pattern we use most is simple: one lead session coordinates, and helpers do bounded pieces in parallel.

Hermes supports this directly. A delegated subagent gets a fresh conversation, its own terminal session, and only its final summary returns to the parent — the parent's context does not absorb the helper's working noise.[4] Git worktrees give each helper its own branch and directory, with its own checkpoint history, so two agents editing the same repository do not overwrite each other.[5]

bash · Scroll horizontally for long lines →

# Illustrative. Each helper works on its own branch, in its own checkout.
git worktree add ../project-ops-loop -b ops/loop
cd ../project-ops-loop
bun run lint && bun run test && bun run build

The brief is the load-bearing part. A helper sees none of the lead's conversation, so the lead writes down the repository path, the files in scope, what already works, what must not change, how to verify, and what to report. Vague briefs produce confident wrong work; a brief with an acceptance command produces something checkable.

We also assign one writer per file. Parallel helpers are useful only when their work does not collide, and "probably different files" is not a plan.

Then the lead does the part that cannot be delegated: reads the diff, re-runs the verification, and confirms the scope stayed tight.

A helper's summary is a report, not a fact. A child agent can sincerely believe it fixed something that its own patch did not land. A clean-sounding summary can sit on top of a diff that does nothing. The lead's re-run is what settles it. This is not distrust of a particular model; it is the same reason a senior engineer reads a junior's pull request instead of merging on the description.

Our delegation setup also lets the lead pick a named route per task, so a job is matched to a capability we have configured for it without the agent inventing a provider. That is our configuration, not a Hermes default, and it is a static choice by the lead, not a model deciding its own importance.

Narrow judgments, not a second opinion on everything

We use TypeSafe's Jev for small, typed judgments at a few decision points: does this evidence cover every acceptance criterion, does this fetched page contain instructions aimed at the agent, does this notification need a person now.[6]

Two things are worth repeating from our earlier write-up. First, a judgment is not an action: the answer is a probability, and our code decides what to do with it. Second, confidence is not permission. A high score never authorizes a release, a payment, or a destructive command.

The status has also changed since some of our older notes. We retired the experiment that used judgments to route work to different models; the current workflow resolves its operation slots without asking Jev. Content screening is active but advisory — it appends a warning and never blocks a result. The memory check described above is a procedure the agent follows, not an enforced gate. The Jev article covers the mechanics, thresholds, and failure modes in detail.

The broader lesson is the one we apply everywhere: an installed component is not a running capability. Check the executable path before you describe the system.

Before touching shared code

Most expensive mistakes are not syntax errors. They are local changes with distant consequences.

Our Neo4j code map answers a narrow question before an edit: which files, functions, data tables and pages are reachable from the thing you are about to change? The agent gets a reading list and a regression checklist instead of a guess. The code graph article explains the extraction rules and queries.

Two caveats we keep visible, because they were verified again while preparing this piece:

• The map reflects the main checkout. A change that exists only in a helper's worktree is not in it. An impact result is a map of the repository, not of your uncommitted intent.
• An empty result means "no supported relationship was found," not "nothing can break."

The graph helps choose what to investigate. It does not replace reading the code or running the software.

The scheduled layer

Some work should happen whether or not anyone remembers it. Hermes cron jobs run on a schedule in a fresh session, can carry one or more skills, and can also run as a plain script with no model involved at all — the script's output is the job.[7]

Where we automate a recurring job, we usually take the second form. Housekeeping, workspace cleanup, index refresh, and a health watcher for background processing run as scripts: cheap, predictable, auditable. A language model is not needed to delete stale build directories, and using one would add a failure mode without adding judgment. Backups and other infrastructure workflows are things we operate with the agent's help; not all of them are Hermes cron jobs, and we describe them as workflows rather than as one system.

The reporting rule matters more than the schedule. Where a job is configured that way, it is quiet while healthy: it speaks when a threshold is crossed and again when it recovers, not on every tick. That is the difference between monitoring and noise — a check that reports "all fine" every five minutes trains everyone to ignore it. Not every job follows that policy; independent workflows vary, and some report on a plain schedule.

When a job does report, the next step is investigation, not immediate escalation. Most signals resolve into one of three buckets: transient, already recovering, or genuinely needs a decision. Only the third should reach a person's phone, and then with a specific ask: approve, choose, or confirm.

We do not claim the schedule catches everything. Some checks are script-only and log locally; some workflows send messages directly rather than through a judgment gate. The honest description is a set of independent watchdogs with a shared convention, not a single monitoring platform.

Evidence before "done"

The phrase "it works" is where a lot of agent output becomes useless. Works where? With what data? On which screen size?

Our acceptance standard is deliberately boring:

• Lint, type checks, and the test suite, run against the exact tree being reviewed.
• A production build, not only a development server.
• The real server, with the real security policy, serving the built output.
• A browser check at phone, tablet, and desktop widths, with screenshots kept as evidence.
• The specific behaviour in the request, exercised the way a user would.

For this website, that means the exported static build is served by the actual Bun server with its content security policy in place, then inspected at 390, 768 and 1440 pixels. A page that renders in a development server and breaks under the real policy is not done. A diagram that fits at desktop width and overflows on a phone is not done.

The same discipline applies outside code. A research claim needs a source that supports the claim itself; that the link returns 200 is link hygiene, not evidence. A "verified" integration needs a call that succeeded, not a configuration key that exists. A summary of a meeting needs the decision and the owner, not a pleasant paragraph.

This is also where the agent is most useful and most dangerous. It is good at producing evidence, and it is good at producing the appearance of evidence. The only reliable separation is a reviewer who reads the command and its output.

Publishing and deploying: authority before the last mile

A release is not a bigger version of a commit. It is a moment where the work becomes visible to other people.

Our publishing path is the same loop with stricter gates: content is reviewed for accuracy and confidentiality, the site is built, the built output is served exactly as production serves it, the pages are inspected in a real browser, links are checked, and the release goes out inside the scope the owner already authorized.

That last part is easy to misread as a person standing over every deploy. It is not. The owner sets the authority, sometimes in advance and in writing: this article, this standard, this site, ship it when the evidence holds. Within that authority the lead agent reads the piece itself, checks the claims against their sources, runs the privacy pass, re-runs the acceptance steps and ships. What comes back to a person is a change in kind, not a habit: new scope, new risk, an irreversible step, or a decision we have deliberately reserved.

Hermes itself is built with that boundary in mind: dangerous commands require approval, and unattended runs — scheduled jobs, one-shot queries, webhook sessions — can be configured to refuse rather than auto-approve.[8]

So a merge, push or deploy does not happen because an agent finished. It happens because the work stayed inside an authorized scope and the evidence passed review. When either of those is unclear, the work stops and the question goes to the owner.

Communication: one clear ask

Hermes can run behind a messaging gateway, so the same agent is reachable from a chat app rather than only a terminal.[9] For a small team this is less about novelty and more about latency: a question answered in the channel where the work is already being discussed does not wait for someone to open a laptop.

The discipline is in what gets sent.

• A digest is not an interruption. Routine status belongs in a summary someone reads when they choose.
• An escalation is a request. If it needs a person, it says what decision is needed and what happens if no one answers.
• Silence is a feature. A watch that pings on every tick is a watch nobody reads.

We keep a notification gate that can suppress low-value messages, but we do not claim every message passes through it; some paths send directly. The safer operating rule is the one we actually follow: notifications are written by a person's standards even when they are sent by a machine, and anything requiring authorization is explicit.

Status, honestly

A snapshot, not a roadmap. "Active" means we have seen it run; "on demand" means it is available and used when a procedure calls for it.

Scroll horizontally to see all table columns →

We could make this table look more impressive by blurring "on demand" into "automated." We would rather keep the distinction, because it is the difference between a system you can reason about and one you have to hope about.

What people still own

It is tempting to describe an agent-operated business as a stack of automations with a human at the end. In practice the human authority is distributed, and it is specific:

• Permissions. Who can read what, which credentials exist, which systems the agent may touch.
• Money. Anything that spends, commits, or prices.
• Client commitments. What we promise, to whom, and by when.
• Irreversible and out-of-scope actions. Destructive deletes, migrations that cannot be rolled back, public statements, and any release that exceeds the authorized scope or cannot be undone.
• Value. Whether the work is worth doing at all, and whether it is good enough to show.

Hermes is good at proposing a plan, executing the reversible parts, and assembling the evidence. It is not the owner of any of the five items above, and our procedures say so explicitly.

Where it goes wrong

An honest account needs the failure modes, not just the wins.

Confident summaries. A helper's report can be wrong in the direction of success. The lead's re-run is the correction.

Stale context. A code map, a memory entry, or a skill can describe last month's system. Freshness has to be checked, not assumed.

Over-alerting. A noisy watch is worse than no watch, because it teaches people to ignore the real one.

Context loss. Long tasks compact, and compaction can drop detail the task still needs. The mitigation is scoped briefs and checkpoints, and reloading the original evidence rather than trusting a summary of it.

Cost of parallelism. More helpers means more coordination, more review, and more surface area. Parallelism pays when the pieces are genuinely independent, and costs when they are not.

Procedure drift. Written steps drift from real steps. The fix is the same as for code: verify against the executable path, and correct the document.

They are ordinary failure modes of delegation, and they are why the loop has a reviewer in it.

If you want to try this

Start small.

1. Pick one recurring task you already know how to judge. A weekly report, a release checklist, a research brief.
2. Write the procedure down, including what "done" means and what evidence proves it. This is the skill.
3. Run it with a person reviewing every output. Correct the procedure, not just the result.
4. Add a check that fails loudly — a test, a link check, a required source.
5. Only then put it on a schedule, and make it quiet when nothing is wrong.

Order matters: automation applied to an undefined process produces undefined results faster.

The point

The value of Hermes in our operation is not that it works without us. It is that more of our work now has a written shape: a scope, a brief, a piece of evidence, a review, a release inside an authorized scope. The agent carries the shape from task to task, which is exactly the part people are bad at when they are busy.

The model is replaceable. The loop is the asset.

Let the agent do the work. Keep the evidence in view. Keep the decisions with people.

Implementation and source notes

The operating description above comes from a read-only review of our active skills, delegation configuration, memory files, scheduled jobs, and the executable paths behind them, alongside the public Hermes documentation. Status labels reflect what we could observe in October 2026. Where an older note disagreed with the running system, the running system won. No private repositories, credentials, client records, or internal inventories are reproduced here, and the diagrams are original illustrations.

The references describe the framework and tools, not an audit of our deployment.

Sources

[1] https://hermes-agent.nousresearch.com/docs

[2] https://hermes-agent.nousresearch.com/docs/user-guide/features/skills

[3] https://hermes-agent.nousresearch.com/docs/user-guide/features/memory

[4] https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation

[5] https://hermes-agent.nousresearch.com/docs/user-guide/git-worktrees

[6] https://docs.typesafe.ai/concepts/system-one

[7] https://hermes-agent.nousresearch.com/docs/user-guide/features/cron

[8] https://hermes-agent.nousresearch.com/docs/user-guide/security

[9] https://hermes-agent.nousresearch.com/docs/user-guide/messaging