A useful practitioner rule for Hermes is to avoid designing a specialist agent in the abstract. Start inside the main agent or orchestrator, run the workflow repeatedly, correct drift and mistakes, and extract a specialist only after the behavior becomes stable.
The often-cited range of four to ten guided runs is a field heuristic, not an official Hermes guarantee. The valuable part is the sequence:
- let the general agent encounter the real task;
- preserve the inputs, decisions, failures, and corrections;
- identify the parts that recur;
- turn those parts into instructions, tools, checks, and a narrow output contract;
- keep a route back to the orchestrator for exceptions.
Why this is better than naming roles first
A role such as “research agent” or “review agent” says almost nothing about what good work looks like. Repeated runs expose the actual boundary: which sources are acceptable, which decisions need a human, which errors recur, and what evidence proves completion.
Specialization is therefore a compression step. The agent is promoted from observed work rather than invented from a title.
New Runtime Read
This is directly applicable to the newsroom. The X bookmark processor, primary-source resolver, site materializer, R2 backup, and OpenClaw handoff should first be run as one observable workflow. Once the same repair pattern appears several times, that repair can become a specialist skill with fixtures and acceptance checks.
The promotion gate should not be “it worked once.” It should be:
- the task boundary is stable;
- drift has named failure modes;
- the output is machine-checkable;
- retries are idempotent;
- escalation to the owner or orchestrator is explicit.
The specialist agent is not a smaller personality. It is a tested operational contract.
