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.
• Guild artifact — not named. The workshop-1 charter standard expects each guild to own a concrete, build-on-able artifact (Owen's framing); Tooling hasn't named one yet. The skill manifest and daily-digest candidates are the obvious contenders once the wiki-vs-accessibility fork resolves.
• 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).

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.