field guide · anatomy

Anatomy of a harness

An agent harness is the vessel around a model: everything that turns "a model that answers" into "an agent that is allowed to act, on your machine, under your rules, and can be stopped". This board names every organ a properly engineered harness needs, why it exists, what breaks without it, and where it lives in the code. Click any piece.

one message, end to end
Inbound arrives on a channel and passes the sender gate Gateway routes it to a profile and journals the run Loop assembles context and calls the model Kernel charges the budget and checks guards before every step Tools pass floors, allowlist, approval, sandbox, egress Memory keeps pins and episodes; the reply is journaled, then sent
Learn: read what each organ is and why. Self-check: tick the requirements you can prove in your own harness.

What a harness must have from birth

Distilled from running four earlier harnesses in production (Corvin on OpenClaw, three Hermes profiles on Mars, the Mercury task engine, OrmusClaw). Each line is a scar, not a feature request.

  1. Workspace as readable files, with one source of persona truth, not two.
  2. Handbrake-first autonomy: E-STOP, auto-trip and loop-safe failure handling before any scheduler ships.
  3. Per-profile credentials with an owned lifecycle; tokens never inside the agent's reach.
  4. Default-on watchdog per profile. A silent dead agent is the worst outcome.
  5. Verification tools for claims about the world; never adjudicate from log inference.
  6. Alert lane and conversation lane separated; an alert can never trigger a reply.
  7. State is a directory: decommission means stop the service and archive the folder.