Skip to content

ADR-046: Defer team-scoped Sync Hermes skills until real-user demand

Status: Deferred Date: 2026-05-08 Context: The Sync Hermes Agent brief (v3.2) proposes nine skills total. Skill 1 (get_user_profile) is the chief-of-staff context delivery — Function 1 / v1 GTM bet — and shipped May 8 in agent-skill v2.0.0. Skills 2–9 fall into three groups:

  • Team-query reads (Skills 2-4: get_team_alignment, get_voice_equity, get_fault_lines) — wrap the SQL queries from docs/handoff-team-analytics-cici.md behind new /api/agent/v1/team/[id]/* endpoints + matching MCP tools.
  • Team-scoped reasoning (Skill 5: find_relevant_voices) — ranks team profiles against a decision context using the 12 judgment-layer signals.
  • Team-scoped writes & recommendations (Skill 9: get_trust_recommendation) — delegation_preferences × scenario category lookup.

(Skills 6-8 are decision-capture, scoped under ADR-039 and tracked separately. Not in this deferral.)

The implementation rough-out for Skills 2-4 was started May 8, then halted before any code shipped after the user asked "why do you need Beacon team in DB so badly for L1-3?" The honest answer is: L1-3 doesn't need the team in DB at all. The team-DB requirement only kicked in for the team-query extensions. That observation surfaced a real prioritization question.

At a glance

What it decides: don't build the team-scoped Hermes skills (2-4, 5, 9) yet — no API endpoints, MCP tools, Postgres functions, or skill copy until real-user demand arrives. Deferred — revisit when a real user asks for agent-visible team data, a prospect names team coordination as an adoption blocker, F1 is validated end-to-end (≥3 members using Skill 1 for ≥1 week), or ADR-039 decision capture ships.

  • Core reasoning — F1 (chief-of-staff, Skill 1) is the v1 GTM bet; team skills (F2) shouldn't ship before F1 is validated with real users.
  • Pre-built features rot — unexercised team-query code can't be verified against real data and would need rebuilding when demand lands.
  • Prerequisite missing — Skills 2-4 need the Beacon team in DB + tagged campaigns, still a pending setup item.
  • Main rejected alternative — "build 100% of the brief now"; rejected as pre-emptive scope off F1's critical path.
  • Cheap to resume — when triggered, the build is mechanical (3 functions, 3 routes, 3 MCP tools, 1 skill update); the hard design work is already done.

Decision

Defer Skills 2-4, 5, and 9. Do not build the API endpoints, MCP tools, Postgres functions, or skill copy until at least one of the trigger conditions below is hit. Document the deferral here so the work isn't quietly forgotten and so future-us can pick it up cleanly.

Rationale

Three reasons:

  1. F1 (chief-of-staff) is the v1 GTM bet, not F2 (orchestrator/team coordination). James said it explicitly on the May 7 daily sync — "I think that really all we need for this first phase is one through three." L1+L2+L3 = Skill 1. The Ryan-Sarver case study works on Skill 1 alone. Building team skills before the F1 bet is validated is pre-emptive scope.

  2. Pre-built features rot. Skills 2-4 sit unexercised until users ask for team queries. Between now and then, Cici's queries may evolve, the schema may shift, real usage may not match assumptions. Code that's never run against real data isn't "done" — it's "unverified." When demand arrives, you'd either rebuild or carry stale code.

  3. The team-DB setup itself is a prerequisite. Skills 2-4 require the Beacon team to exist in DB + 4 historical multiplayer campaigns tagged. That setup is still pending from a May 4 action item. Building the read-side before the data exists means we can't even verify our own work end-to-end.

Alternatives Considered

  • Build Skills 2-4 now ("100% of the brief"). Rejected: pre-emptive scope without demand signal. The "carry-cost" argument from §opportunity-cost in our May 8 thread: time spent building Skills 2-4 is time not spent verifying L1-3 in real life, writing the case study, doing GTM outreach, or pairing with Cici on profile/team UI. The team skills will eventually need building, but not on F1's critical path.

  • Build Skill 5 (find_relevant_voices) without 2-4. Rejected: Skill 5 depends on the team-query primitives (alignment, voice patterns, fault-line categorization). Building Skill 5 first would force inlining those primitives into the reasoning skill, then later refactoring out — wasted work.

  • Build the SQL Postgres functions speculatively, defer the API+MCP+skill layers. Rejected for the same reason as the previous: half-finished implementations violate CLAUDE.md's "don't half-ship" rule. The functions without the route handlers can't be tested.

  • Build a cut-down Skill 2 only (just alignment). Considered but not chosen: the marginal cost of Skills 3+4 once Skill 2's plumbing exists is small, so cherry-picking doesn't save much. If we're going to defer, defer cleanly.

Discussion

The user asked a sharp question on May 8: "Why do you need Beacon team in DB so badly for L1-3?" The answer surfaced that L1-3 (the chief-of-staff thesis) needs zero team setup. The team-DB requirement only started mattering at the point I'd just begun on the team-query extensions — which weren't actually on F1's path.

Before this question, the trajectory was "implement 100% of the brief" — nine skills, multi-week. After: a much sharper picture of what's actually load-bearing for v1 GTM. The deferral isn't about whether team skills are valuable (they are; the company-brain thesis hinges on them). It's about whether they should ship before the chief-of-staff thesis is validated with real users.

CoachJ's framing on the same day: "Force [forget] the skills. I'm less concerned about team skills." L4-5 (orchestrator runtime + A2A endpoint) are higher priority than team skills because of the Raid Guild / MetaClawTel GTM angle James surfaced on May 7. The orchestrator can be useful even without the team-skill bundle filled in — those skills can be added once F1 is validated and the data + demand both exist.

Cici's parallel work on team profile views (May 7 1:1) means the visualization side of team coordination is in flight regardless. When her designs land and a real user asks "can my agent see this team data?", that's the demand signal that triggers Skills 2-4.

Consequences

  • F1 (chief-of-staff) ships without waiting on Skills 2-4. Skill 1 + L4 + L5 form a minimum viable F1+F2 v1 — chief-of-staff for personal queries, orchestrator for cross-agent coordination. Team-specific reasoning is a v2 add.
  • The brief's §5 skill table now has "deferred" status visible against rows 2-5 and 9. Brief should reference this ADR.
  • Beacon team in DB setup remains a backlog item but is no longer a blocker — it's needed when team skills come back, not before.
  • Cici's team-analytics handoff doc (docs/handoff-team-analytics-cici.md) is preserved for the eventual revisit. Don't delete or rewrite — it's the design source.

Triggers for revisit:

  1. A real user (Cici, James, future Beacon team member, or external pilot like Lena) asks for "my agent should see team data."
  2. The case study lands and a Ryan-Sarver-style prospect explicitly asks about team coordination as a prerequisite for adoption.
  3. F1 is validated end-to-end (≥3 team members using Skill 1 actively for ≥1 week with structured feedback) and the natural next direction is team layering.
  4. ADR-039 (decision capture) ships and surfaces team-decision queries as a needed analytics surface.

When triggered, the build is mechanical: three Postgres functions, three API routes, three MCP tool definitions, one Hermes skill copy update. The hard work (Cici's SQL, the schema, the auth model) is already done.

Key files: - docs/briefs/sync-hermes-agent-brief.md §5 — skill table; mark Skills 2-5, 9 as deferred per this ADR - docs/handoff-team-analytics-cici.md — design source for the eventual implementation - src/lib/agent/mcp.ts — where the new MCP tools would land - src/app/api/agent/v1/ — where the new endpoint dirs would go