DEV Community: AskClaw

How I Use Hermes Agent to Run an Agent Team

AskClaw — Sat, 30 May 2026 11:36:31 +0000

My problem

I run more than ten Hermes agents across several servers.

That sounds powerful.

I also got a real headache.

Some agents write code. Some review project state. Some watch for problems. Some help me decide what to do next.

This is useful. It is also a lot to manage.

The hard part is not asking an agent to do work. The hard part is knowing:

which agent owns a task,
which server is safe to use,
which model account still has room,
which reminder matters,
what I should do next.

I have ADHD. Too many open loops can turn a good agent setup into stress.

So I use Hermes Agent as my control plane.

By "control plane", I mean the place where I check state, make a choice, and pick the next safe action.

The simple idea

My control plane is mostly Markdown files.

I call them anchors.

An anchor is a small control sheet. It stores facts that should not live only in chat history.

An anchor can track:

current projects,
agent owners,
server roles,
model capacity,
blockers,
review dates,
the next small action.

This sounds boring. That is the point.

Boring files are easy to read. They are easy to update. They are easy for Hermes to use in the next session.

Without anchors, each chat has to rebuild the world. With anchors, Hermes can check the files, update them, and give me a short answer.

The goal is not more notes. The goal is less load on my brain.

The loop

The loop looks like this:

me on Telegram
  ↓
Hermes Gateway
  ↓
Claw, one of my Hermes agents
  ↓
SSH checks over Tailscale + files + cron + memory + skills + session search
  ↓
Markdown anchors
  ↓
short report: best pick, blocker, next action

Hermes Agent works well here because it is not just chat.

It can use tools. It can read and write files. It can run shell commands. It can run cron jobs. It has memory. It can search old sessions. It can use skills.

That mix makes it useful for daily ops.

One boring but important piece is Tailscale.

My agents and servers are not all on one public machine. Tailscale gives them a private network with stable names and safe access paths. That makes managing many agents much easier:

I can SSH to worker nodes without opening extra public ports,
agents can use private host names instead of fragile public IPs,
a new worker can join the tailnet and become usable quickly,
access can be limited with ACLs,
redaction is simpler because public examples can use fake node names.

For me, Hermes is the control plane and Tailscale is the private road between the machines.

Example 1: choosing where to run long AI work

I often ask:

codex status?

Hermes checks several worker nodes. It reads the live model limits. It updates the capacity anchor. Then it gives me a short routing answer.

Here is a redacted example:

Best pick: node-c
Fallback: node-d

- node-a / control-node / account-a
  GPT-5.5: 33%, reset 20:14
  Spark: 91%, reset 6/3 14:57

- node-b / worker-node / account-b
  GPT-5.5: 12%, reset 20:13
  Spark: 100%, reset 6/6 02:11

- node-c / worker-node / account-c
  GPT-5.5: 75%, reset 5/31 10:52
  Spark: 100%, reset 6/6 02:11

- node-d / worker-node / account-d
  GPT-5.5: 66%, reset 23:30
  Spark: 100%, reset 6/6 02:11

The key part is "Best pick" at the top.

I do not want a wall of data. I want the choice first, then enough proof to trust it.

Example 2: quiet checks

I also use Hermes cron jobs for checks that should stay quiet when all is well.

A security check might look at:

service status,
rule files,
log size,
lost events,
free disk space,
SSH access.

If all checks pass, it sends nothing.

If something is wrong, it sends a short alert:

auditd watchdog

node-c:
- audit log is too large
- next: rotate the log and check auditd again

This matters.

If a reminder says "all good" every day, I learn to ignore it. Quiet success saves attention for real problems.

Example 3: agent ownership

When many agents work at once, ownership can get messy.

So I keep a small registry:

Claw
- Role: control plane, QA, memory keeper, ops helper.
- Work: maintain anchors, route model work, read monitoring reports.

Builder Agent
- Role: main builder for project-alpha.
- Rule: Claw can inspect and report, but should not take over unless asked.

node-c / worker-node
- Role: best node for long work right now.
- Note: check ownership before touching active project folders.

This stops a common problem: two helpful agents changing the same repo because nobody wrote down who owns it.

The ADHD part

A good Claw report is small:

Answer first.
Evidence second.
Blocker only if real.
One next action.

This is not just style. It is part of the system.

For me, support means:

do not make me choose from ten options,
do not hide the blocker,
do not send reminders that do not change what I do,
do not ask me to remember what the agent can write down,
do not turn every status check into a dashboard review.

Hermes can take on a lot of that load.

Try the smallest version

You do not need ten agents to use this idea.

Start with one file:

# agent-team-anchor.md

## Current owner
Claw

## Active agents
- Builder: owns project-alpha
- Reviewer: reviews pull requests only
- Ops: checks servers and cron

## Safe next action
Ask Claw to summarize blockers and pick one next step.

## Do not touch
- active production deploys
- repos owned by another agent

Then ask Hermes:

Read agent-team-anchor.md.

Update stale facts if needed.

Tell me:
1. best next action
2. real blocker, if any
3. which agent owns the work

Keep it under 8 lines.

That is the smallest version of my control plane.

What I learned

Agents need anchors

If an agent only uses chat history, it will miss things. Put the current state in a file.

Memory needs a place

Not every fact belongs in long term memory.

I split it like this:

user preferences go in memory,
live project state goes in anchors,
repeat steps go in skills,
old chat context stays in session search.

That keeps memory clean.

Cron should be quiet

A cron job should help me act. If it has nothing useful to say, it should stay silent.

Redaction is part of the work

I do not publish real host names, account names, IPs, tokens, or private project names.

The public examples keep the shape of the work, not the private details.

A short message can be better than a dashboard

Dashboards are good when I need to dig.

For daily work, a short message is often better:

Best pick: node-c.
Blocker: node-b is low on capacity.
Next: send long work to node-c.

What I would improve next

I want to make the anchor files easier to check.

Next steps:

add simple schema checks,
improve the redaction script,
mark stale anchors,
make a small public example page,
export safe reports for future posts.

I would still keep Markdown as the base.

A human should be able to open the file and understand what is going on.

Disclosure and credits

I wrote this article with help from Hermes Agent itself.

The examples are redacted from a real workflow. I changed host names, account names, IPs, session IDs, and project names.

Hermes Agent is an open source project by Nous Research. Claw is my own way of using Hermes Agent as a daily control plane.

Final thought

Hermes did not give me more agents.

It gave me a way to see what my agents are doing.

The agents check, write, route, remember, and report. I still choose what matters, what is safe, and what should happen next.

My headache is getting better.

That is the difference between having many agents and having a working agent team.

Supply Chain Security: 4 Commands That Would Have Stopped the axios and litellm Attacks

AskClaw — Tue, 31 Mar 2026 09:56:20 +0000

Supply Chain Security

"Classical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated — I've been increasingly averse to them, preferring to use LLMs to 'yoink' functionality when it's simple enough."
— Andrej Karpathy

He's right. And this week proved it again.

What Happened This Week

Two major supply chain attacks, seven days apart:

axios (npm) — March 31, 2026
Malicious versions 1.14.1 and 0.30.4 published via compromised maintainer credentials. A postinstall script silently dropped a RAT, called home to a C2 server, then self-destructed — leaving no trace in node_modules. Millions of developers had "axios": "^1.13.0" in their package.json. The ^ did the rest.

litellm (PyPI) — March 24, 2026
Version 1.82.8 compromised. Exfiltrated: SSH keys, AWS/GCP/Azure credentials, Kubernetes configs, environment variables, shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords. 97M downloads/month. Only caught because the malware had an OOM bug that crashed a developer's machine. A cleaner attack would have run undetected for weeks.

The common thread: both attacks lived entirely in install scripts. One flag stops both cold.

The Fix (4 Commands + 1 Config)

Copy these into your project. You're done.

# 1. Never let install scripts run
npm ci --ignore-scripts

# 2. Pin exact versions — strip all ^ and ~ from package.json
#    "axios": "^1.13.0"  →  "axios": "1.13.0"

# 3. Age-check before installing anything new — don't touch < 7 days old
npm view <package> time --json | python3 -c "
import json, sys
from datetime import datetime, timezone
times = json.load(sys.stdin)
latest = max(times.items(), key=lambda x: x[1] if x[0] not in ('created','modified') else '')
published = datetime.fromisoformat(latest[1].replace('Z','+00:00'))
age = datetime.now(timezone.utc) - published
print(f'Latest: {latest[0]}, published {age.days}d ago')
"

# 4. Audit known CVEs on every CI run
npm audit --audit-level=high

Bonus: lock it all in with one .npmrc — commit this to your repo:

# .npmrc — commit this file
ignore-scripts=true       # blocks all postinstall RATs
save-exact=true           # forces exact pins on npm install (no ^ added automatically)
min-release-age=7         # npm v11.10.0+ only — blocks packages < 7 days old

Three lines, committed to the repo. Every developer, every CI run, every npm install — protected by default. No discipline required.

⚠️ min-release-age requires npm v11.10.0+ (Feb 2026). Check with npm --version. On older npm, use the age-check script above manually.

⚠️ Security patch override: when you need to fast-track a verified CVE fix, temporarily override with npm install <pkg>@<version> --ignore-min-release-age (npm v11.10.0+) or remove the line, update, then restore it.

Why Each One Matters

1. `--ignore-scripts` (or `.npmrc`)

The entire axios and litellm attack delivery mechanism was a postinstall script. This flag disables preinstall, install, postinstall, preuninstall, and postuninstall for all packages. The payload never executes.

The .npmrc config bakes this into the project permanently — you don't need to remember the flag, and new contributors get the protection automatically.

⚠️ Caveat: packages that compile native addons (e.g. node-gyp, bcrypt) need install scripts. For most web projects: safe.

2. Exact version pins

// ❌ This silently upgraded thousands of projects to axios@1.14.1
"axios": "^1.13.0"

// ✅ This doesn't move without an explicit commit
"axios": "1.13.0"

^ means "any compatible version." In practice it means "pull whatever the maintainer published today." Remove it everywhere.

3. The 7-day rule

Both attacks were caught within hours — but that was luck. Sloppy malware. A competent attacker builds in a delay before the payload activates. The 7-day window filters out rushed attacks. 48 hours catches the sloppiest. 7 days catches most of the rest.

Update type	Wait
Feature / minor update	7 days
Verified security patch for known CVE	ASAP
Package you've never used before	7 days minimum + manual review

4. `npm audit`

This catches known CVEs — it won't catch a zero-day attack like axios. But it catches the long tail of everything else. Run it in CI. Block merges on --audit-level=high.

Why Standard Tools Missed This

Tool	Why it failed
Trivy, Grype, OSV-Scanner	Scan for known CVEs — zero-day has no CVE yet
Renovate / Dependabot	Would have automatically pulled in the malicious version
Snyk	Same — no CVE, no signal
Socket.dev	Closest to catching it — behavioral analysis flags suspicious new publishes

What actually caught the axios attack: runtime network monitoring (StepSecurity Harden-Runner) spotted the C2 callback during a CI run. The malware called home. That's the only reason we know.

The Deeper Fix: Fewer Dependencies

This project (creem-worker) uses zero npm dependencies by design. Pure Node.js. If the runtime provides it, we use it. If it doesn't, we write 20 lines instead of pulling in a library.

Every dependency is a permanent bet that its entire supply chain stays clean — forever. Maintainer accounts get compromised. Packages get abandoned and re-registered. CI pipelines pull from npm at 3am when nobody's watching.

The safest dependency is the one you never added.

When an LLM can write the function in 5 minutes, that's almost always the better call.

Quick Checklist

[ ] .npmrc committed to repo (ignore-scripts=true, save-exact=true, min-release-age=7)
[ ] npm ci --ignore-scripts in all CI pipelines (belt + suspenders)
[ ] No ^ or ~ in package.json dependencies
[ ] Don't install packages published < 7 days ago
[ ] npm audit --audit-level=high gates CI

If You've Already Been Hit

A developer whose team used APIFOX (also compromised this week) laid out what's actually at risk after a supply chain attack. It's not just your code:

Rotate immediately:

[ ] All SSH keys on every server
[ ] All API keys in .env files, CI/CD secrets, and config files
[ ] Exchange API keys — set withdrawal disabled + IP whitelist on every exchange
[ ] Browser sessions — sign out everywhere, clear cookies, revoke OAuth tokens
[ ] Any token that was ever in an environment variable or clipboard

Crypto-specific:

Private keys should never exist in plaintext on any server — if they do, assume compromised
Exchange API: attacker can drain funds via wash trading even with withdrawal disabled — monitor for unusual trading activity
SSH keys give attackers a way around IP whitelists — treat SSH key theft as full server compromise

For next time:

Local dev: only use test API keys, never production keys
SSH: use a passphrase + consider a bastion/jump host
Browser: enable 2FA/MFA on everything that touches money or infra

The attack surface isn't your code. It's everything your code touches.