Sync Hermes Agent — Design Brief

Status: Draft v3.2 (May 8, 2026) Author: CoachJ + Claude (synthesizing May 4 all-hands + May 5 daily sync with James + May 7 James DM on layered phasing + May 8 implementation review + L1-3 functional test) v3.2 changes: L1 + L2 verified end-to-end against production (HTTP 200, model_confidence 0.74, all 12 signals present). L3 install verified (with --force due to security scanner false-positive on curl examples in v1 SKILL.md). L3 functional test exposed a real behavior gap: agent answered with a position but never called the Sync API — used Hermes' built-in session_search and fabricated patterns from conversation context instead. Diagnosis: in v1, SKILL.md's API quick reference was raw curl examples that the agent had to choose to execute; in modern tool-use models, this is much weaker than exposing first-class tools. Fix shipped: SKILL.md → MCP rewrite (v2.0.0). New SKILL.md drops all curl, references sync.get_profile / sync.get_recent_decisions / sync.submit_feedback as first-class tool calls. Added sync.submit_feedback MCP tool (src/lib/agent/mcp.ts, shared business logic factored to src/lib/agent/submit-feedback.ts). Install guide rewritten to add the MCP-server-registration step in the runtime config. Side effect: scanner DANGEROUS verdict eliminated, install path now clean for any future user. Pending: user retests in Hermes after reinstalling v2. v3.1 changes: Layer 3 was already shipped at public/agent-skill/SKILL.md on May 4, with install guide at src/app/docs/agent-skill/page.tsx. The v3 brief incorrectly marked L3 as "NEXT — not built." Layers 1, 2, and 3 are all done — Function 1 (chief-of-staff context delivery) is shippable as of v3.1. Confirmed via end-to-end test instructions added inline. F1 needs no team-DB setup; that requirement only kicks in at the Layer 1+2 team-query extensions (Skills 2-4), which are not on F1's critical path. v3 changes: Restructured the build plan around James's 5-layer progressive model (API → MCP → Hermes skill → Sync Hermes agent → A2A) instead of the original orchestrator-centric phasing. Layers 1 and 2 already exist in the codebase. This collapses Function 1 (chief-of-staff context delivery to personal DTAs — the v1 GTM bet) to a single Hermes skill manifest on top of the existing MCP server, hours of work. Function 2 (orchestrator agent + DAO surface) becomes a parallel later workstream that doesn't gate Function 1. §6a (skill lock + rollback, Cici May 7) and the eval-harness refinements from earlier May 7 push are preserved. v2 changes: Reframed Skill 1 as the load-bearing pre-prompt context skill (was mis-scoped as a trivial wrapper). Added Phase 0 prerequisites for James's contribution path (repo access, Supabase access, deploy migration off direct-Vercel). Made it explicit that agent-mediated gameplay is out of scope.

1. Purpose

This brief covers two related-but-separable functions, both built progressively on a shared 5-layer stack (see §3):

• Function 1 — Chief-of-staff context delivery. A user's personal Hermes (DTA) calls the Sync MCP server to retrieve the user's behavioral-profile context block, then injects it as pre-prompt for any downstream task (emails, content, decisions). The personal agent's output reflects how the user actually decides — not just stated preferences. This is the v1 GTM bet (the Ryan-Sarver "Chief of Staff" thesis: an agent with sync context > an agent without). Ships as a single Hermes skill on top of the existing MCP server (Layers 1+2 done; Layer 3 = the skill).
• Function 2 — Sync Hermes orchestrator + DAO surface. A second Hermes runtime — distinct from each user's personal Hermes — runs as an orchestrator one abstraction level above Sync. Hosts the cross-user reasoning skills (find_relevant_voices), write skills (capture_decision), and trust recommendations. Exposes an A2A endpoint that personal Hermes agents can call. Is the queryable "Beacon governance algorithm" surface that the white paper described as "the mother." Layers 4+5.

Critical clarification (May 5): Sync the game does not change. The Sync API surface (/api/agent/v1/*) does not change. Both functions are new infrastructure that sits on top — they consume Sync, they don't modify Sync.

Out of scope: Playing Sync through agents. There is no implementation of agent-mediated gameplay and that is not the goal. Players play Sync at the website; both Function 1 and Function 2 deliver what's been built up there to other surfaces (the user's own DTA, the orchestrator's A2A endpoint).

2. Why a separate agent (not just more Sync API endpoints)

This question only applies to Function 2. Function 1 needs no separate agent — it's a Hermes skill in the user's own DTA wrapping MCP tools that already exist. For Function 2, three reasons:

1. A2A is the right interaction model for cross-agent queries. Personal Hermes agents need to ask coordination questions ("who should weigh in on X?", "what's the team's recent stance on Y?"). REST is fine for direct user→Sync; agent→agent is what A2A is built for.
2. Cross-user queries need a privileged identity. Today's /api/agent/v1/* endpoints are user-scoped — bearer token = one user's data. The Sync Hermes agent needs team-scoped and aggregate read access. That's a different trust class and belongs behind a different identity, not bolted onto user-scoped endpoints.
3. Skill packaging matters. Hermes agents ship with skills (per agentskills.io standard). The Sync Hermes agent has its own skill bundle that can be installed/updated independently of any personal agent.

3. Architecture

Layered stack (the build model)

Per James's May 7 framing — progressive connectivity, each layer independently useful, each unblocks parallel workstreams:

┌────────────────────────────────────────────────────────────────────┐
│ LAYER 5  A2A endpoint on Sync Hermes Agent                         │ Function 2
│          (cross-agent: other DTAs talk to the orchestrator)        │
├────────────────────────────────────────────────────────────────────┤
│ LAYER 4  Sync Hermes Agent  (orchestrator runtime)                 │ Function 2
│          ~/.hermes-sync/, hosts reasoning + write skills,          │
│          consumes the same MCP layer as any other client           │
├────────────────────────────────────────────────────────────────────┤
│ LAYER 3  Hermes skill in personal DTA                              │ Function 1
│          ~/.hermes/, calls MCP tools directly                      │ ← v1 GTM bet
├────────────────────────────────────────────────────────────────────┤
│ LAYER 2  MCP server  /api/agent/v1/mcp                    ✓ DONE   │
│          sync.get_profile, sync.get_recent_decisions               │
├────────────────────────────────────────────────────────────────────┤
│ LAYER 1  Sync REST API  /api/agent/v1/*                   ✓ DONE   │
│          /profile, /recent-decisions  (+team endpoints TBD)        │
├────────────────────────────────────────────────────────────────────┤
│          Sync Supabase DB  (no changes)                            │
└────────────────────────────────────────────────────────────────────┘

Implications: - New API endpoints (e.g. team-scoped reads) get added at Layer 1, surfaced as new MCP tools at Layer 2, and become automatically available to both Layer 3 (personal DTA skill) and Layer 4 (orchestrator). No duplicate work. - Function 1 ships as soon as Layer 3 lands. Layers 4+5 are not on its critical path. - Function 2 (the orchestrator agent + A2A surface) consumes the same MCP layer that Layer 3 uses. It's a Hermes runtime that is also an MCP client; it just additionally exposes A2A and houses the cross-user reasoning skills.

Topology (when Layers 4+5 are running)

┌─────────────────────┐         A2A        ┌──────────────────────┐
│ CoachJ's Hermes     │ ◄────────────────► │ Sync Hermes Agent    │
│ (personal DTA)      │                    │ (orchestrator)       │
└─────────────────────┘                    │                      │
                                           │  - team queries      │
┌─────────────────────┐         A2A        │  - find_relevant_…   │
│ James's Hermes      │ ◄────────────────► │  - decision capture  │
│ (personal DTA)      │                    │  - trust-graph       │
└─────────────────────┘                    └──────────┬───────────┘
                                                      │ MCP/HTTP
                                                      ▼
                                           Sync MCP server (Layer 2)
                                                      │
                                                      ▼
                                           Sync API + Supabase DB

Where it runs (Layer 3 only — Function 1): the Hermes skill lives in each user's ~/.hermes/. No new infrastructure beyond what's already deployed.

Where it runs (Layers 4+5 — Function 2, local dev): the orchestrator runs on CoachJ's machine alongside personal Hermes. Two Hermes runtimes, two config dirs (~/.hermes/ for personal, ~/.hermes-sync/ for orchestrator). Cloudflare tunnel or ngrok exposes the A2A endpoint for external personal agents to reach during dev.

Where it runs (Layers 4+5 — production): orchestrator deployed to a server (Vercel/Railway/Fly) for always-on availability. Required before any external user's personal agent can rely on it.

Configuration separation is non-negotiable. The two Hermes runtimes must not share state. Different config dir, different API key set, different MCP server config, different skill bundle. They're two distinct identities; commingling auth would defeat the privilege separation.

4. What it knows (data sources)

In priority order:

1. Sync REST API (/api/agent/v1/profile, /recent-decisions) — for user-scoped reads. F1: the personal DTA calls these directly via the MCP layer, with the user's own API key. F2: the orchestrator calls these on behalf of a requesting personal agent (user's API key passed through A2A). Both reuse existing auth/distillation/rate-limiting; loose coupling.
2. New team-scoped API endpoints — /api/agent/v1/team/[id]/alignment, /voice, /fault-lines, /relevant-voices. These wrap the queries from docs/handoff-team-analytics-cici.md and require team-membership auth. New code, but small.
3. Direct Supabase reads (service role) — only for queries that don't have an API endpoint yet, and only for cross-user aggregates that need DB-level joins. Treated as escape hatch, not default.
4. Shadow eval harness data (evaluation_snapshots, evaluation_predictions) — not consumed in v1, but worth flagging now: this dataset (per-choice agreement rates under conditions A/B/C) is itself a candidate skill input later. Example future skill: get_agent_lift_for_user — "based on N of your recorded choices, an agent armed with your Sync profile predicts you correctly X% of the time vs. Y% with personal_context alone." Concrete, per-user, defensible against the "your agent already knows me" objection. Park until F1 has shipped and we have real-world calls to correlate with the eval data.

5. Initial skill bundle

Skills with which layer they live in and which function they serve. Build order roughly follows layer order.

#	Skill	What it does	Layer	Function
1	get_user_profile	Returns the requesting user's behavioral-profile context block (the "based on the last 50 games, this user tends to lead with consequentialist reasoning…" summary) for use as a pre-prompt by the caller's personal Hermes. Load-bearing for the v1 GTM thesis — see paragraph below. Underlying MCP tool (sync.get_profile) already exists at Layer 2; this skill is the Layer 3 Hermes-side wrapper.	3	F1
2	get_team_alignment	Returns most-aligned/divergent pairs for a team the requester is a member of. Needs new endpoint at Layer 1, new MCP tool at Layer 2; consumable by both Layer 3 (personal DTA) and Layer 4 (orchestrator).	1+2	F1 + F2
3	get_voice_equity	Returns who's most cited as a mind-mover in the team. Same shape as #2.	1+2	F1 + F2
4	get_fault_lines	Returns scenarios where the team split. Same shape as #2.	1+2	F1 + F2
5	find_relevant_voices	Given a decision question + team_id, returns ranked profiles by signal-to-situation match (e.g. "for conflict mediation: A, then C, then B"). Per-decision suggestion only — never persistent role labels (per feedback_signal_to_situation_not_roles). Lives in Layer 4 (orchestrator) — consumes the team-query MCP tools and reasons over them.	4	F2
6	capture_decision	Accepts a transcript (Fathom URL or raw) + team_id, runs LLM extraction, writes decision_log rows. ADR-039 Phase 1. Write skill — needs orchestrator's privileged identity.	4	F2
7	tag_outcome	Records outcome for a previously-captured decision. ADR-039 Phase 1. Write skill.	4	F2
8	query_decision_history	Returns recent decisions a team has made + outcomes.	4	F2
9	get_trust_recommendation	Given a decision context + a team, returns who to delegate to based on delegation_preferences × scenario category.	4	F2

Two different theses, two different load-bearing skills. Skill 1 (get_user_profile) carries the v1 chief-of-staff thesis: a personal agent armed with Sync-derived behavioral context produces measurably better output than the same agent without it. The shadow eval harness (migrations/081_agent_eval_harness.sql, src/lib/agent/eval.ts, admin UI at /admin/agent-eval) has been running on every recorded choice for weeks, capturing predictions under three conditions: A (personal_context only — the user's existing AI memory), B (Sync profile only), C (both). The headline metric is A vs C — directly answering the objection a Ryan-Sarver type would raise: "My agent already has memory of me. Why does Sync add anything?" The case-study artifact is therefore not a thing we still need to instrument; it's accumulating in the background. Skill 5 (find_relevant_voices) carries the longer-term company-brain thesis: that the orchestrator can rank profiles against a decision context usefully. Both can succeed independently; v1 stands or falls on Skill 1.

6. Permissions & privacy model

Layer 3 (the personal-DTA skill, F1) inherits the existing user-scoped MCP/API auth — bearer token = one user's data, no extra permissions story. This section is about Layers 4+5 (F2): the orchestrator has more reach than user-scoped agents, so the trust model has to be explicit.

• Personal agent identity passes through. When CoachJ's Hermes asks the orchestrator a question, it includes CoachJ's identity (via A2A auth). The orchestrator scopes every query to what CoachJ is allowed to see.
• Team-scoped queries require membership. get_team_alignment for team T returns data only if the requesting user is a member of T (or has read-grant from a team admin).
• No raw cross-user profile exposure. A user's full profile is only returned via get_user_profile for the requesting user themselves. Team queries return aggregates (alignment %, voice rank) and signal patterns, not raw decision histories of other users.
• Decision capture writes are gated by team admin role. Only team owners/admins can call capture_decision for a team's transcripts. Members can read decisions; only admins write.
• Audit log. Every orchestrator query is logged with (caller_user_id, skill, target_scope, timestamp). Mandatory — this is the answer to Tash's manipulation/capture concern (project_coordination_substrate_security).
• Personal Hermes agents do not call Sync directly. All access flows through the orchestrator. CoachJ confirmed May 5: gatekeeping is desired for v1. Revisit only if rate limits or latency force it; don't open the gate just because it would be marginally simpler.

6a. Skill lock + rollback (Cici, May 7)

A real product safety requirement that lands as scope on whichever phase ships agent-driven skill updates. Two distinct mechanisms:

1. Lock — mark a skill as immutable to agent-driven mutations. The orchestrator may surface recommendations for skill updates based on continual learning, but for locked skills, those are surfaced for explicit human approve only — never applied automatically. Locked skills represent deliberate human-curated rules the user has decided shouldn't drift.

2. Rollback — for unlocked skills, every mutation is versioned with a diff. The user can revert to any prior version on detecting drift. Implementation: per-skill version log keyed by skill_id × user_id, stored alongside the skill content.

Why both: Cici's framing on the May 7 call — "I want to be able to lock it. I want to be able to restrict the agent from changing it ever... If I realize something's going wrong with a skill, then maybe roll back." Lock = prevent unwanted change; rollback = recover from change that already happened.

Why this is non-negotiable: the bigger framing CoachJ surfaced on the same call — "Sync is meant to capture how you're making decisions, but sometimes we have a particular vision about how we want to accomplish it. It doesn't matter how accurate it is to how you're making decisions. If you wanted to do it a specific way, that's what the tool should do." Sync = measurement; skill lock = action override. Both layers are needed; without lock, the action layer becomes unreliable and users move to a competing tool. See project_skills_lock_rollback memory for the longer framing.

Scope: add to whichever layer first ships agent-driven skill updates (likely Layer 4 work, since orchestrator-side reasoning skills are the most likely to want to mutate user skills). Don't ship update-without-lock-rollback under any circumstance. Liability framing: Cici was explicit that "we need to protect ourselves from being, getting the blame for it" if agent-driven updates corrupt a skill.

7. Layered build plan

Each layer is independently useful and can be worked on in parallel once its dependencies are met. F1 (chief-of-staff) ships when Layer 3 lands; F2 (orchestrator + DAO) needs Layers 4+5. Team-query work (new endpoints at Layers 1+2) benefits both functions and is the natural parallel track.

✓ Layer 1 — Sync REST API (DONE)

Currently exposes /api/agent/v1/profile and /api/agent/v1/recent-decisions. User-scoped, bearer-token auth. Extension work: add team-scoped endpoints /api/agent/v1/team/[id]/{alignment,voice,fault-lines} wrapping the queries from docs/handoff-team-analytics-cici.md. Auth: bearer token + team-membership check. ~3–4 days. Doesn't gate Layer 3 (F1).

✓ Layer 2 — MCP server (DONE)

Currently at src/app/api/agent/v1/mcp/route.ts, src/lib/agent/mcp.ts. Exposes three tools: sync.get_profile (returns the behavioral-profile context block per §5), sync.get_recent_decisions (recent decisions with rationale), and sync.submit_feedback (records the user's 👍/👎 reaction to a recommendation, joins back via read_id). Extension work: add MCP tools wrapping each new Layer 1 endpoint as it lands. Mechanical — each new tool is ~20 lines in src/lib/agent/mcp.ts.

✓ Layer 3 — Hermes skill in personal DTA (DONE — v2.0.0, F1 is shippable pending user retest)

Manifest at public/agent-skill/SKILL.md (v2.0.0, agentskills.io format), install guide at src/app/docs/agent-skill/page.tsx. v2 references the three Layer-2 MCP tools as first-class actions (sync.get_profile, sync.get_recent_decisions, sync.submit_feedback) instead of the v1 raw-curl approach. The rewrite was driven by a real behavior failure in the May 8 functional test (see v3.2 status notes): the v1 skill's curl examples were treated as flavor-text by the model and the Sync API never got called. Tool-call references survive the model's attention much better.

The skill content embeds embodiment rules ("take a position, don't narrate"), a 120-word length cap on decision recommendations, signal selection rules, model_confidence gating, and a thumbs-up/thumbs-down feedback loop. This is the prompt-engineering work the v2 brief flagged as "heavy on prompt design for the returned context block" — preserved verbatim through the v2.0.0 rewrite.

Install flow now has two parts: (1) install the SKILL.md, (2) register the Sync MCP server in the runtime's config (~/.hermes/config.yaml for Hermes, .mcp.json for Claude Code). The install guide walks both. Side effect of removing curl examples: the security scanner's DANGEROUS verdict on v1 is gone — v2 installs cleanly without --force.

Acceptance test (next step for CoachJ): reinstall in Hermes (hermes skills install ... — should not require --force for v2), add the MCP server registration to ~/.hermes/config.yaml, restart, and re-ask a decision question. Pass = agent calls sync.get_profile, cites a real signal from your actual profile (e.g. "consequentialist reasoning", "transparency in resource-allocation"), stays under 120 words, ends with Was this useful? 👍 👎. The May 8 v1 test failed all four; v2 should fix the first three (the call) which causes the others to follow.

Open questions answered in-build: snapshot-vs-call-every-time on the caller side (§9 Q5) is currently "call every time" — the skill instructs the agent to call sync.get_profile per decision conversation. Skill development workflow (§9 Q2) is now known: edit public/agent-skill/SKILL.md, push, reinstall on the agent side. No build step.

Layer 4 — Sync Hermes Agent runtime (scaffold shipped May 8 — F2 starts here)

Scaffold lives at docs/orchestrator/ — README explaining when and why, a customizable config-template.yaml, and a step-by-step setup.md. When you're ready to stand up the orchestrator: mkdir ~/.hermes-sync && cp the template, set the env, start a separate Hermes runtime via the multi-config mechanism. Two runtimes side-by-side, two distinct identities — see brief §3 "Configuration separation is non-negotiable."

The orchestrator is initially a thin shell: it has access to the Sync MCP server but no F2 skills installed yet. F2 skills (5, 6-8, 9) are deferred per ADR-046 / ADR-047. That's intentional — the L4 addressability (per the May 7 Raid Guild / MetaClawTel framing) is the real v1 deliverable; functional skills layer in as demand triggers them.

When F2 skills land, they'll go in ~/.hermes-sync/skills/ (separate bundle from personal-DTA skills). Skill 5 (find_relevant_voices) — 1 week of prompt engineering on top of Layer 2 MCP data. Skills 6-8 (decision capture, ADR-039 Phase 1) — 1-2 weeks including decision_log + decision_participants migration and the outcome-tag UI surface (Cici pairs well here). Skill 9 (trust recommendation) — a few days at L4.

§6a (skill lock + rollback) is coupled to L4's first skill-mutation feature. The lock+rollback schema doesn't ship until orchestrator-driven skill updates are real — building tables without a write path violates the no-half-finished rule. When the first feature that wants to mutate user skills lands, it MUST gate against agent_skill_locks and write to agent_skill_versions. Not yet.

Layer 5 — A2A endpoint on Sync Hermes (deploy/research scaffold shipped May 8 — full ship blocked on hands-on Hermes A2A)

Scaffold at docs/orchestrator/a2a-deploy.md. Covers what L5 is, the open Hermes A2A questions that block real implementation (wire format, auth handshake, skill discovery, invocation, response shape, port — six questions total per §9 Q1), the Cloudflare tunnel setup (concrete enough to write down today), and the hosting decision matrix (Vercel / Railway / Fly / Supabase Edge Functions — recommendation: Railway or Fly because Hermes is a long-lived process and serverless cold-starts hurt A2A latency).

Real L5 code is intentionally not written. The brief explicitly flagged Hermes A2A as a "learn hands-on first" item; speculating at the wire format would produce code that's likely wrong and need rewriting once CoachJ does the actual research. Once questions 1-6 are answered, L5 implementation is mostly: register the right skill manifests, expose the runtime port, point Cloudflare at it, secure the auth path. Estimated 2+ weeks once the open questions resolve.

Pre-L5 checklist (per a2a-deploy.md): - Hands-on Hermes A2A learning to answer §9 Q1 - Hosting target decided - project_coordination_substrate_security ADR landed (per brief §8 — Tash's concern) - L4 orchestrator runtime working locally - At least one F2 skill installed worth exposing (A2A on a thin shell exposes nothing the public MCP doesn't already)

ZHD GTM framing becomes coherent when L5 is live: the orchestrator is addressable, has decision history (when ADR-039 ships), can recommend trust.

8. Prerequisites & dependencies

Before Layer 3 (the F1 ship): - [ ] CoachJ has Hermes installed and a working personal agent (✓ done) - [ ] CoachJ has played enough with Hermes to understand skills, MCP, A2A in practice (✓ partial — Telegram/CLI working, sync-judgment-poll skill built, soul.md configured; specific gaps remain on snapshot-vs-call semantics and skill workflow, will be resolved in-build at Layer 3) - [ ] James added as developer on the sync-game-v2 GitHub repo (so he can take over Layer 3 if CoachJ hits a wall, and can extend Layers 1+2 in parallel) - [ ] James added as developer on the Supabase project - [ ] Deploy pipeline migrated from direct-Vercel to GitHub Actions. Current state: Vercel's GitHub integration auto-deploys on push, which requires every contributor to have a Vercel seat. Vercel free plan caps non-owners at viewer-only, which blocks James. Target state: a GitHub Actions workflow handles the Vercel deploy via API token, so contributors only need GitHub write access. Already done in CoachJ's Murder Mystery Generator repo — port the workflow.

Before Layer 1+2 team-query extension: - [ ] Beacon team created in DB + 4 historical campaigns tagged (still pending from May 4 action item) - [ ] Cici's handoff doc queries validated against real data

Before Layer 4 decision-capture skills (Skills 6–8): - [ ] ADR-039 migration (decision_log + decision_participants) designed and applied - [ ] Outcome-tag UI surface designed (Cici pairs well here)

Before Layer 5 (production A2A surface): - [ ] project_coordination_substrate_security ADR landed (gates external "ZHD" framing) - [ ] Hosting target decided (Vercel / Railway / Fly / Supabase Edge Functions — see §9 Q3) - [ ] Cost model for hosting + API calls

9. Open questions

1. A2A protocol implementation (Layer 5). Hermes' A2A is built into the runtime — what's the wire format, how is auth handled, how do skill discovery and invocation actually work? CoachJ to learn this hands-on before committing to a v1.
2. Skill development workflow (Layer 3 — answered as part of building it). How do you write a Hermes skill? What's the test/iterate loop? CoachJ to learn this hands-on; James to share his transcript-to-GitHub skill as a working reference example.
3. Hosting target for production (Layer 5). Vercel is the path of least resistance (Sync is already there) but cost may push to Railway/Fly for long-lived agents.
4. Memory/state across A2A calls (Layer 5). Does the orchestrator hold conversation state per-caller, or is every call stateless? Probably stateless to start; revisit if needed.
5. Snapshot vs call-every-time on the caller side (Layer 3 — answered as part of building it). Does the personal Hermes cache the profile context block (e.g., refresh once per day) or fetch fresh from MCP on every task? Tradeoff: freshness vs. rate-limit/latency cost. CoachJ raised this on May 5; punted to "figure out after we build." Worth an ADR once Layer 3 ships and we have real call patterns to reason about.
6. Personal agent ↔ orchestrator agent hand-off semantics (Layer 5). When a personal agent delegates a decision to the orchestrator (e.g. "find me the right person to ask"), does it return a recommendation only, or can it act (route the question)? Probably "recommendation only" for v1.

10. What this brief is not

• Not a full ZHD architecture. ZHD is the GTM frame; this brief covers two foundational pieces (F1 chief-of-staff, F2 orchestrator). Smart contracts, on-chain governance, ERC-8004 agent registry, multi-DAO "Sync Factory" / metasync — all out of scope. Capture as post-Layer-5 direction in a separate doc so they're not lost.
• Not a Sync product change. Sync stays as-is.
• Not a system for playing Sync through agents. Confirmed May 5: there is no implementation of agent-mediated gameplay, and that is not the goal. Players play at the website; F1 makes that profile available to their own DTA, F2 makes it available to other agents via the orchestrator.
• Not a commitment to deploy to NEAR/Iron Claw. That's a possible post-Layer-5 migration; Hermes/OpenClaw is the substrate for now.

---

Next actions (May 8): 1. Verify L1-3 end-to-end on a real Hermes runtime. This is the F1 acceptance test (see Layer 3 section above). Until this is confirmed, "F1 is shippable" is a code-only claim, not a real-world claim. 2. Add James as developer on the sync-game-v2 GitHub repo and Supabase project (still pending from May 7) — unblocks his ability to extend Layers 1+2 in parallel. 3. Port the GitHub Actions deploy workflow from the Murder Mystery Generator repo into sync-game-v2, so deploys no longer require a Vercel seat (still pending from May 7). 4. Decide: continue toward "100% of the brief" (Skills 2-4 team-query extensions next, requires Beacon team in DB) or hold at F1, focus on the Ryan-Sarver case study, and let team work follow real demand.