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. Corrected in call 2: Justin flagged this as a transcription error — what he actually said was that Copilot does load all of the cloud skills, so both surfaces have access to the review-loop skill. No structural Copilot/Hermes gap; the original miss was adoption, not tooling.
• 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. Call 2: the interim answer in practice is session-lens — it now doubles as a session/skill manifest per agent (surfaced when Sage asked Justin how he was publishing sites and he pointed her at session-lens rather than a wiki).
• Wiki proposal — resolved in call 2. 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) is what actually matters. Call 2 outcome: the group settled on Ryan's side — no dedicated wiki; people ask their own Hermes to query for what's available (e.g. via session-lens across other agents' sessions) rather than maintaining a separate doc. Pulling off the wiki idea unless a strong new case is made.
• Mandatory vs. voluntary shared skills — still unresolved, tentative lean in call 2. Sage's original proposal: make certain shared skills (e.g. the PR review skill) auto-included in Hermes by default instead of opt-in. Justin's read in call 2: the team may already effectively do this via the shared cloud skills directory that gets injected into every agent, but he's not certain that's what Sage meant — not a firm close.
• Daily visibility mechanism — advanced into a concrete action item in call 2. Ryan's original proposal (a cron/digest reviewing skills built or used each day) got real texture this call: distinguish it from the existing hive-dream digest, which Ryan characterizes as blocking-focused and "hard to read," not skills-focused. New framing (Ryan): model it like a newspaper front page — terse, high-level per-agent headlines ("Ryan built a new CLI tool for accounting via Hermes") that link out to detail, the same editorial approach he already uses for the Rosenblatt Ops Digest. Action item (Justin): a first pass at a per-agent "what skills/tools people are using" review, separate from hive-dream.
• BWS / secrets literacy — mostly resolved per call 2, kept as a soft flag. Sage had missed the Bitwarden migration entirely as of call 1. Justin in call 2: hasn't heard of anyone still not using it, so treating it as resolved in practice, but keeping a reminder flag in signaling rather than dropping it outright.
• Bedrock guardrails, /swarm tool (future). Carried forward from before call 1; not discussed in call 2 either.
• Webhook dispatcher / peer registry reuse. Still the proof point from workshop 1 that this guild has real value. Restated in call 2: the dispatcher is available for webhooks, but Justin is still unsure whether anyone is actually using it — uptake unclear either way.

What call 2 surfaced (2026-07-15)

• Messaging-platform reliability for agents (new). Justin lost access to his own agent for a stretch: Hermes lacked exponential backoff on Slack calls, and a burst of ~500 messages in an hour got the bot rate-limited/disabled by Slack. Ryan flagged this as feeding a broader, still-informal concern that Slack "isn't the best messaging platform for agents" (he's also been using Discord with Hermes, with similar results) — explicitly punted as low priority, not a guild action item right now.
• Proactive secret-leak guardrails (new action item). Ryan flagged recurring "oops, I accidentally read your .env" incidents from his agent. Justin's proposed fix: port the pre-tool-use hook pattern he originally set up for the dev container (checks/denies tool calls that would read `.env`-style files) over to Hermes, which doesn't have an equivalent guardrail today — named as a real, current gap.
• Retroactive secret-leak cleanup (new idea, not yet built). Ryan's follow-up question: once a leak happens, how do we scrub it from session history rather than relying on manual key rotation? Justin's proposed approach: reuse the observability pipeline's existing secret-scanning/stripping logic (already applied when sessions aggregate into the observability volume) as a cron that sweeps session data directly. Automatic key rotation was discussed as a stretch goal (e.g. via an admin box triggered by detecting a leak in observability data) but flagged as only partially feasible — some providers require manual portal rotation with no CLI/API path.
• Repo/PR hygiene pass (new action item). Eugene raised the number of stale-looking cards in the Rosenblatt monorepo. Walking through them live: two of Justin's oldest open items (Jiu Jitsu dev-container integration + related workspace skills) can close since the team never activated that route; a ProServices agent-clone item can close since that effort was abandoned and won't be picked back up; a webhook item and a "refresh to index" item are likely closable pending a quick look. A couple of older items from Owen and Andreas remain open, not owned by Justin or Eugene. Action item (Justin): work through the closable ones after this call.

Knowledge gap

Converging: the wiki-vs-accessibility fork resolved toward query-based discovery (session-lens), and the manifest/visibility ask now has a concrete next deliverable (a per-agent skills-usage digest) rather than sitting as an open question.

Business outcome

Still open — not discussed in call 2. Ryan's call-1 framing (reduce duplicated skill-building) remains the only candidate on the table, still with no agreed target.

Permission

Not discussed in call 2 either — carried a second time.

OKRs / KPIs, timeline, go/no-go

Not discussed. Mandatory-vs-voluntary skills remains the fork most likely to gate this, and it only got a tentative lean in call 2, not a decision.

Carried to next Wednesday

• Mandatory vs. voluntary skills. Sage's proposal to auto-include certain shared skills by default in Hermes. Call 2 offered a tentative partial answer (the existing shared cloud-skills directory may already cover this) but Justin was explicit he's not sure that's what Sage intended — needs Sage's own read before this can close.
• Steward — still not assigned; not raised in call 2 either. Justin continues running the call de facto.
• Guild artifact — still not formally named, but a clear frontrunner emerged in call 2. The wiki-vs-accessibility fork that was blocking this resolved this call, and the daily skills-usage digest went from candidate to an assigned action item (Justin, first pass after this call) — the closest thing to a named artifact so far, just not yet formally adopted as "the" artifact.
• Business outcome, permission, and OKRs/KPIs — none of the last three template questions have been reached across two calls now.
• New from call 2: Hermes secret-handling guardrails (proactive hook + retroactive scrub/rotation) and the repo/PR hygiene pass are both real action items with no committed completion date yet.

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).

What call 2 surfaced (2026-07-13 — Swarm Demo & Workshop)

• Call 1's concrete commitment delivered. Sage and Justin ran the Kanban/dashboard show-and-tell on the Monday target, for Andres, Eugene, and Justin Griffin (Ryan and Owen absent). Covered task/profile creation, Slack-driven Kanban control, per-profile model assignment, work-tree isolation, and auto-delegation.
• Two contrasting swarm approaches demoed directly, addressing the "orchestration skill vs. Kanban-specific skill" distinction from call 1. Justin's plan-first approach (draft a plan doc with Copilot, decompose into a dependency-sequenced DAG of tasks — his working pattern on the Novi engagement). Sage's goal-first approach (minimal prescription, an explicit start/end-state ticket, higher trust in the orchestrator to explore) — which she reported gave her a real one-shot outcome: a Copilot Cloud session, seeded only with Zach's Slack message and a screenshot, produced a PR he confirmed was exactly what he wanted.
• "When to swarm vs. not" discussed again, still unresolved. Ryan reframed it as ad hoc/webhook-triggered response (agent sees a Slack message, drafts a PR immediately, no planning phase) vs. planned swarm work — and named it explicitly as something that "is going to be tricky over time to figure out." Sage's counterpoint: even the Kanban orchestrator isn't the top of the pyramid — Slack-triggered "create a goal-mode swarm" requests are already a layer above it.
• Resource/task budgeting flagged as a future problem (Ryan). Once running on the team's own GPU cluster rather than a metered inference provider, tasks will need explicit budgeting (model choice, speed, memory, tools) — not urgent yet, becomes real once the cluster hits its own limits. Justin extended this to ROI/value-per-token-spent as tasks get distributed across the team.
• BWS/secrets literacy hit in practice, not just named as a gap. Sage discovered her container had dropped Bitwarden-sourced secrets after a weekend Docker rebuild (an active auth issue she's still triaging). Ryan separately found a secret that had been stored directly in a container rather than Bitwarden and flagged it as a "big no-no" — reinforcing that config values belong in the compose file's environment section (version-controlled) and secrets belong in Bitwarden exclusively, never in an env file. Eugene also hit a broken dev container post-weekend-reset, still debugging.
• Cluster work back on Ryan's plate this week (renewed intent, not yet resolved). He'd deprioritized it for operations work; explicit swarms do not require the cluster to be running today, but he's hoping to get the cluster stable enough this week to also unlock self-hosted model endpoints.
• Follow-up commitment: an ad hoc Tuesday call for everyone to bring their own swarm attempt from the week and compare notes — distinct from, and in addition to, the regular Thursday cadence.

Knowledge gap

Call 1's finding (lack of hands-on Kanban reps) is being directly addressed: the Monday show-and-tell gave Andres, Eugene, and Justin Griffin their first real exposure, and a Tuesday follow-up is scheduled specifically so people can bring their own attempts. Not closed yet — attendees haven't run their own tasks independently as of this call.

Business outcome

Still not settled. The client-facing swarm framing question from call 1 was punted to Monday's Delivery/Consulting call; that call (also 2026-07-13) touched adjacent demo-storytelling ground but did not explicitly resolve the Sage-vs-Ryan client-value framing debate.

Permission

Not discussed in call 2 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Not raised again in call 2; the mandatory-by-default-skills-vs-accessibility fork from Tooling that was expected to inform this is still unresolved there too.

Carried to next Thursday

• Business outcome, permission, and OKRs/KPIs — none of the last three template questions have been reached across two calls now.
• When to swarm vs. not. Discussed again in call 2 (Ryan's ad hoc/webhook framing vs. planned swarms) but still explicitly unresolved — Ryan named it as something that will stay tricky to pin down over time. Don't restart from zero: workshop 1 (2026-07-03) already seeded an answer — the constraint is scope-fit plus a decomposition-judgment gap, not reliability (Andres: no pressure, current workflow covers typical scope; Owen: blocked on not yet having an end-to-end feel for decomposing a task into swarm roles), and Sage's Intravia whole-broken-UI rebuild was named the clearest swarm-worthy case: large, messy, whole-system tasks, not routine tickets.
• Cluster/infra ownership. Still trending toward a dedicated platform role rather than a guild topic — not yet formally decided who owns it, though Ryan signaled renewed personal intent to work on it this week. Carried prescription from the workshop-1 primer (Team Topologies): when this gets chartered, name its interaction mode explicitly — the cluster should run X-as-a-Service (self-serve, minimal back-and-forth), with high-bandwidth Collaboration mode reserved for time-boxed discovery only, because single-person pods have the least slack to absorb coordination overhead.
• Steward — Justin and Sage self-appointed "for now," pending a firmer answer. Not revisited in call 2.
• Guild artifact — not named. The workshop-1 charter standard expects each guild to own a concrete, build-on-able artifact (Owen's framing); Orchestration hasn't named one yet, though the demo/show-and-tell format and the planned /swarm tool are candidate shapes.
• Hermes onboarding, table stakes. BWS/secrets literacy moved from named-gap to lived-incident this call (Sage's dropped secrets, Ryan's found-in-container secret) — reinforces it's still the real blocker, not resolved by the incident being caught. Bedrock API key setup and the new Slack agent update were not discussed in call 2 and remain open.
• Cluster availability & reliability. Outbidding protection, possible multi-provider fallback, and a rate-limiter/gateway were not specifically discussed in call 2 — still open, though Ryan flagged general renewed intent to get cluster work done this week.
• Swarm SDLC / experience. Call 2's demo is a first step toward spreading hands-on experience beyond Justin H. and Ryan (Sage now has a demoed one-shot win; Andres/Eugene/Justin G. got their first exposure), but nobody outside Sage/Justin/Ryan has run their own task independently yet — that's exactly what Tuesday's ad hoc follow-up is for.
• 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. Not discussed in call 2.
• Justin's own carried-over action item, still not done. Packaging his existing personal workflows (incl. a Kanban blocked-task triage/escalation cron he built) into shareable tooling — not discussed in call 2, still outstanding.

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.

What call 1 surfaced

• Urgency still not settled — Ryan's live caution repeated at the top of this call. He explicitly flagged this isn't a burning issue compared to Orchestration/Tooling; the call opened with Justin naming that flag and asking the group to gut-check focus and cadence (weekly vs. occasional) before diving in. Not resolved by the end of the call.
• Demo standardization (knowledge gap) — real discussion, no resolution. Andres's ask: standardize cadence and content of client-facing demos, not because the team lacks demo skill but because there's no shared playbook. Ryan's pushback: client constraints vary wildly (Intravia explicitly bans meetings, forcing async/Slack/gifs instead of live demos), so any standard needs to flex to the client rather than assume a live weekly slot. Landed on a looser framing (Ryan): a scaffold of demo principles — demonstrate pace, keep it fully explainable to a layman, favor a shareable/re-watchable artifact — rather than one fixed cadence.
• "Skeleton + negotiate" framing (Sage). Have a default shape for what a good demo looks like, then negotiate the specifics with each client rather than starting from scratch every time.
• Escalating-feedback-tiers idea (Sage). Start cheap (a screenshot) and escalate only as needed (a working-feature video, then a live session) to surface requirement misalignment early and cheaply — tied to a broader point that clients often don't know what they want until they see something concrete.
• Live-demo-driven-by-real-time-transcript concept (Justin), raised as a direction question, not decided. A surface where a live transcript drives visible changes to a design within seconds. Eugene's caution: client asks often encode an underlying intent/pain point rather than the literal solution requested, so any such tool needs to read intent, not just execute literally — take direct client asks "with a grain of salt."
• Client-playbook skill idea (Justin), tied to his own Novi/Shashpot handoff experience. A Hermes skill that guides a newly-assigned engineer through the right onboarding questions for a client, versus relying on ad hoc email/doc alignment as he did.
• Client-health-check idea (Ryan). Review recent Recall call transcripts and internal sessions for a given client to surface sentiment/urgency shifts (e.g. "client is pushing for things to go faster") more objectively than gut feel.
• LLM-judge-as-disambiguator idea (Sage), tied to swarm blocking functionality. Tune the swarm's judge LLM to detect when a client-derived task/ticket is too ambiguous and block it rather than run with a guess — referenced Owen's past work on English-language disambiguation as a possible base.
• Automated demo-video generation floated as plausible today, not yet built. Ideas discussed: an agent-generated Friday recap video from the week's commits (Sage), or a Cypress-recorded flow generated directly from a "write this as a demo" instruction (Ryan) — both framed as already technically reachable, not aspirational.
• Pricing tension (business outcome) — real discussion, no resolution. Retainer-based agreements sell well and move fast, but the team bills time-and-materials against them; as AI compresses actual hours worked, a fixed-scope task billed on old hourly assumptions risks under-billing relative to client-perceived value. Eugene's counter: hours are already just a proxy the client converts to a dollar figure in their head anyway, so the real number is the price, not the hour count behind it. No consensus reached on whether that argument generalizes past their specific biases.
• Revenue-concentration risk (Ryan), reframed as the more urgent problem than pricing mechanics. The real 2025-to-2026 issue was client/revenue concentration — one client dominating revenue and effectively suppressing pursuit of other opportunities — not a profitability problem. Current state (Intravia, Novi) is a material improvement over 2024/early-2025, but the bottleneck now is sales pipeline volume/velocity for larger (PE-backed, mid-market) clients, which Ryan attributes partly to his own sales-closing ability, not just pipeline volume.
• Scope question raised, not settled: should sales/pricing strategy discussions live in this guild call going forward? Justin asked directly; Ryan's view is these are mostly solo sales-floor brainstorming today (he's the only one on the sales floor) rather than team-actionable yet, but he left the door open rather than ruling it out.

Knowledge gap

Real texture from this call: demo standardization/principles, a client-playbook skill, and a client-health-check concept are all concrete candidates, but none chosen as the priority.

Business outcome

Pricing-model tension (retainer vs. time-and-materials vs. flat per-feature pricing) and revenue-concentration risk both surfaced as real business gaps; Ryan's framing that revenue concentration is the more urgent of the two was not explicitly contested, but also not adopted as the guild's stated business outcome.

Permission

Not discussed this call.

OKRs / KPIs, timeline, go/no-go

Not discussed this call. Tied to the still-open urgency question — a go/no-go on cadence itself is arguably the prerequisite here.

Carried to next Monday

• Caution flagged live (from before call 1, restated at the top of this call, still unresolved): Ryan's view that this isn't a current burning issue compared to Orchestration/Tooling — needs a real gut-check on urgency and cadence before investing more guild time.
• "Rosenblatt Consulting handbook" candidate idea (Sage's original proposal, from before call 1) — not explicitly discussed this call by that name, though the demo-standardization and client-playbook-skill threads are closely related. Carried forward as its own distinct idea rather than assumed folded in.
• Demo standards/scaffold — principles discussed, no final shared standard adopted.
• Client-facing swarm framing (punted here from Orchestration's call 1) — not explicitly picked up as its own agenda item this call; the demo-storytelling discussion touched adjacent ground but didn't resolve Sage's platform-differentiation vs. Ryan's open-source-parity framing debate from Orchestration.
• Pricing model direction — retainer-vs-time-and-materials tension named, no decision.
• Whether sales/pipeline discussions belong in this guild's cadence — raised, not settled.
• Guild artifact — not named. The workshop-1 charter standard expects each guild to own a concrete, build-on-able artifact (Owen's framing); Delivery/Consulting hasn't named one yet — the demo-principles scaffold, client-playbook skill, and "Rosenblatt Consulting handbook" ideas are all candidate shapes.