hermes research decision-grade Pattern A+B mixed — single trial Fleet-wide adoption arc · 2 sub-agents + main-thread synthesis · 4 deliverables

T2 — Nous Hermes-Agent — Fleet-Wide Capability Profile

Companion: T1-pantheon-scheduling-stack.md (mirror axes for matrix join in T3). Source: viska-autoresearch T5/T6/PHASE2/DECISIONS + machine-report (K20N0S Hermes live) — no firecrawl extension required. Lens: fleet-wide adoption candidate evaluation. NOT viska-specific.

Reframing from viska arc

Viska arc (T5/T6/PHASE2/DECISIONS) scoped hermes-agent as a single-client autonomous research substrate. Fleet-wide reframe shifts the question from "can it host one client agent" to "can it host one of N executor roles inside a multi-tenant Pantheon constellation."

Carries forward unchanged: - 5 mandatory guardrails (PHASE2 §guardrails): pin tag, OS-sandbox, Pantheon-only skills, mirrored fork, 4–8 wk hook half-life. - SECURITY.md "only boundary is OS" (T5 §security-posture §2.2). Implementation gap: in-process plugins/skills/hooks run with full agent privileges. - Bus factor 1+ (teknium1 4,712 commits vs #2 660) + weekly v0.x cadence (T5 §release-pattern). - D11 strict-isolation directive — Pantheon-authored only, agentskills.io blocked at Envoy. - D10 hardened Docker Compose stage-1, OpenShell stage-2.

Reframes for fleet: - Viska = ONE client deployment. Fleet = multiple agents (atlas/hermes/plutus/proteus/...) potentially using hermes-agent as a shared scheduling executor on K20N0S. Tenant boundary moves from viska to <agent-name>. - D11 ceiling "Pantheon-authored only" now means fleet-Pantheon (cross-agent shared skill registry), not viska-Pantheon (per-client siloed registry). Wider skill author surface, same trust ceiling. - Hermes-on-K20N0S is already live (machine report: launchd-managed, OpenRouter deepseek-v4-pro, LAN-only, Slack delivery active). Fleet adoption is not greenfield — it's role-promotion of an existing process. - Fleet role candidates for hermes-agent: (a) scheduling executor (alongside launchd/n8n/Mastra), (b) autonomous-research agent (Ralph loop), (c) supervisor/orchestrator, (d) delivery surface (Slack gateway already covering this). Different roles fit different axes — score against PRIMARY-role-as-scheduling-executor for T3 matrix-join.

Surface inventory (capabilities covered)

Per T5 §release-pattern, T6 §extensibility-inventory:

Gateway: launchd-managed daemon on K20N0S (machine report). Slack/Discord/Telegram/Teams native, plus 18 other messaging surfaces (T5 §release-pattern v0.14 headline).
/goal Ralph loop: persistent goal pursuit across turns; checkpoints v2 (T5 §release v0.13 Tenacity).
Cron subsystem: skill-injection scheduling primitive (T1 D9 §architecture — "Hermes cron jobs.json"); built-in scheduled-task primitive (T6 row 19).
Plugins: Python modules at ~/.hermes/plugins/<name>/, 5+ hook types (T6 §extensibility): pre_tool_call (veto), pre_llm_call (context-inject append-only), transform_tool_result, transform_llm_output, transform_terminal_output, pre/post_api_request, on_session_start/end, plus gateway-only hooks (agent:step, session:start/end/reset, command:*).
MCP client: stdio + StreamableHTTP, env-filtered subprocess, credential redaction on errors, per-server sampling opt-out (T6 §extensibility row "MCP client").
Subagent delegation: delegate_task with own provider/model chain, isolated context (T6 #1 dual-LLM sketch).
Memory provider: 8 in-tree (Honcho, Mem0, Hindsight, Holographic, ...). D12 picks Holographic (local SQLite) for viska Tier-1; fleet-wide pick TBD per agent.
Programmatic surfaces: ACP, TUI gateway JSON-RPC, OpenAI-compat HTTP+SSE proxy (T5 §release v0.14 "OpenAI-compat proxy").
22 messaging platforms / 18 delivery surfaces: Slack already-live K20N0S; Telegram/Discord/Teams/Matrix/IRC/SMS/email available (T5 §release v0.14, T6 inventory).
Skill ecosystem: agentskills.io public registry + Pantheon-only allowlist per D11. Skill format = markdown + scripts, more stable than Python plugin API (T5 §plugin-API-stability).

Axis profiles

Scoring: 0 = not supported, 1 = barely, 2 = workable with friction, 3 = solid, 4 = strong, 5 = best-in-class.

Axis 1 — Triggering modes

Executor	cron	event	manual	conversational	file-watch	score	note
nous-hermes	✓ (cron subsystem, native skill-injection scheduler)	✓ (22 messaging-platform inbound events, gateway hooks, HTTP gateway, MCP server-side triggers via sampling)	✓ (CLI invoke, TUI gateway JSON-RPC, OpenAI-compat HTTP+SSE, ACP)	✓ (Ralph `/goal` loop autonomous re-triggering across turns; conversational schedule-modify forbidden fleet-wide per T1 invariant 6)	✗ (no native; could be plugin via `pre_tool_call` + inotify subprocess)	4	Broadest single-process surface. Cron + gateway-event + ACP + HTTP + Ralph. Conversational schedule-mutation primitive present but MUST be Hades-blocked per T1 invariant 6. src: T1 D9 §architecture, T5 §release v0.14 OpenAI-compat, T6 row "Gateway hooks"

Triggering-mode note: Hermes is the only candidate in the T1 matrix that natively supports BOTH cron AND conversational re-triggering AND HTTP-event ingress in one process. The Ralph loop is novel — it persists pursuit of a goal across LLM turns until completion criteria fire, effectively chaining executions without operator intervention. Fleet adoption converts this into a "long-running autonomous schedule" primitive that no other T1 executor offers. Risk: Ralph-loop runaway is real (operator anecdotes in T5 §production-deployments cite multi-hour runs); iteration-guard plugin (T6 #11) is the mandated countermeasure.

Axis 2 — Persistence + state durability

Executor	restart	reboot	sleep	state location	score
nous-hermes	✓ (launchd-supervised K20N0S)	✓ (launchd KeepAlive)	inherits launchd wake-catchup on macOS; cron-subsystem catchup semantics not documented	Hermes memory provider (Holographic SQLite on Railway volume per D12 / local FS); `~/.hermes/` config + `jobs.json`; gateway-state in-process	3 — durable via launchd wrapper, but Hermes-internal cron has no published catch-up semantics (gap vs launchd's wake-catchup primacy). src: D12 Tier-1 mount, T6 row "Memory providers"

Persistence note: Memory durability and schedule durability are two different surfaces. Memory provider (Holographic SQLite, D12 Tier-1) handles the Ralph loop's goal-state durability across process restart. Schedule durability (cron-table survival across reboot) depends on ~/.hermes/jobs.json being on persistent disk — which it is on K20N0S local FS, but Railway-container deployments need explicit volume mount. Gateway-state (active sessions, in-flight tool calls) is NOT durable — process restart drops in-flight Ralph iterations. For fleet posture: every long-running Ralph goal must checkpoint to Holographic at iteration boundaries; in-flight tool-call state is lost on crash. Mnemosyne-checkpoint plugin (T6 #22) is the mandated countermeasure for the latter.

Axis 3 — Tool surface

Executor	tool surface available at runtime	score
nous-hermes	Built-in tool set (web_search, web_extract, browser, terminal, execute_code, vision, voice, computer-use) + plugin-registered tools + MCP-client tools + skills + 22 messaging platforms + 8 memory providers + `delegate_task` subagents. Provider-routing layer with fallback chains per task.	5 — broadest in any candidate. src: T5 §release v0.14, T6 §extensibility-inventory

Tool-surface note: The breadth is both a feature and a fleet-adoption risk. Per-tool attack surface compounds — terminal + execute_code + browser + computer-use each have independent security envelopes. T6 threat-model rows TM-2/TM-3/TM-4 all assume the surface is minimized via per-tool veto (pre_tool_call allowlist), not native. For fleet adoption, a "scheduling-executor-role-only" deployment should aggressively disable tool surface (e.g., no browser, no computer-use, no voice/vision) via config to reduce attack surface. Compare to launchd (T1 axis-3 score 2, shell only) — Hermes ends up at launchd-level surface when locked down, but with hooks/plugins/MCP-client intact, which is the differentiation worth keeping.

Axis 4 — Cost model

Executor	cost	score (cost-efficiency)
nous-hermes	self-host on K20N0S ($0 hosting); LLM API pay-per-token (OpenRouter deepseek-v4-pro currently per machine report); Nous Portal default tier $23–55/mo light volume (D8); $200–400/mo stage-1 light, $900–1650/mo heavy (PHASE2 §cost-comparison); skill ecosystem free (MIT).	4 — comparable to other self-host stacks. Caveat: per-call LLM cost via provider, not flat. src: PHASE2 §cost-comparison, D8

Cost note: Per-call LLM cost is the dominant variable. Fleet adoption with N agents fanning out across one Hermes process aggregates cost into one OpenRouter account (or whichever provider); process-per-agent fanout splits into N quotas. D8's stage-1 stance of "Default tier (180 RPM), scale on telemetry" applies — but at fleet aggregate, 180 RPM may saturate sooner than single-client viska usage. Process-per-agent pattern also splits cost-attribution per agent, easier billing/chargeback per client engagement. Skill/plugin authoring cost is the hidden line item — 4–8 wk hook half-life means recurring engineering tax that compounds with number of authored plugins (see fleet-deployment §plugin-maintenance-budget).

Axis 5 — Isolation / sandbox posture

Executor	process	network	secret	tenant-boundary	score
nous-hermes	hardened Docker Compose stage-1 / OpenShell stage-2 (D10); default local backend "explicitly out-of-support" per SECURITY.md §2.2 (T5 §security-posture); `terminal.backend: docker` with `cap_drop:[ALL]`, no-new-privileges, pids-limit, tmpfs noexec (T6 row "Container backends")	application-layer website-blocklist + built-in SSRF guard (RFC 1918, link-local, cloud-metadata, CGNAT, redirect re-validation, fail-closed DNS) — T6 row "SSRF guard" + threat-model TM-7. NO network-layer egress allowlist — Envoy sidecar still mandatory (T6 #7, threat-model TM-4)	Bitwarden Secrets Manager built-in + Vault-adapter pluggable surface at `agent/secret_sources/`; MCP credential filtering (only PATH/HOME/USER/LANG/TERM/SHELL/XDG_* pass to subprocess); credential redaction on tool errors (`ghp_`, `sk-`, bearer, `token=`, `key=`, `password=`, `secret=`); execute_code/terminal env-strip on `KEY/TOKEN/SECRET/PASSWORD/CREDENTIAL/PASSWD/AUTH` substrings	per-process tenant by default — multi-agent coexistence INSIDE one Hermes process is NOT a built-in primitive. Plugins + delegate_task subagents can carve sub-tenants but trust still flows through main process privileges (SECURITY.md §2.4/§2.5 — in-process plugins run with full agent privileges).	3 — strong app-layer + container-layer, weak network-layer (Envoy still external), weak intra-process multi-tenant. src: T5 §security-posture, T6 §extensibility-inventory + threat-model

Isolation note: Hermes's SECURITY.md is the most honest in the candidate set — it names what is and isn't a boundary. The compensations (SSRF guard, hardline blocklist, approval modes, context-file injection scan) are real and reduce risk meaningfully (T6 threat-model rows TM-1/TM-2/TM-7 all move to "Lower"). But the in-process trust model means any plugin or skill compromise is full-agent compromise. K20N0S currently runs Hermes WITHOUT the Docker Compose wrap (machine report shows launchd-direct daemon on host). For fleet adoption, that posture must change — either wrap in Docker Compose per D10 stage-1, or accept that K20N0S Hermes runs at "out-of-support" posture per Nous's own §2.2.

Axis 6 — Observability

Executor	logs	traces	rule-18 evidence integration	score
nous-hermes	built-in `observability/langfuse` plugin (per-turn / per-LLM-call / per-tool-call tracing); `pre/post_api_request` + `pre/post_tool_call` hooks = audit-trail substrate (T6 #8 sketch); per-call usage_pricing surface; gateway logs per platform	✓ first-class via Langfuse plugin + custom audit-trail plugin to separate Supabase	application-emitted via plugin authoring — `pre_tool_call` can capture entity_ids before tool dispatch, `post_tool_call` can capture commit_shas / api_acks; but deterministic evidence (rule-18 CHECK constraint requirement) depends on plugin discipline, not framework guarantee. No native `verification_evidence` JSONB writer like Mastra `writeRun` step.	3 — strong observability surface, but rule-18 evidence requires Pantheon-authored plugin (not free). src: T6 #8, T6 row "Built-in plugins"

Observability note: The Langfuse plugin is a working reference implementation — it proves the hook surface is sufficient to capture every LLM call + every tool dispatch with structured per-call observations including usage_pricing. Re-using its pattern, a pantheon-audit-trail plugin writing to fleet_schedule_runs.verification_evidence is ~3–5 days of work (T6 #8 effort estimate). The framework guarantee is absent, however — there is no enforced CHECK constraint inside Hermes that says "every tool call MUST emit evidence." Plugin discipline is the only guarantor. By contrast Mastra's writeRun step is deterministic by design — the Workflow shape forces it. For fleet adoption, the audit-trail plugin must be one of the first authored + must be Argus-monitored for plugin-disabled drift.

Axis 7 — Multi-tenant boundary

Executor	boundary	score
nous-hermes	per-process. One hermes-agent process = one tenant. Multi-agent coexistence (atlas + plutus + proteus tasks in one Hermes) requires plugins to gate per-call, NOT a built-in tenant primitive. Plugin-trust ceiling D11 (Pantheon-only) bounds the attack surface but does not enforce inter-agent isolation. For fleet-wide use, the natural pattern is one Hermes process per agent identity (multi-process fanout) — turns K20N0S into N processes.	2 — workable only via process-per-agent pattern; intra-process tenant boundary is convention, not enforced. src: SECURITY.md §2.4/§2.5 (T5), T6 §extensibility row "MCP credential filtering"

Multi-tenant note: This is the single most consequential axis for fleet adoption decision. T1 Routines scored 1 here for the same reason (per-operator-account collapse). Hermes scoring 2 instead of 1 reflects that plugins CAN carve sub-tenants — but the trust line is plugin-author discipline, not OS-enforced. Compare Mastra (T1 axis-7 score 4): per-Workflow tool-constraint = sandbox by construction. Process-per-agent on Hermes reaches Mastra-tier (estimated 4) at the cost of N× resource footprint + N× provider-routing configuration + N× plugin maintenance surface. T3 weighting must decide: is the per-process tax acceptable for the feature-ceiling-escalator benefit?

Axis 8 — Failure modes + auto-pause

Executor	retry	auto-pause	silent-stall risk	score
nous-hermes	per-tool retry within `delegate_task` ladder + provider fallback chain (T6 row "Fallback providers + auxiliary tasks"); approval-system fail-closed timeout (default 60s) on `approvals.mode: manual`; hardline blocklist refuses catastrophic commands regardless of approve flags	✗ native (no Inngest-style auto-pause-after-N-failures). Operator must build via plugin: `freeze-flag` plugin (T6 #20) checks Supabase status, vetoes all `pre_tool_call` when set; cron poller updates the flag. Out-of-the-box: kill-switch is `replicas: 0` (external) or operator-flipped flag (plugin).	medium — cron-subsystem catch-up semantics undocumented (Axis 2 gap); plugin-trust drift if hook contract changes between weekly releases (T5 §plugin-API-stability "low-to-moderate" 6mo confidence).	3 — solid app-layer, needs Pantheon plugins to reach fleet auto-pause posture. src: T6 #20, T5 §plugin-API-stability

Failure-mode note: Hermes inherits the same gap as the rest of T1 stack — no native auto-pause-after-N-failures (T1 §cross-stack-gaps gap 1). PRD §3 ladder (1 failure log → 2 handoff → 3 paused_by_failure=true + athena decision-request) compensates SSOT-side rather than executor-side. The freeze-flag plugin sketch (T6 #20) does the executor-side enforcement — pre_tool_call reads a Supabase flag and vetoes all tool dispatch when set. Cron-poll cadence matters: too slow = blast radius before freeze takes effect; too fast = Supabase load. Suggested baseline: 30s poll. Combined with Cerberus P-SCHED-5..8 probes, the failure-mode coverage approaches Mastra-tier (T1 axis-8 score 4).

Axis 9 — Learning / feedback loop

Executor	reflection step	learns from outcome rows	score
nous-hermes	Ralph `/goal` loop = native multi-turn reflection on goal progression (T5 §release v0.13 Tenacity); memory provider (Holographic) supports trust-scoring; agent-skills can be self-authored ("self-created skills cut research-task time by ~40%" — TokenMix benchmark, T5 §production-deployment-signals); checkpoints v2 enables loop-state replay	partial — reflection lands in memory provider but Hermes does NOT natively read `fleet_schedule_runs` to adjust cadence/retry/evidence-shape. Same gap as rest of T1 stack (T1 §axis-9 stack-level gap). Plugin path open via `post_tool_call` reading outcome rows + `pre_llm_call` injecting cadence-adjustment context.	3 — Ralph loop + checkpoints + self-authored skills move score above other executors; cross-executor `fleet_schedule_runs` learning still requires fleet-side plugin glue. src: T5 §release v0.13, T5 §production-deployment-signals Krzysztof benchmark

Learning note: This is where Hermes is genuinely differentiated. Most T1 executors are stateless invocations; Hermes ships a persistent goal-pursuit loop AND a self-modifying skill substrate AND a memory provider with trust-scoring. The TokenMix benchmark (~40% research-task time reduction via self-created skills) is the load-bearing external signal. For fleet adoption as the autonomous-research role (not the scheduling role), this is THE feature — no other T1 candidate touches it. But: self-modifying skill primitive collides with fleet invariant 6 (forbidding in-prompt schedule mutation). If "skills" can mutate their own scheduling, Hades-layer gating is mandatory before fleet adoption.

Axis 10 — Cross-machine + sleep/wake survival

Executor	wake catchup	cross-machine	needs always-on	score
nous-hermes	inherits host (launchd on K20N0S → macOS wake-catchup IF wrapped by launchd; Hermes-internal cron behavior on host sleep undocumented — assume silent skip without launchd wrapper)	✗ native — single-process, single-host. Multi-host means one Hermes per host coordinated externally. `fleet_schedules.executor_machine` field disambiguates (PRD §5, T1 §architecture-invariants).	K20N0S already configured no-sleep (machine report); other hosts would need same posture or launchd-wake-catchup wrapper	3 — strong on K20N0S-as-primary-host, weak on multi-host coordination; depends on launchd wrap for wake-catchup behavior. src: machine report, T1 axis-10 launchd row

Cross-machine note: This is the classic "scheduling executor needs a coordination story" axis. Routines (T1 axis-10 score 5) wins by being cloud — reachable from any Tailscale host. Hermes is single-host like launchd, n8n, CC Desktop, Mastra. The K20N0S no-sleep configuration is the load-bearing assumption — Hermes-internal cron has no documented wake-catchup, so any host sleeping mid-schedule loses the run. For fleet adoption beyond K20N0S (MacBook fleet, Mac Mini secondaries), the recommended pattern is to wrap Hermes invocations in launchd plists (Posture A from fleet-deployment considerations) so launchd's wake-catchup applies and Hermes runs as the execution payload, not the trigger.

Architecture invariants (carry-forward from viska arc, reframed for fleet)

Beyond the 5 mandatory guardrails (PHASE2), the following Hermes-specific architecture invariants survive the fleet reframe and constrain T3 weighting:

Pinned tag is non-negotiable. v2026.5.16 (v0.14.0) is the floor. D13 review-gated rolling means any fleet-wide upgrade requires plugin re-test + operator sign-off. No auto-pull from upstream. src: PHASE2 §guardrail-1, D13.
Skill ceiling is fleet-Pantheon-only. D11 maps to "block agentskills.io at Envoy" + "Hades CI signature gate on skill install" + "no community skills, no Nous-bundled outside Pantheon-reviewed subset." Fleet authoring is allowed across agent identities; external authoring is not. src: D11 enforcement bullets.
Mirror fork is fleet asset. One Pantheon-controlled namespace mirror serves all fleet hermes-agent deployments. main-tracking branch + fleet-stable branch (renamed from viska-stable for fleet scope). src: PHASE2 §guardrail-4.
In-process trust is full-privilege. Cannot be tightened from inside Hermes. Whole-process OS sandbox (D10 hardened Docker Compose stage-1) is the only boundary. Cross-agent identity isolation inside one Hermes process is NOT achievable via plugin discipline alone. src: T5 §security-posture §2.4/§2.5.
Envoy egress sidecar is mandatory regardless. TM-4 (LLM API as exfil) + TM-5 (tenant escape) close ONLY at network layer; Hermes contributes nothing here. Fleet adoption does not retire the Envoy line item. src: T6 #7 "MANDATORY".
Plugin contract has 4–8 week half-life. Every fleet-wide hardening plugin (audit-trail, research-fetch-allowlist, pii-tokenizer, iteration-guard, freeze-flag, mnemosyne-checkpoint, etc.) is on this clock. Maintenance budget is a fleet-tax line, not a one-off. src: PHASE2 §guardrail-5, T5 §plugin-API-stability.

Fleet-deployment considerations

K20N0S is already live. Machine report shows launchd-managed hermes-agent daemon, OpenRouter deepseek-v4-pro provider, LAN-only (no Tailscale exposure), Slack delivery active. Adoption is role-promotion of an existing process, not greenfield install. Constrains posture choices to "fits within current K20N0S envelope" unless Tailscale exposure is added later.
5 mandatory guardrails carry forward, re-scoped. "Pantheon-only skills" now spans fleet-Pantheon authorship (atlas/hermes/plutus/proteus shared registry) rather than viska-Pantheon (single-client). agentskills.io still blocked at Envoy. Mirror fork is fleet-scoped (one Pantheon-controlled namespace mirror), not per-client.
fleet_schedules.executor enum extension. Adding nous-hermes-agent as a fleet executor = enum value hermes + Themis parser case + one direct-write contract OR mastra-bridge-style endpoint. NOT a protocol rewrite (T1 §architecture-invariants invariant 7).
Rule-18 verification_evidence integration. Hermes plugin hooks (post_tool_call, transform_tool_result) CAN gather entity_ids/commit_shas/api_acks deterministically — but the framework does not enforce; Pantheon-authored verification-evidence-writer plugin needed (T6 #8 audit-trail pattern adapted for fleet-schedules). Without this plugin, Hermes-executed schedules cannot satisfy CHECK constraint (outcome != 'success' OR verification_evidence IS NOT NULL).
Coexistence with launchd. Two posture options: (A) launchd plist fires → POSTs to Hermes gateway HTTP endpoint (gateway = trigger ingress, Hermes runs as service); (B) Hermes cron skill schedules independently inside Hermes process (no launchd involvement per-schedule). (A) preserves launchd wake-catchup primacy; (B) loses it. Recommend (A) for fleet posture — keeps launchd as wake-catchup SSOT, Hermes as execution substrate.
Multi-agent coexistence inside one Hermes process is risky. Per Axis 7, plugin-trust ceiling does not enforce inter-agent isolation; the natural pattern is one Hermes process per agent identity. K20N0S running N hermes-agent processes (one per fleet agent) is feasible but adds resource footprint vs single shared process. Open question: is fleet adoption "one Hermes shared" or "N Hermes per agent"?
Provider-routing identity coupling. Hermes routes through one provider account per process (OpenRouter deepseek-v4-pro currently). Multi-agent fleet use where each agent has separate LLM quota/provider preference favors process-per-agent pattern (Axis 7 reinforcement).
Plugin maintenance budget is fleet-wide tax. D13 review-gated rolling cadence + 4–8 wk hook half-life means ~1–2h/wk plugin maintenance + monthly upgrade triage. Across fleet adoption, this scales with number of Pantheon-authored plugins, NOT number of agents using them. ~10 hardening plugins (T6) is the minimum floor; fleet-specific additions (verification-evidence-writer, fleet-schedules-trigger-adapter) add ~2–4 more.
Role-disambiguation matters for T3 scoring. Hermes-as-scheduling-executor (the role aligned with T1 matrix) has different requirements than Hermes-as-autonomous-research-agent or Hermes-as-supervisor or Hermes-as-delivery-surface. For matrix-join purposes T2 scores against the scheduling-executor role; but fleet adoption decision may favor a hybrid posture where Hermes occupies multiple roles and the matrix-join axis weighting must account for that. T3 weighting recommendation: score Hermes against scheduling-executor primary but flag axes where autonomous-research role would change scoring (Axis 9 jumps to 4, Axis 1 stays at 4, Axis 7 drops to 1 if shared-process).
Existing Hermes-on-K20N0S configuration is not D10-compliant. Machine report shows launchd-direct daemon, NOT inside Docker Compose. Fleet-adoption gate requires either (a) wrap K20N0S Hermes inside hardened Docker Compose first (D10 stage-1) or (b) explicitly accept "out-of-support" posture per Nous SECURITY.md §2.2 with operator-signed waiver. (b) is incompatible with D11 strict-isolation directive. Hades hardening pass required before fleet promotion.

Stack-level findings (5 bullets)

Hermes is a feature-ceiling escalator, not a scheduler. Cron subsystem exists, but the dominant value is the surrounding substrate (Ralph loop, 22 messaging platforms, 8 memory providers, MCP client, delegate_task subagent, OpenAI-compat HTTP gateway). For scheduling-only role, hermes-agent overshoots — launchd + n8n already cover that axis with less attack surface. Fleet adoption only makes sense if multiple roles consolidate into Hermes (executor + delivery + autonomous loop + supervisor).
Rule-18 evidence integration is plugin-authoring work, not free. Hermes has the hooks (post_tool_call, transform_tool_result, pre/post_api_request) but no native verification_evidence writer. Mastra Workflow (T1 axis-6 score 5) ships a deterministic writeRun step; Hermes requires Pantheon-authored verification-evidence-writer plugin to reach parity. Plug-and-play parity = ~3–5 days plugin dev per T6 #8 effort estimate.
Multi-tenant boundary is convention, not enforced. SECURITY.md §2.4/§2.5 names in-process trust as full-privilege. Multi-agent fleet use through ONE shared Hermes process collapses agent identity into the process owner — same failure mode as Routines (T1 axis-7 score 1, "per-operator-account"). Process-per-agent pattern fixes this at the cost of resource footprint + per-process provider configuration.
Network-layer egress is the unbridgeable gap. Application-layer website-blocklist + SSRF guard are strong, but TM-4 (LLM-API-as-exfil) and TM-5 (tenant escape) remain Envoy-or-equivalent dependencies. Same gap as every executor in T1 stack — Hermes does not improve here. T6 #7 names Envoy "MANDATORY" regardless of which runtime is picked.
Stability tax is real: weekly v0.x cadence + 0% LTS + ~165k LoC inserted in 9 days (v0.13→v0.14, T5 §release-pattern). Fleet adoption means continuous plugin re-test against rolling upstream. D13 review-gated rolling buys back determinism but requires operator gate per upgrade. Compare: launchd is 20yr stable, n8n monthly-stable, Mastra @1.35.0 (May 2026) on weekly cadence too. Hermes is on the fastest-moving end of the candidate set.

Adoption-vs-T1-stack net assessment

If fleet adopts hermes-agent as one more executor in the T1 enum, it joins as the broadest-surface (Axis 3 = 5, ties top tier), strongest-learning (Axis 9 = 3, top of stack), broadest-triggering (Axis 1 = 4, ties n8n). It is weakest on multi-tenant boundary (Axis 7 = 2, ties launchd + n8n at bottom of stack), weakest on persistence vs launchd's wake-catchup primacy (Axis 2 = 3), and inherits the same network-layer-egress gap as the rest of stack (Envoy still external). Five-axis weighted score depends on T3 axis weights — but on raw axis scoring, hermes-agent is roughly Mastra-tier (composite expected mid-3 to low-4) with different per-axis distribution.

Where it WINS vs T1 incumbents: - Ralph loop = unique autonomous-pursuit primitive (axis 9 leadership). - Skill ecosystem + 22 messaging platforms + 8 memory providers = highest feature ceiling per process. - Self-modifying skills primitive — both feature and risk (fleet invariant 6 needs Hades enforcement).

Where it LOSES vs T1 incumbents: - Persistence durability (Axis 2): launchd 5 > hermes 3 on wake-catchup primacy. - Observability + rule-18 evidence (Axis 6): Mastra 5 > hermes 3, because Mastra writeRun step is deterministic by design. - Multi-tenant boundary (Axis 7): Mastra 4 > hermes 2, because per-Workflow tool-constraint is enforced by Workflow shape. - Stability cadence: every other T1 executor has slower release cadence than Hermes weekly v0.x.

The adopt question, sharpened: Does the Ralph loop + memory provider + skill ecosystem + multi-gateway feature ceiling justify the per-process maintenance tax + plugin-discipline-required posture + 4–8 wk hook half-life + in-process trust model? Decision rests on whether fleet has a use-case that NEEDS the Ralph loop. If yes → adopt as executor for that role specifically, scope tight. If no → cheaper to stay with launchd + n8n + Mastra stack and skip Hermes.

Comparison highlights vs T1 stack

Quick read-out of where nous-hermes lands relative to T1 executors on key axes:

Axis 1 (triggering modes): nous-hermes ties n8n (T1 score 4) for breadth; both beat Routines (4), CC Desktop (2), launchd (2). Hermes wins on conversational-trigger via Ralph loop, loses to n8n on file-watch.
Axis 2 (persistence): nous-hermes (3) below launchd (5) and Routines (5); on par with CC Desktop (3) and n8n (3). Hermes-internal cron catch-up semantics undocumented = the gap.
Axis 3 (tool surface): nous-hermes (5) ties /loop (5) and n8n (5) for top tier. Larger plugin/skill surface than /loop; native model-agnostic LLM step (no /loop parity for that).
Axis 5 (isolation): nous-hermes (3) below Mastra (4) and Slack-as-surface (4). In-process plugin trust + missing network-layer egress are the gap. Same gap as everything in T1 stack.
Axis 6 (observability): nous-hermes (3) below Mastra (5). Hooks exist, evidence-writer doesn't — plugin-authoring tax.
Axis 7 (multi-tenant): nous-hermes (2) matches n8n (2) and launchd (2). Worst-in-class would require process-per-agent fanout to reach Mastra-tier (4).
Axis 9 (learning): nous-hermes (3) leads stack — Ralph loop + checkpoints + self-authored skills. Mastra (3) ties via reflection_text. Rest of stack at 0–2.
Axis 10 (cross-machine): nous-hermes (3) needs launchd-wrap for wake-catchup parity with native-launchd (4); single-host limitation matches all non-cloud executors.

Pantheon-authored plugin backlog (fleet adoption path)

Compiled from T6 §implementation-order + PHASE2 §updated-implementation-order, reframed for fleet (not viska):

#	Plugin	Hooks used	Effort	Fleet-scope notes
1	`pantheon-audit-trail`	pre/post_api_request, pre/post_tool_call	3–5d	Adapts Langfuse pattern. Writes to fleet_schedule_runs.verification_evidence + separate fleet-audit Supabase project. Ships first — every other plugin's evidence chains through it.
2	`verification-evidence-writer`	post_tool_call, transform_tool_result	2–3d	Specifically targets rule-18 CHECK constraint shape. Captures entity_ids/commit_shas/file_paths/api_acks/slack_message_ts per the PRD §6 schema.
3	`fleet-schedules-trigger-adapter`	on_session_start + custom HTTP gateway endpoint	3–5d	Themis-side: Themis reads fleet_schedules + posts to Hermes endpoint. Hermes-side: this plugin receives + invokes the cron skill. Adapter path A from fleet-deployment §coexistence.
4	`research-fetch-allowlist` + `fetch_research(domain_id)` tool	pre_tool_call + new built-in tool	1–2d	Per T6 #6. Allowlist queried from Supabase, cached per session. Replaces free-form URL fetches.
5	`pre-ingestion-sanitize`	transform_tool_result	1–2d	Per T6 #10. Zero-width strip + NFC + HTML-comment + CSS + aria-label + JSON-LD strip on every web_extract/web_search/browser_navigate result.
6	`pii-tokenizer`	transform_tool_result + transform_llm_output + on_session_start/end	3–5d	Per T6 #3. Fleet-scope tokenization rules may differ from viska's (client-name tokens etc). Schema lives in fleet_tokenization_policies.
7	`iteration-guard`	agent:step + pre_llm_call + on_session_start	3–5d	Per T6 #11. Ralph-loop runaway countermeasure — drift score + iteration cap. Mandatory fleet-side given Axis 9 autonomous-loop differentiation.
8	`entropy-anomaly`	post_api_request	1–2d	Per T6 #16. Outbound LLM prompt entropy baseline; alert on Nσ deviation.
9	`freeze-flag`	pre_tool_call + cron poll	1d	Per T6 #20. Supabase status check → veto all tool dispatch when flipped. Fleet kill-switch.
10	`slack-template-filter`	transform_llm_output	1–2d	Per T6 #21. JSON-Schema validation on Slack-delivery outputs.
11	`mnemosyne-checkpoint`	agent:step + agent:end gateway hooks	1–2d	Per T6 #22. Iteration-snapshot POST to Mnemosyne/Aion ingest.
12	`dual-LLM via auxiliary`	config + delegate_task pattern	1–5d	Per T6 #1. Quarantined LLM for ingested-content reasoning. Config-mostly.

Aggregate fleet-authoring effort: ~25–40 person-days (~5–8 weeks single-dev, ~3–5 weeks two-dev). All plugins enter the 4–8 wk hook-half-life maintenance cycle once shipped.

Source citation map

Quick-index of which inputs drove which axis/section, for T3 matrix-join verification:

Axis 1: T1 D9 §architecture, T5 §release v0.14, T6 row "Gateway hooks", T1 architecture-invariants invariant 6
Axis 2: D12 Tier-1 mount spec, T6 row "Memory providers", machine report
Axis 3: T5 §release v0.14, T6 §extensibility-inventory
Axis 4: PHASE2 §cost-comparison, D8
Axis 5: T5 §security-posture, T6 §extensibility + §threat-model rows TM-1..TM-7, D10
Axis 6: T6 #8 audit-trail sketch, T6 row "Built-in plugins" (Langfuse reference)
Axis 7: T5 §security-posture §2.4/§2.5, T6 §extensibility
Axis 8: T6 #20 freeze-flag, T5 §plugin-API-stability, T1 §cross-stack-gaps gap-1
Axis 9: T5 §release v0.13 Tenacity, T5 §production-deployment-signals (Krzysztof Słomka TokenMix benchmark)
Axis 10: machine report, T1 axis-10 launchd row, PRD §5 executor_machine

Open questions

Process count. Fleet adoption pattern: one shared Hermes process on K20N0S (lower resource, weaker tenant boundary), N processes (one per agent identity — stronger boundary, higher resource), or hybrid (one Hermes per "tenant cluster" — atlas+plutus shared, viska siloed). Decides Axis 7 score from 2 → 4 depending on path. T3 weighting needed.
Launchd-wraps-Hermes vs Hermes-internal-cron. Posture A vs B per "Coexistence with launchd" above. Wake-catchup behavior of Hermes-internal cron on macOS sleep is undocumented — empirical probe needed before either path is locked. Affects Axis 2 + Axis 10 scoring confidence.
fleet_schedules.executor adapter path. Mastra-bridge-style (HTTP POST to mastra-bridge translates to Hermes invocation) vs direct (Themis writes to Hermes jobs.json mirror + Hermes reads as file-watch). Latter is lower-latency but couples Hermes to Themis schema; former preserves separation. PRD-level decision, not pure T2 scope.
Cross-tenant LLM-quota coordination. If process-per-agent, each Hermes consumes its own OpenRouter / Nous Portal quota. Fleet aggregate could exceed D8's 180 RPM Default tier even when each agent stays under. Cutover criteria from D8 need fleet-aggregate revision.
update_scheduled_task MCP-tool equivalent in Hermes cron subsystem. T1 §architecture-invariants invariant 6 forbids in-prompt self-rescheduling fleet-wide. Hermes cron is skill-injection — does an in-running plugin/skill have the primitive to mutate the cron table? If yes, that primitive needs Hades-layer block. If no, axis-9 score stays at 3 (no self-modification risk).
Multi-machine fanout. Fleet has K20N0S + other machines (MacBook fleet, hostinger-vps, Railway). Hermes is single-host. Multi-host scheduling requires N Hermes installs coordinated via fleet_schedules.executor_machine. Adapter work multiplies; bus-factor risk multiplies too (each host now depends on teknium1).
Plugin re-test infrastructure. D13 review-gated rolling requires "all 10 Pantheon hardening plugins must pass on candidate tag before merge." No CI fixture for plugin-vs-Hermes-tag-matrix exists today. Building this infra is a hard prerequisite to fleet adoption — separate from per-plugin authoring cost.