Functional Guilds

The shared capability layer for the whole team — skills, MCP servers, and config that any agent should be able to pick up rather than rebuild from scratch. If it's reusable and not swarm-specific, it lives here.

Scope boundary (settled live, don't re-litigate): Orchestration owns swarm-specific architecture/SDLC; Tooling owns the general reusable capability layer — skills, MCP servers, config, anything meant to be shared across pods regardless of whether it's swarm-related. Cadence: Wednesdays, before standup.

What call 1 surfaced

• Review-loop skill — deeper than an awareness gap. Andres and Owen both tried it early and it didn't stick as habit; Ryan wasn't using it either and got called out directly for pushing unreviewed changes to the Rosenblatt repo. Root cause per Ryan: most hands-on coding happens through Copilot, which doesn't autonomously build or reuse skills the way Hermes does — a structural gap between the two surfaces, not just an adoption gap.
• Skill visibility / manifest. Andres and Owen's ask: nobody can currently see what tools/skills exist across agents, or which are shared vs. personal to one agent.
• Wiki proposal — contested, unresolved. Sage and Justin floated an auto-updating wiki hooked to the docs folder with unread-section indicators. Ryan pushed back hard: accessibility (agents that can query/search directly, e.g. Slack search for agents) is what actually matters, and he's shipped a lot of work without ever reading a wiki. Real disagreement, not yet settled.
• Mandatory vs. voluntary shared skills — unresolved. Sage's proposal: make certain shared skills (e.g. the PR review skill) auto-included in Hermes by default instead of opt-in, to remove the decision fatigue of knowing a skill exists and judging whether it fits your task.
• Daily visibility mechanism (candidate). Ryan proposed a cron job / daily digest that reviews new skills built each day or scans sessions to flag "there's already a skill for what you're doing." Connects to Justin's existing hive-dream prototype (a session-lens wrapper producing a nightly ledger of recurring blockers) as a possible base to build on rather than starting fresh.
• BWS / secrets literacy. Still real — Sage said she missed the Bitwarden migration entirely and was still operating on the old secrets paradigm.
• Bedrock guardrails, /swarm tool (future). Carried forward from before call 1, not discussed this round.
• Webhook dispatcher / peer registry reuse. Still the proof point from workshop 1 that this guild has real value.

Knowledge gap

Richer than the pre-call draft: not just "how to discover skills" but a decision-fatigue problem (Sage) — knowing a skill exists, judging whether it fits your task vs. what it was built for, and trusting it enough to use it. Visibility/manifest (Andres, Owen) is the most concrete sub-ask.

Business outcome

Still open. Candidate framing from Ryan: reduce duplicated skill-building (e.g. his own unshared operational skills) — no agreed target stated.

Permission

Not discussed this call — carried to next Wednesday.

OKRs / KPIs, timeline, go/no-go

Not discussed. The bigger fork to resolve first: mandatory-by-default skills (Sage) vs. accessibility/visibility tooling (Ryan) — the right OKR likely depends on which direction wins.

Carried to next Wednesday

• Wiki vs. accessibility-tooling. Sage/Justin's auto-updating wiki idea vs. Ryan's case that queryable accessibility beats a dedicated platform. Needs a decision, not more debate.
• Mandatory vs. voluntary skills. Sage's proposal to auto-include certain shared skills by default in Hermes.
• Steward — still not assigned; Justin has been running the call de facto.
• Business outcome, permission, and OKRs/KPIs — none of the last three template questions got reached this call.

How we design and run agent swarms well — sub-agent topologies, delegation patterns, and the infrastructure (GPU cluster, model serving) that makes swarms possible. Tied directly to the swarm mandate, and currently the most active, fastest-moving guild.

Scope boundary reaffirmed live: orchestration is patterns (sub-agent delegation, Kanban orchestration in Hermes, which model handles planning vs. execution); infrastructure is separate and ownership-based (cluster uptime, model serving) — related but kept distinct in discussion. Cadence: Thursdays, before standup.

What call 1 surfaced

• Same knowledge gap as Tooling. Most attendees (Andres, Eugene explicitly) don't feel confident driving Hermes Kanban orchestration hands-on — not a tooling-access problem, an experience-reps problem. Execution pressure crowds out the time to practice.
• Ryan's counter-data point. He's been running swarms heavily via raw Sonnet + GLM 5.2 (Sonnet plans, GLM executes at ~90%+ accuracy for ~10x lower cost) without ever touching the Hermes dashboard or Kanban — a live example that orchestration skill and Kanban-specific skill aren't the same thing.
• Rate-limiting awareness (Sage). Occasionally hitting Sonnet/AWS rate limiting; flagged that concurrent-execution limits and total-token limits are distinct constraints worth tracking as usage scales.
• Copilot as swarm "eyes" (Sage). A Copilot cloud session can run a local dev server and do manual-QA-style clicking/verification, giving models without native vision an effective visual-QA path. Sage is actively working this out.
• Client-facing swarm framing — open, no consensus. Prompted by Eugene's "does it matter to clients" question. Sage's case: differentiation is about the Rosenblatt platform, not the individual engineer, and volume/speed demos land better than naming the technique. Ryan's case: could demo via open-source rebuilds of a client's existing closed tooling (his DocuSign/DocuSel example) to show parity without licensing exposure. Punted to Monday's Delivery/Consulting call rather than resolved here.
• "When to swarm vs. not" — named explicitly as unresolved (Ryan). Batch-job framing today (no 24/7 cluster access yet); the line between swarm-worthy and not is still a live, unanswered question.
• Justin's own carried-over action items, still not done. Packaging his existing personal workflows (incl. a Kanban blocked-task triage/escalation cron he built) into shareable tooling — flagged again this call as outstanding, not yet started.
• Concrete commitment. Sage and Justin will run a Hermes Kanban/dashboard show-and-tell, targeting Monday (falls back to Wednesday if prep isn't ready).

Knowledge gap

Confirmed and specific: lack of hands-on reps with Hermes Kanban orchestration, distinct from general swarm/agent-delegation skill which some (Ryan) already have without using Kanban at all.

Business outcome

Not settled. Adjacent client-demo-value question raised but explicitly deferred to Monday's Delivery/Consulting call rather than answered here.

Permission

Not discussed this call.

OKRs / KPIs, timeline, go/no-go

Not defined. Justin flagged KRs/KPIs as still needed and tied it to a future call, but didn't lock a date on this call.

Carried to next Thursday

• Business outcome, permission, and OKRs/KPIs — none of the last three template questions got reached this call.
• When to swarm vs. not. Explicitly flagged by Ryan as one of the hardest open questions for the guild.
• Cluster/infra ownership. Still trending toward a dedicated platform role rather than a guild topic — not yet decided who owns it.
• Steward — Justin and Sage self-appointed "for now," pending a firmer answer.
• Hermes onboarding, table stakes (not discussed call 1, still open). Bitwarden Secrets (BWS) literacy is the real blocker underneath most other issues — wide gap between people (Ryan: ~30 secrets configured vs. others' ~2), plus Bedrock API key setup and the new Slack agent update.
• Cluster availability & reliability (not discussed call 1, still open). Outbidding protection (lost a running cluster to a competing bid with 5 minutes notice), possible multi-provider fallback, a rate-limiter/gateway in front of the box.
• Swarm SDLC / experience (not discussed call 1, still open). Justin H. was previously the only one with real hands-on swarm experience — blocked on the two items above being stable first. Partially overtaken by call 1's finding that Ryan now also has heavy hands-on swarm experience (via raw Sonnet + GLM), so this may need re-scoping rather than straight carry-forward.
• Action item, not started: build an explicit /swarm tool (assigned to Justin H.) once infra stabilizes — likely lands in Tooling once it exists. Also echoed in Tooling's own backlog.

The commercial and relationship side of client work — scoping, pricing, demoing, and the ongoing client-relationship layer Sage raised at workshop 1. Newer and less urgent than the other two per live discussion; still finding its first concrete outcome.

Merged from the original Delivery category plus the consulting/ client-relationship gap Sage raised at workshop 1 (rolled up per Eugene's suggestion — naming can still change). Cadence: Mondays, before standup.

• Candidate idea: a "Rosenblatt Consulting handbook" — standardizing how the team interacts with clients, sets expectations, handles disagreements (Sage's proposal, aimed at newer or less client-facing engineers).
• Caution flagged live: Ryan pushed back that this isn't a current burning issue compared to Orchestration/Tooling — worth a real gut-check on urgency before investing guild time here.