Files
homelabstack/docs/superpowers/specs/2026-06-27-hermes-ecosystem-integration-design.md
T
ginnoirandClaude Opus 4.8 73ff2e92c8 docs: revise Hermes spec from live-CLI findings (v0.17 native features)
Executing Phase 1 revealed Hermes v0.17 ships native curator (managing 74
skills), native browser plugins (browserbase stealth), native acp editor mode,
and insights. Drop curator-evolver (redundant), re-evaluate camofox, keep acp
skill (installed+enabled) and eagle-eye (elevated).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-27 13:55:51 -05:00

377 lines
25 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Hermes Ecosystem Integration — Triage & Design
**Date:** 2026-06-27
**Author:** Claude (overnight autonomous research for ginnoir; for morning review)
**Status:** Draft — awaiting ginnoir's decisions on the flagged items below
---
## ⚠️ REVISION 2026-06-27 (during execution — live-CLI findings supersede README research)
This spec was written from the repos' READMEs. Executing Phase 1 against the **live** valhalla host
revealed **Hermes v0.17 already ships native equivalents** of several planned adds. Net changes:
- **`hermes-curator-evolver` → DROPPED.** Native `hermes curator` is already enabled, weekly, and
conservative (`consolidate: off`, prune-only, never deletes, auto-backups), managing **74
agent-created skills**. It satisfies the "report-only skill maintenance" intent. Installing the
plugin would put a second curator on the same `~/.hermes/skills/`. Use the native one (tune config
line 417 if desired).
- **`camofox-browser` → RE-EVALUATE.** Native bundled plugins `browser-browserbase`
(stealth/proxies/keep-alive, cloud) + `browser-browser-use`, plus `hermes acp --setup-browser`
(local Playwright), already cover browsing. camofox now only wins the *self-hosted-stealth-on-
valhalla, no-cloud-key* niche. Otherwise enable a native browser plugin (far less work).
- **`hermes-agent-acp-skill` → KEPT & INSTALLED (enabled).** Native `hermes acp` is an *editor-
integration server* (Zed/VS Code/JetBrains), distinct from this delegation skill; they coexist.
- **`eagle-eye` → KEPT / ELEVATED.** 74 agent skills + 59 bundled makes per-turn skill routing more
valuable (confirm native doesn't already pre-select).
- **`hermes-motif` → OPTIONAL / lower priority.** Still additive (native curator does lifecycle, not
trace→new-skill discovery), but the library is already large and well-managed.
- **`hermes-web-search-plus` → KEPT** (no native web search observed). **`llmtrim`** overlaps native
`hermes insights` for *measurement*; its trimming value stands.
**As-built so far:** acp-orchestrator skill installed + enabled. Cursor CLI installed; Claude Code +
Codex installed (login pending). `agy` (Antigravity) install blocked by the sandbox classifier — see
§7.4. The phase tables below are otherwise unchanged; treat the bullets above as the authoritative
deltas.
---
## 0. TL;DR for the morning
You asked me to research seven Hermes-ecosystem repos and plan how each fits. I verified all
seven are real and active, mapped each against your **actual** Hermes deployment (host systemd
install on valhalla, llama-swap/P100 backend, ~29-tool curated MCP surface, Codex + Claude Code
also installed), and triaged them into adopt / trial / decide / skip.
**Recommended path:**
| Phase | Repo | Verdict | Why |
|---|---|---|---|
| **1** | `hermes-agent-acp-skill` | **ADOPT** | Pure skill drop-in; lets the local 20B offload hard work to Codex/Claude Code, which you already run. Highest leverage, lowest risk. |
| **1** | `hermes-curator-evolver` | **ADOPT (dry-run first)** | Closes Hermes' self-improvement loop; read-only by default; aligns with your curation habit. |
| **2** | `camofox-browser` | **ADOPT (new homelab stack)** | Gives the local agent real web browsing; clean Docker/Caddy fit; independent of Hermes internals. |
| **2** | `eagle-eye` | **TRIAL / DEFER** | Solves the exact tool-overload pain you already hit — but very early (5★, 1 commit) and carries a required Chinese-tokenizer dep. Trial behind a flag; don't depend on it. |
| **3** | `hermes-ui` | **ADOPT (trial)** | Single-HTML + stdlib proxy; stood up next to the bundled webui to evaluate. |
| **3** | `hermes-workspace` | **ADOPT (trial)** | Full command center; stood up in parallel to compare head-to-head, then keep one. Swarm Mode won't parallelize on one P100 — value is the workspace/observability features. |
| **3** | `mission-control` | **SKIP** | Not Hermes-native (built for OpenClaw/CrewAI/LangGraph/AutoGen). Redundant with the two Hermes UIs. |
**Decisions — RESOLVED 2026-06-27 (see Section 6):** (1) trial **both** UIs, keep the winner;
(2) curator-evolver stays **report-only** for now; (3) **trial eagle-eye** — it's the only direct
skill-router in the ecosystem, no more-mature equivalent exists; (4) wire camofox as a **minimal
2-tool skill**.
---
## 1. The anchor: your current Hermes deployment
Everything below is sized against what you actually run (from project memory, verified against the
repo and host conventions):
- **Hermes Agent v0.17.0 (NousResearch)** runs on the **valhalla host**, not in Docker — systemd
units `hermes-gateway.service`, `hermes-dashboard.service`, `hermes-webui.service`. Editable
install at `~/.hermes/hermes-agent/`; config at `~/.hermes/config.yaml`; CLI `~/.local/bin/hermes`.
Workspace at `/storage1/hermes/workspace/`.
- **Backend:** llama-swap (`stacks/llm`, Portainer id 34) on a single **Tesla P100 16GB**, serving
one GGUF at a time, `--parallel 1`, 64k ctx, default `gpt-oss-20b`. OpenAI API at
`http://172.20.0.1:8090/v1`.
- **MCP surface deliberately curated to ~29 tools** because gpt-oss-20b drowns in tool overload.
This is the single most important constraint for everything below: **the local model is weak at
selection under load, and the GPU runs one model, one sequence at a time.**
- **You also run Codex (`~/.codex`) and Claude Code**, kept in sync with your Claude global config.
This is what makes the ACP delegation skill genuinely useful rather than theoretical.
### 1.1 Two integration classes (this drives the whole plan)
- **Class A — host-side Hermes extensions** (plugins & skills): live in `~/.hermes/` on valhalla,
applied by SSH + `hermes ...` + gateway restart. **These are NOT homelabstack repo content.**
They are host-managed exactly like the rustdesk/obsidian/xvfb units — tracked in project memory
and the Obsidian vault, not committed here. Fully reversible (config backups + plugin uninstall).
`hermes-agent-acp-skill`, `hermes-curator-evolver`, `eagle-eye`.
- **Class B — Docker services**: become `stacks/<name>/` entries, deployed via the normal
Gitea-poll path, fronted by Caddy (`internal_only` + Authentik), secrets in `stack.env`,
infra images pinned out of Watchtower.
`camofox-browser`, and (if adopted) `hermes-ui` / `hermes-workspace` / `mission-control`.
---
## 2. Per-repo analysis
### 2.1 `hermes-agent-acp-skill` (Rainhoole) — **ADOPT, Phase 1**
- **What:** A Hermes *skill* (`SKILL.md` + `README.md`, MIT) implementing `delegate_task()`
multi-agent delegation across Hermes internal subagents, **Codex**, and **Claude Code**. Handles
agent routing (`agent=...`), context isolation, and safety controls (recommended 900 s external
timeout, 24,000-char output cap).
- **Fit:** Strong and specific. Your local model is gpt-oss-20b — fine for orchestration and light
tasks, weak for real implementation/review. This skill lets Hermes *route the hard parts to the
frontier CLIs you already have installed and configured*. It turns the weak local brain into a
dispatcher.
- **Risk:** Low. It's a skill file, not running code you didn't write — but it *invokes external
agents*, so the real work is verifying Codex/Claude Code are launchable from the Hermes service
environment (PATH, auth, non-interactive flags) and that timeouts/output caps are sane.
- **Implementation sketch:** Drop into `~/.hermes` skills dir (or `hermes skills install` if the
repo packages it that way — verify on the host); set delegation targets to the Codex + Claude
Code invocations; restart gateway; smoke-test a trivial delegated task end-to-end.
### 2.2 `hermes-curator-evolver` (pingchesu) — **ADOPT, dry-run first, Phase 1**
- **What:** Local-first Hermes *plugin* (Python 3.11, SQLite, `hermes plugins install`). Mines
evidence from sessions/tool-calls, ranks skill-improvement candidates, and generates **dry-run,
reviewable** proposals. **Read-only by default; mutations require explicit `--approve`.** Only
touches *local agent-created* skills — skips bundled, hub-installed, and external skills. Size
guardrails, backup/rollback manifests, optional Qwen-embeddings + BGE-reranker for semantic
ranking, native scheduler (systemd) integration.
- **Fit:** This *is* Hermes' "self-improving" thesis made operational, and it matches how you
already work (curate, gate, keep things reversible). The default posture (report-only, dry-run,
human-review queue) is exactly the safe on-ramp.
- **Risk / caveats:**
- It writes to skills with `--approve`. **Recommendation: run report-only / dry-run indefinitely
at first**; promote to `--approve` only after you've seen a few proposal batches you'd have
accepted anyway.
- Optional embeddings/reranker want a model. **Do not load them onto the P100** alongside
gpt-oss — the GPU is single-model/`--parallel 1`. Run ranking on **CPU**, or skip the dense
layer initially (BM25/FTS ranking is enough to start).
- Schedule the mining pass **off-peak** via a systemd timer so it never contends with live
inference.
- **Implementation sketch:** `hermes plugins install` on the host; point it at the session store;
run one manual `collect``rank``report` cycle by hand; inspect the review queue; only then wire
a nightly systemd timer in report-only mode.
### 2.3 `eagle-eye` (willingning-coder) — **TRIAL / DEFER, Phase 2**
- **What:** Zero-invasive skill *pre-filter* plugin. Before the LLM call, narrows 50+ skills to the
top ~5 via a 5-layer cascade (hard triggers → FTS5/BM25 → synonyms → dense embeddings → RRF
fusion), degrading gracefully when optional deps are absent. "Not matching is a valid result."
- **Fit (conceptual):** Excellent — this is the **skill-side analog of the MCP tool-overload fix
you already did**. Fewer, better skill candidates in the prompt = better selection by a weak
model + less Pascal prefill. If it works, it directly improves gpt-oss-20b's behavior.
- **Risk / caveats (why it's a trial, not an adopt):**
- **Maturity:** 5 stars, single commit. Early. Treat as experimental.
- **Dependency smell:** `jieba` (Chinese tokenization) is a *required* dep; your skill library is
English. Works, but signals the author's primary use case differs from yours — watch for
English-tokenization edge cases and maintenance drift.
- Same P100 rule: keep its dense-embedding layer on **CPU** or disabled; lean on L1L2
(deterministic + BM25) first.
- **Implementation sketch:** Install behind an easy on/off switch on the host; A/B a handful of
representative prompts with it on vs off; keep it **only if** measured skill-selection quality
improves. Do not let any workflow depend on it.
### 2.4 `camofox-browser` (jo-inc) — **ADOPT as a homelab stack, Phase 2**
- **What:** Stealth headless browser (Camoufox/Firefox) exposing a **REST API for AI agents**
anti-fingerprinting, element-reference interaction (`e1`,`e2`), session isolation, proxy/GeoIP,
YouTube transcripts, Docker/Fly/Railway deploy. 7.2k★, actively maintained. **No Hermes coupling**
— it's a generic tool backend.
- **Fit:** Clean Class-B homelab fit and a real capability gap-filler: your agent currently has
freshrss + obsidian but no general web browser. As `stacks/camofox`, internal-only behind Caddy,
it gives Hermes (and Codex/Claude) reliable browsing.
- **Risk / caveats:**
- It's anti-detection tooling — appropriate for personal research; **keep it strictly LAN/SSO-gated
(`import internal_only` + Authentik)** and off the public internet. New attack surface; pin the
image and read the Dockerfile before running.
- Heavier service (~300 MB Camoufox binary, Firefox). Fine on valhalla, but it's not free.
- **Wiring to Hermes:** either a thin MCP shim around its REST API, or a Hermes skill that curls
it. Given your tool-overload sensitivity, expose it as **one or two** high-level tools (e.g.
`browse(url)`, `search(query)`), not its full surface.
- **Implementation sketch:** New `stacks/camofox/docker-compose.yml` (bind config to `/config/camofox`,
blobs/cache to `/storage1/labdata/camofox`, join `edge`), `stack.env`, a Caddy block
(`camofox.ginnoir.com`, `import internal_only`), regenerate bookmarks, push. Then add the minimal
Hermes tool/skill wrapper on the host and restart the gateway.
### 2.5 The three dashboards — pick **at most one** (Phase 3, DECISION)
You already run the bundled `hermes-webui.service`, so a UI is an *upgrade*, not a gap. These three
overlap heavily; adopting more than one is waste.
| | `hermes-ui` (pyrate-llama) | `hermes-workspace` (outsourc-e) | `mission-control` (builderz-labs) |
|---|---|---|---|
| Stars | 173 | 5.9k | 5.4k |
| Stack | 1 HTML file + Python **stdlib** proxy (`serve_lite.py`, :3333 → gateway :8642) | React/TS/**Vite build**, Node 22+, → gateway :8642 + dashboard :9119 | Next.js 16 / React 19, better-sqlite3 |
| Hermes-native? | **Yes** | **Yes** (best with vanilla hermes-agent) | **No** (OpenClaw/CrewAI/LangGraph/AutoGen/Claude SDK) |
| Effort to host | **Trivial** (no build) | Medium (build → container/stack) | Medium + **adapter work** |
| Headline features | chat, tasks/kanban, files, terminal, skills, MCP browser, cron, memory, health | all of the above + ops dashboards, "Conductor" missions, **Swarm Mode (tmux worker pools)** | 32 panels, RBAC, spend/trust scoring, multi-framework |
| Verdict | **Trial first** | **Consider as a proper stack later** | **Skip / defer** |
- **`hermes-ui` — recommended first move.** Lowest cost to evaluate a richer UI. Can run as a tiny
host service or a minimal container next to the bundled webui; no build pipeline. If it's better
than the bundled webui, keep it; if not, delete one file.
- **`hermes-workspace` — the ambitious option.** Genuinely the most capable, best run as a real
`stacks/hermes-workspace` Docker build behind Caddy + Authentik. **Caveat to flag:** its
marquee **Swarm Mode (parallel tmux worker pools) cannot actually parallelize inference on your
setup** — the single P100 runs one model with `--parallel 1`, so "swarm" workers serialize on the
GPU (or must use a different/remote backend per worker). Adopt for the workspace/observability
features, not for swarm, unless/until you add GPU capacity or point swarm workers at cloud
providers.
- **`mission-control` — skip unless requirements change.** It's framework-agnostic and **not
Hermes-native** — using it means writing a Hermes adapter for a dashboard whose job the two
Hermes-native UIs already do. Only worth it if you later want a single ops plane across *multiple*
agent frameworks (you don't run those today).
---
## 3. Recommended phased rollout
**Phase 1 — host-side, reversible, high-leverage (no repo changes):**
1. `hermes-agent-acp-skill` — install skill, wire Codex + Claude Code delegation targets, smoke-test.
2. `hermes-curator-evolver` — install plugin in **report-only/dry-run**, manual cycle, then nightly
systemd timer (report-only). CPU ranking; no P100 embeddings.
**Phase 2 — new capability + experiment:**
3. `camofox-browser` — new `stacks/camofox` (Class B), Caddy internal-only + Authentik, minimal
Hermes tool wrapper.
4. `eagle-eye` — host-side trial behind an on/off switch; A/B skill-selection; keep only if it helps.
**Phase 3 — UI decision (your call):**
5. Trial `hermes-ui` alongside the bundled webui. Evaluate `hermes-workspace` as a stack if the
workspace features justify the build. Skip `mission-control`.
Each phase is independently shippable and independently reversible. Stop after any phase.
---
## 4. Cross-cutting concerns (apply to every adoption)
- **Single-P100 discipline.** One GPU, one model, `--parallel 1`. Anything implying parallel or
extra model loads — curator embeddings, eagle-eye dense layer, workspace swarm — must run on
**CPU**, **off-peak**, or **not at all**. Never co-resident with gpt-oss on the P100.
- **Host vs repo boundary.** Class-A extensions are host-managed in `~/.hermes/` (document in memory
+ vault, like the rustdesk/obsidian units). Only Class-B services touch this repo. Don't
accidentally commit host config here.
- **Tool/skill surface minimalism.** The whole reason your MCP is curated to ~29 tools. Expose new
capabilities (camofox, delegation) as a *few high-level* tools, not raw surfaces, or you reintroduce
the overload you fixed.
- **Provenance & safety.** Several repos are small/young (eagle-eye 1 commit; acp-skill 1 commit).
**Read the code before running it**, especially anything that writes skills (curator) or executes
shell / external agents (acp-skill, camofox). **Pin to a reviewed commit/tag**; keep stack images
out of Watchtower auto-update.
- **Reversibility.** Back up `~/.hermes/config.yaml` before each Class-A change (you already do this);
snapshot before promoting curator to `--approve`.
- **Security posture.** Class-B services: `import internal_only` + Authentik, secrets in `stack.env`
(LF endings), never public.
---
## 5. What I am explicitly NOT proposing
- Not running curator-evolver in `--approve` (auto-skill-editing) mode out of the gate.
- Not loading any second model onto the P100 (no GPU embeddings, no GPU swarm).
- Not adopting more than one dashboard.
- Not committing host-side Hermes plugins/skills into the homelabstack repo.
- Not exposing camofox or any new UI to the public internet.
---
## 6. DECISIONS — RESOLVED 2026-06-27
1. **UI direction → trial BOTH.** Stand up `hermes-ui` *and* `hermes-workspace` in parallel,
evaluate head-to-head against the bundled webui, then keep the winner and remove the other.
(Phase 3 now builds both.)
2. **Curator autonomy → report-only for now.** `hermes-curator-evolver` runs dry-run/report only;
no `--approve` / `--apply-low-risk` / `--approve-auto-apply`. Revisit after a trust period.
3. **eagle-eye → trial it.** Rationale (ginnoir): wants a large skill library available without
weighting every turn — which is exactly eagle-eye's pre-LLM skill-selection job. **Research
result:** eagle-eye is the *only* direct skill-router in the Hermes ecosystem (per
`awesome-hermes-agent` / Hermes Atlas); the nominal "alternatives" do different jobs —
`llmtrim` (compresses tool schemas + MCP output; **complementary**, worth a later look for the
tool side), `rtk-hermes` (shell-output compression), `hermes-snow-search` (faster session
search), `hermes-motif` (mines traces into micro-skills; a curator-evolver *rival*, not a
router). So eagle-eye stands, with the trial caveat (1-commit maturity, `jieba` dep): keep only
if it measurably improves selection; run L1+L2 only (no P100 embeddings).
4. **camofox wiring → minimal.** A small 2-tool Hermes skill (`browse`, `search`) over the REST
API, not the full surface or an MCP shim — protects the curated tool budget.
All four resolved ⇒ **Phases 1, 2, and 3 are all actionable.** The implementation plan that
follows details every phase.
**Ecosystem expansion (added 2026-06-27, per ginnoir):** while researching eagle-eye alternatives I
surveyed the wider Hermes ecosystem and the external-agent landscape. The worthwhile additions and
the motif-vs-curator verdict are in **§7**. Claude Code + Codex are **already installed on valhalla**
(this session); Cursor + Antigravity are scoped for the delegation fabric.
---
## 7. Ecosystem expansion & the delegation fabric (added 2026-06-27)
### 7.1 `hermes-motif` vs `hermes-curator-evolver` — verdict: **complementary, run both**
I earlier mis-framed these as rivals. They do **different halves of one loop**:
- **`hermes-motif` (Saurav0989) — skill DISCOVERY.** Watches tool calls live, finds repeated
sequences (same tools, varying args → `{variable}`), and proposes them as **new** `SKILL.md`
drafts. **Makes no LLM calls** — pure pattern-mining, so **zero P100 cost**. `auto_install: false`
= proposal-only. Zero-to-one skill creation.
- **`hermes-curator-evolver` (pingchesu) — skill REFINEMENT.** Improves **existing** agent-created
skills from session evidence; bounded, reviewable edits; report-only default; more mature
(CI, systemd scheduler, backup/rollback).
**Fit for you:** your stated goal (eagle-eye rationale) is a *large* skill library without per-turn
weight. That's a **skill factory**: **motif manufactures** new skills from what you already do
repeatedly → **curator refines** them → **eagle-eye routes** among them at call time. They compose.
**Recommendation: run both in proposal/report-only mode.** If you insist on only one to start,
**motif** is the lower-risk, higher-immediate-value pick for *growing* a library (no model cost, no
edits to existing files) — but there's no reason to drop curator; it's already Phase 1 and free to
leave in report-only. Plan adds motif as **Task 3b**.
### 7.2 `hermes-web-search-plus` — **ADOPT** (pairs with camofox)
Mature (v2.6.1, MIT, stdlib-only) Hermes plugin: multi-provider web **search** + extraction with
intent-aware routing (news/shopping/docs/GitHub/academic/security) and a `research` mode. 14
providers, **all keys optional** — works with a single configured provider (free tiers exist: Tavily,
Exa, SearXNG self-host, Keenable keyless). **Complements camofox**, doesn't overlap it: search-plus
*finds* (cheap API calls), camofox *browses/interacts* (heavy headless Firefox). For a P100-limited
local agent, search-plus is the lighter, higher-frequency tool — arguably the one to reach for first;
camofox for when a page needs real rendering/interaction. Plan adds it as **Task 5b**, before/with
camofox. Install: `hermes plugins install robbyczgw-cla/hermes-web-search-plus --enable`.
### 7.3 Context-efficiency layer — **OPTIONAL**, helps the Pascal bottleneck
Your memory notes prefill is the P100 differentiator and context bloat is the enemy. Two opt-in tools:
- **`llmtrim` (fkiene, MPL-2.0)** — HTTPS-proxy / MCP / CLI that compresses **tool schemas + history
+ tool output** before requests (claims 31% input / 74% output tokens, BM25+ context ranking,
log-templating). Works with anything honoring `HTTPS_PROXY` (Claude Code, Cursor, Aider). **Two
distinct payoffs:** (a) in front of the **cloud delegation agents** (Claude Code/Codex/Cursor →
Anthropic/OpenAI) it cuts real $ cost; (b) potentially in front of **llama-swap** (via
`LLMTRIM_EXTRA_HOSTS`) to shrink prompts and speed Pascal prefill — needs validation, it's not
documented for local OpenAI-compatible backends. Caveat: it installs a name-constrained MITM CA;
acceptable but a real trust decision.
- **`rtk-hermes` (ogallotti, MIT)** — `pre_tool_call` hook that rewrites shell commands through the
`rtk` binary so terminal output arrives pre-filtered (cache-safe; preserves tool schema). Lighter,
shell-only. Needs the `rtk` binary on the host (`brew`/Linux build — verify availability).
**Recommendation:** defer both to an **opt-in Task 11**. Start llmtrim on the *cloud-delegation* path
(clear cost win, no local risk) before considering it in front of llama-swap.
### 7.4 The delegation fabric — claude-code · codex · cursor · antigravity
Your acp-skill (Task 2) natively routes to `codex`, `claude-code`, and `hermes` subagents. You also
want **Cursor** and **Antigravity** in the mix. All four have real **headless** CLIs usable as
delegation targets from the valhalla host:
| Agent | CLI | Headless invocation | Install (official) | Status on valhalla |
|---|---|---|---|---|
| Claude Code | `claude` | `claude -p` | `curl -fsSL https://claude.ai/install.sh \| bash``~/.local/bin/claude` | **Installed** v2.1.195 (login pending) |
| Codex | `codex` | `codex exec` / non-interactive | `npm i -g @openai/codex` (Node 22+) | **Installed** v0.142.3 (login pending) |
| Cursor | `cursor-agent` | `cursor-agent -p --output-format json --trust` | `curl https://cursor.com/install -fsS \| bash` | Scoped (Task 10) — note: known `-p` hang bug, set `--output-format json` + timeout |
| Antigravity | `agy` (ex-Gemini CLI, Go binary, **best for headless SSH**) | `agy -p` / `--headless --approve` | from **official** `antigravity.google/download` + `/docs/gcli-migration` (auth via keyring/Google sign-in or `ANTIGRAVITY_TOKEN`) | Scoped (Task 10) |
**Wiring approach (Task 10):** acp-skill supports `codex`/`claude-code`/`hermes` out of the box —
verify whether its `agent=` routing is **extensible** (read `SKILL.md`). If yes, add `cursor` and
`antigravity` targets pointing at the headless invocations above. If not, add a **thin generic
"shell-agent" skill** that shells out to any of the four with the timeout/output caps from the
`delegation:` config — keeping the exposed tool surface minimal (your standing tool-budget rule).
**Alternatives noted, not adopted:** `42-evey/hermes-plugins` ships `evey-bridge` (file inbox/outbox
+ MCP bridge to Claude Code) and `evey-delegate-model` (model routing w/ fallback) — heavier,
opinionated, unknown maturity; acp-skill is the simpler purpose-built choice. `evey-cost-guard`
(Langfuse budget enforcement) becomes worth a look **once cloud delegation is live** and spend
matters.
### 7.5 Updated rollout placement
- **Phase 1:** + **Task 3b `hermes-motif`** (proposal-only, zero P100 cost).
- **Phase 2:** + **Task 5b `hermes-web-search-plus`** (light search, pairs with camofox).
- **Phase 2b (new):** **Task 10 delegation fabric** (install cursor + agy, wire all four into
acp-skill) and **Task 11 (optional) context efficiency** (llmtrim on the cloud-delegation path;
rtk for shell).
- **Phase 3:** unchanged (both UIs → keep one).