Skip to content

Sync Hermes Orchestrator (L4) — scaffold + setup

This directory contains the scaffolding for the Sync Hermes Agent — a second Hermes runtime, separate from each user's personal Hermes, that runs as an orchestrator one abstraction level above Sync. See the brief §1 / §3 / §7 Layer 4 for the full architecture.

This is the L4 piece of the 5-layer model. L1 (REST API), L2 (MCP server), and L3 (personal-DTA Hermes skill) are all done — F1 (chief-of-staff context delivery to your own DTA) is shippable as of agent-skill v2.0.0. L4 + L5 are the F2 path: an orchestrator agent that other agents can talk to, plus an A2A endpoint that exposes its surface.

When to set this up

You need L4 if you want any of:

  1. Raid Guild / MetaClawTel addressability story. Per James's May 7 framing: external agents in DAO ecosystems (Raid Guild, MetaClawTel, etc.) need a single addressable agent that "represents" Sync's coherence/reputation surface. The orchestrator is that agent. Even with a thin skill bundle, being addressable is a real GTM artifact.
  2. An identity to host F2 skills as they get built. When Skills 5 (find_relevant_voices), 6-8 (decision capture, ADR-039), or 9 (get_trust_recommendation) come back from deferral (see ADR-046, ADR-047), they live in the orchestrator runtime, not in personal DTAs. The orchestrator is where cross-user reasoning + privileged writes happen.
  3. A skill-mutation gate (the place §6a's lock+rollback machinery would attach when agent-driven skill updates start shipping; see brief §6a).

You don't need L4 for the chief-of-staff GTM bet (F1) — Skill 1 in your personal DTA does that. L4 is forward infrastructure.

What's in this directory

  • config-template.yaml — a Hermes config skeleton for the orchestrator runtime. Copy to ~/.hermes-sync/config.yaml and customize.
  • setup.md — step-by-step setup walking through copy → customize → start → verify (L4).
  • a2a-deploy.md — L5 deployment scaffold: Cloudflare tunnel setup, hosting decision matrix (Vercel / Railway / Fly), and the open Hermes A2A questions that need hands-on resolution before any L5 code lands.
  • skills/ — orchestrator-specific Hermes skills as they're built. Currently empty by design (per ADR-046, F2 skills are deferred). When Skill 5 / 6-8 / 9 land, they'll go here as SKILL.md files installed into ~/.hermes-sync/skills/.

Two-runtime principle (recap from brief §3)

The personal Hermes (~/.hermes/) and the orchestrator (~/.hermes-sync/) are two distinct identities. They do not share state. Different config dir, different API key set, different MCP server config, different skill bundle.

This is non-negotiable. Commingling auth would defeat the privilege separation that's the whole point of the orchestrator (which, eventually, holds privileged team-scoped read access plus write access for decision capture).

What's deferred until L4 is "real"

  • §6a skill lock + rollback infrastructure. Per ADR-046's spirit (don't build features without a mutation pathway to gate), the lock+rollback schema is coupled to the orchestrator's first agent-driven skill mutation. When the first orchestrator-side skill that modifies a user's skill ships, it must gate against agent_skill_locks and write to agent_skill_versions. Until then, building those tables is forward-looking — preserving the contract (no skill mutation without lock check) is the goal, not the schema in isolation.
  • L5 A2A endpoint. The orchestrator runs locally for now. A2A — exposing the orchestrator over the network so external agents can call it — is a separate scaffold (see brief §7 Layer 5).

ADRs touching this

  • ADR-046 — defers Skills 2-4, 5, 9 (the F2 skills the orchestrator would host) until real demand.
  • ADR-047 — defers SKILL.md instruction tuning for Skill 1 until team-feedback signal accumulates.
  • Brief §6a — Cici's skill lock + rollback requirement.