Skip to content

■ ARTICLES // EDITORIAL

hermes field note: the local operator stack

a sunday field note on the stack beneath a personal agent: claude as executor, hermes/network.self.md as harness, and local tools as custody.

[!] ON THIS PAGE

this week made the personal agent stack feel less like a thesis and more like a chore list.

not in a bad way. chore lists are underrated. a stack becomes real when it stops being a diagram and starts asking for boring operator work: check the executor, inspect the harness, verify the local runtime, read the audit trail, decide what gets to run next.

the cleanest version of the week is three columns:

layerjobfailure mode
executordo the next steptreats motion as judgment
harnessdecide what deserves a stepbecomes invisible until it fails
custodydecide what leaves the machinegets ignored because it is not flashy

claude is the executor. hermes is the harness. local tools are custody.

that sentence is the whole field note.

the executor is supposed to move

an executor should be fast, slightly dangerous, and easy to interrupt.

that is why claude code works for this layer. it can inspect a repo, edit files, run tests, make a plan, accept a correction, and keep moving. when the job is concrete — fix the build, draft the page, compare the diff, run the checker — the model should not be philosophizing about agency. it should ship.

but an executor should not decide what deserves to exist.

that distinction is easy to lose because chat makes everything look like one surface. the same box receives the idea, writes the code, explains the result, and asks for the next step. after a while the UI tricks you into thinking the executor is the operating system.

it is not. it is a worker standing near the control panel.

that is why the earlier pieces in this cluster start with the control surface before the agent romance. claude code session preflight is about checking what contract the executor is running under. claude code workflow files is about the instructions that survive the chat. agent verification loop is about not believing the executor just because it sounds confident.

move fast, yes. but move inside a frame.

the harness decides what deserves work

hermes is the frame i use around the executor.

publicly, the important part is not the brand name. the important part is the role: a harness is the layer that carries memory, policy, identity, audit, queueing, and operator attention. it is where the agent stops being a clever tab and starts becoming a system you can leave running without turning your life into incident response.

network.self.md is the state layer inside that idea. the point is simple: agents need more than messages. they need state they can read, write, join, refuse, audit, and expose safely.

that is the reason agents need states, not chats is the closer for the week. chat is a fine human surface. it is a terrible source of truth. it does not know which peers exist, which rooms are public, which sender is trusted, which action was denied, which message was queued, or which decision needs the operator.

state does.

in practice the harness has a few boring jobs:

  • keep identity separate from vibes;
  • make public discovery explicit instead of accidental;
  • route incoming work through one policy gate;
  • write metadata-only audit before side effects;
  • keep the ask/ignore/enqueue decision visible;
  • give the operator a dashboard that answers “what is alive, what is waiting, what just happened?”

none of this looks like the future in a launch video. it looks like plumbing. good. plumbing is what lets the future take a shower.

custody is the quiet power layer

local tools are not just cheaper inference. that framing undersells them.

local tools decide custody: what stays on the machine, what gets summarized before it leaves, what can run while the network is bad, what can survive a restart, what can be inspected without asking a vendor for permission.

ollama sits in this week’s queue because it is one of the simplest ways for a builder to make a local model addressable from real tools. not because every task should run locally. that is cosplay. the useful question is narrower: which bytes should not leave this machine until the operator says so?

voice capture, OCR, local documents, private notes, drafts, receipts, long-running memory — those are custody questions before they are model questions.

custody also changes the mood of the stack. a cloud model feels like renting intelligence by the minute. a local runtime feels like owning part of the workshop. you still rent plenty. but the workbench is yours.

the one-screen version

if i had to explain the whole week to another operator, i would put this on one screen:

questionexecutor answerharness answercustody answer
what should happen next?“i can do this step”“this step is allowed / blocked / needs Ray”“this data may / may not leave”
what changed?diff, draft, command outputstate transition, policy verdict, queue itemlocal artifact, cached source, runtime state
can we trust it?only after verificationonly if audit and policy agreeonly if source bytes are inspectable
what breaks first?hallucinated completionhidden permission driftsilent leakage or lost local state

this is why the control surface is the product matters. the model is not the product. the stack of decisions around the model is the product.

the sunday checklist

this is the actual ritual i want, not a motivational poster:

  • check what executor version and permissions are active;
  • read the workflow files the executor will obey;
  • inspect the harness dashboard before accepting new work;
  • scan the last policy decisions: enqueue, ignore, ask;
  • verify that public discovery only exposes what should be public;
  • check which local runtime owns sensitive work this week;
  • run one real verification loop before trusting a claimed result;
  • write one sentence: “what did the harness refuse to let the executor do?”

that last line is the important one.

if the harness never refuses anything, you do not have a harness. you have a decorative dashboard around a yes-machine.

the point of hermes

hermes is not here to be another chat app.

it is here to make the agent boring enough to trust: persistent state, explicit policy, visible queues, public/private boundaries, and a small surface where the operator can see what is happening without reading a transcript like tea leaves.

that is less glamorous than “autonomous agent.” good. glamorous agents create demos. boring harnesses create compounding systems.

this week’s pieces are the public parts of that stack:

hermes is the field note underneath them: the thing that decides what deserves the executor, what deserves custody, and what deserves a hard no.