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.

What call 3 surfaced (2026-07-22)

• Doc vs. hive-kanban action-item drift (new). Justin flagged that the action items in this doc were extracted at a single point in time from the last tooling call, while he's since been running calls through the hive kanban board and deduplicating/updating items there independently — so the board's copies are now more current than this doc's, and the two need to be reconciled. Action item (Justin): roll the hive kanban board's updates back into this document.
• Repo/PR hygiene — live walkthrough, real progress. Justin: cleaned up his own older PRs, only two still in progress. Andres: asked to close or move along PR #44. Justin: will follow up with Owen on PR #38 (merge in, add docs). Eugene: several PRs from the E Solutions first-onboarding demo (including #91) he considers safe to self-merge since they're additive artifacts that don't affect anyone else.
• Human PR review on dev — tentatively reframed as mostly a blocker (new discussion, not fully resolved). Eugene raised whether mandatory human review before merging to dev is still a value-add given how much of the team's day-to-day coding now flows through Hermes-authored PRs already covered by AI/Copilot review. Justin's read: mostly a blocker at this point, especially when the PR-review-loop skill was already used — except when someone is editing shared harness/dev-container infrastructure directly, where a human eye still matters (ties to SOC 2's own approval requirement, which the team could in principle change but is wary of loosening for security reasons — self-approving automation was called out as the specific risk). Sage noted Copilot reviews may already be able to count as the official required review. Justin also described a GitHub CODEOWNERS-based approach (partially started, not finished) that could route review requirements per-subfolder, including bot-account auto-approval for lower-risk areas — flagged as worth revisiting, not decided. Working guidance for now: use best judgment, bypass when a change doesn't touch anything important.
• /swarm tool — explicitly put on hold (status change). Justin hasn't started building this and, after more time experimenting with swarms himself, isn't convinced a dedicated /swarm skill is the right move yet given how differently everyone on the team is already approaching swarms with base Hermes functionality. Deferred until there's a clearer shared need, rather than standardizing prematurely.
• Dev-container/VM infrastructure assessment for multi-client deployability (new action item, Eugene). Eugene is working with Hermes to review the team's current shared dev-container/VM setup (acknowledged as fast-to-stand-up but not built for access control or a less-transparent multi-person team) and think through what a client-deployable version would need to look like differently. Related threads raised live: EBS snapshotting for disaster recovery (Ryan already turned this on after a prior full-environment loss); whether a persistent-always-on gateway routing into per-request serverless/isolated compute (Daytona-style, or the Fly Sprites-style micro-VM pattern Justin described from a personal project) is the right target architecture. Not yet ready to report; explicitly framed as a likely input into a future swarm-driven infra migration.
• Supabase container sprawl (surfaced, not a guild action item). Eugene noticed a large number of Supabase-related containers running on the shared VM and asked who's responsible; nobody on the call claimed ownership of the full footprint (Sage: mostly uses a personal Lovable account; Andres: ran one locally, temporary). Left unresolved, flagged as "figure it out later," not assigned.

What call 4 surfaced (2026-07-29)

• AWS MCP working, but a real PII-exposure incident (new). Eugene confirmed his AWS MCP setup is now working (the earlier issue was Hermes hallucinating the wrong config URL; pasting AWS's own docs into Hermes fixed it). But while triaging a support ticket with it, his pro-service agent pulled live DynamoDB data and accidentally surfaced Social Security numbers. Reinforces the existing decision to keep client-facing agents in isolated containers — and raises a new concern that any agent with observability-service access could pick up the same PII if logs aren't scrubbed at the source.
• Guardrails are provider-specific, not organization-wide (new, higher-priority framing). Eugene's agent runs Bedrock guardrails v5 (PII filtering on, content filtering explicitly off for the client-facing bot). Justin flagged the structural risk this exposes: guardrails today live at the provider level (Bedrock has them; Fireworks, the provider Rosenblatt actually uses for most inference, does not), so if someone's profile switches from Sonnet to a Fireworks-hosted model like Kimi K3 for better reasoning, guardrails silently disappear with no warning. Discussed and rejected consolidating on OpenRouter (does have guardrails, but isn't the team's provider) in favor of building protection at the Hermes level instead, via its existing pre-tool-use / pre-LLM-call hook lifecycle — the only approach that stays consistent regardless of which provider a given profile is using. Action item (Justin): research building a provider-agnostic guardrail/classifier hook in Hermes.
• Hive-kanban task duplication is a real bug, not just doc drift (escalation of call 3's item). Justin flagged live that there are confirmed duplicate task cards on the hive kanban board from these very guild calls extracting overlapping action items across sessions — despite dedup logic that's supposed to prevent exactly this. Escalates the still-open "reconcile doc vs. board" item from call 3 into something more concrete: the dedup mechanism itself needs investigating, not just a one-time doc/board sync.
• Repo/PR hygiene — continued progress, no specifics logged. Eugene reports he's been steadily working through PR cleanup; no specific PR numbers or blockers raised this call (contrast with call 3's detailed walkthrough).
• Monorepo tooling gap (surfaced, not a guild action item). Eugene noted he avoided committing a ~100,000-line raw transcript JSON to git after finding it unwieldy. Justin's take: the team lacks Big-Tech-style monorepo tooling (sparse/on-demand checkout) and should aim for it eventually, but it requires rolling a custom VCS server rather than using GitHub as-is — not scoped as urgent.
• Browser control for Hermes (surfaced, personal exploration, not a guild item). Justin wants his pro-service support agent to triage tickets using session-replay tools (e.g. Mixpanel) that need real browser interaction; hasn't tried Hermes's browser-use capability yet but plans to test it with his own login credentials.

Knowledge gap

Not discussed in call 4; still resting on call 2's resolution (query-based discovery via session-lens) plus the still-in-progress per-agent skills-usage digest.

Business outcome

Still open — not discussed in call 4 either. 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 4 — carried a fourth time.

OKRs / KPIs, timeline, go/no-go

Not discussed. Mandatory-vs-voluntary skills remains the fork most likely to gate this, and it wasn't raised again in call 4.

What call 5 surfaced (2026-08-05)

• Hermes Bedrock integration — model availability confirmed. The full Bedrock model list is now available in Hermes. No per-model proof-of-concept needed; the integration is treated as solid. This removes a lingering question from earlier calls about whether Bedrock models would require individual validation before use.
• Guardrails design — Bedrock-only vs. generic MESOS approach. Continued the call 4 guardrails discussion with a design fork: configure guardrails as a Bedrock-only setting (simple, but leaves other providers unprotected as flagged in call 4) vs. build a generic MESOS approach that applies guardrails across all providers regardless of native support. Fireworks notably has no native guardrails, reinforcing the call 4 finding that a profile switch silently drops protection. No decision landed — the design question is still open.
• Beads CLI integration — Justin to claim. The beads task-tracking CLI (replacing the prior hive-kanban approach) needs integration into the guild pipeline. Justin agreed to take it on in the next couple days if no one else claims it first. This is the same migration that the guild-ingest cron job now uses for action-item sync.
• Gas City exploration. Brief exploration of Gas City — context carried from the 2026-08-04 guild design weekly where a Gas City fork was planned. Not yet a formal action item.
• Action item prioritization requested. Justin requested P0 flags on standing action items to help triage what's actually urgent vs. long-tail. This ties to the growing open-items list across multiple calls.

Knowledge gap

Not discussed in call 5; still resting on call 2's resolution (query-based discovery via session-lens) plus the still-in-progress per-agent skills-usage digest.

Business outcome

Still open — not discussed in call 5. 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 5 — carried a fifth time.

OKRs / KPIs, timeline, go/no-go

Not discussed. Mandatory-vs-voluntary skills remains the fork most likely to gate this, and it wasn't raised again in call 5.

What call 6 surfaced (2026-08-12)

• Beads bidirectional sync with Jira/Linear/GitHub (Justin, live demo). Justin showed beads syncing in real time with Jira issues — beads list can search through task metadata by Ticket ID, and changes in Jira (e.g. moving a ticket to "In Review") are reflected in beads instantly. The mirrored issues get their own beads IDs but retain the external link, making beads list + bd show a unified view across both systems. This is a concrete step toward beads as the shared task-tracking layer that complements (not replaces) Jira.
• Client isolation architecture (Justin, prompted by Andres). Andres asked about the standard approach for isolating a new client's beads integration. Justin walked through the ProService support agent pattern: a separate client-hermes-base Docker image that extends from hermes-base but removes the peer network, disables all firewalls by default (vs. the internal agents which get all firewalls by default), and has its own beads task graph. The motivating incident: Justin's personal agent immediately surfaced Social Security numbers from ProService data after adding one API key — a live PII-exposure warning that prompted the full isolation. Justin committed to writing a playbook documenting the steps. Eugene noted PII is "an eventuality" for any automated ticketing agent.
• Bedrock guardrails deactivated (Justin). Ryan deactivated Bedrock keys 1–5 in favor of Fireworks, meaning any profile relying on Bedrock's built-in guardrails no longer has them. This reinforces the call-4 action item for provider-agnostic guardrails via Hermes's hook system.
• Mixture of Agents (MoA) for PR review (Sage, live demo). Sage demonstrated her MoA setup: reference models (Kimi K2, DeepSeek, and previously MiniMax) each receive the same prompt with the PR diff, then an aggregator model (GLM 5.2) combines their outputs with its own perspective to produce the final review. Used for a real Intravia release review with 34 commits — she grouped commits into Kanban cards, each card ran an MoA review with a green/yellow/red stoplight system and confidence scoring (80%+ threshold). Cost: ~$3.50 vs. ~$50 for Sonnet. Key design insight: reference models can't use tools, so all context (diff, criteria) must be provided upfront in the Kanban card description. Sage also pulls CloudBot reviews into the loop for iterative refinement. She emphasized the adversarial architecture (multiple models trying to break the PR) as a benefit over Sonnet reviewing its own work.
• Profiles as infrastructure capabilities, not roles (Sage). Sage's profile philosophy: separate profiles by infrastructure needs, not by job function. A "review PR" profile exists because MoA is a different infrastructure than coding. A UI profile uses a model with visual capability (screenshots, browser) while the code-writing profile uses GLM 5.2 (no visual). This reframes the earlier "profiles as capabilities, not roles" discussion from the Consulting guild's call 2 in a concrete Tooling context.
• Shared profiles/presets injection (Justin, new proposal). Justin proposed injecting useful shared profiles and presets (like Sage's MoA PR-review profile) into everyone's Hermes automatically, reducing the friction of each person setting them up independently. Sage agreed a shared version would be valuable. Not yet a formal action item with a timeline, but a concrete next step identified.
• PII redaction tool (Sage, brief mention). Sage noted the need for a tool that strips PII before it even reaches the model — "I'm sure that'll come someday." Eugene referenced the Bedrock guardrail they used for this, but Justin noted Bedrock keys are now deactivated. Connects to both the guardrails action item and the client-isolation work.

Knowledge gap

Advanced concretely: beads-Jira sync is working, client isolation has a reference implementation (ProService), and MoA PR review has a working skill. But the mandatory-vs-voluntary skills question and the skills-usage digest remain untouched.

Business outcome

Still open — not discussed in call 6. 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 6 — carried a sixth time.

OKRs / KPIs, timeline, go/no-go

Not discussed. Mandatory-vs-voluntary skills remains the fork most likely to gate this, and it wasn't raised again in call 6.

What call 7 surfaced (2026-08-19)

• Kanban ticket description is the linchpin of MoA PR review (Sage, key insight). Sage explained why skipping the Kanban ticket breaks the entire MoA PR-review flow: the reference models (Kimi K2, DeepSeek, etc.) can't make tool calls — they're "brains in a jar" that receive only the ticket description as their input. So the orchestrator must create a fully-fleshed-out ticket with the diff and all relevant context before the MoA council can respond productively. Andres admitted he hasn't been using Kanban tickets for PR review; Sage said this alone is probably why he's catching less — not a tooling gap, an architecture assumption mismatch.
• Client-retrospective loop and git history as review-quality signal (Sage). Sage described her periodic manual client retrospective: a more powerful model reviews session history, Sol.md, and Memory.md, then performs "brain surgery" on the harness and skills based on what it observes. Git history feeds this loop — multi-round PR reviews reveal common failure points that should have been caught earlier, which become candidates for new skills. This loop engineering (retrospective → brain surgery → improved harness) is how her MoA PR-review profile evolves beyond a raw first deployment.
• Expanding the setup diagram: Investigate profile and multi-client architecture (Sage). Sage is building out her setup diagram with an Investigate profile designed for direct interaction — it puts the user through a "grilling session" to evaluate requirements. She found Qwen3 is good at investigating codebases but worse at writing code, so the architecture pairs Qwen3 for investigation with cheaper code-writing models for execution. The diagram also includes a multi-client concept (Client 1, Client N) and an Orchestrate profile that can search all other profiles' session histories to identify pain points in the overall loop and perform brain surgery on each profile. Sage characterized her trajectory as "Slack is just my work environment."
• Eugene working in Justin's ProService/Friday support setup. Eugene is getting used to Justin's pro-service support agent setup, which he described as "kind of like Swarm but for support tickets." All requests and responses are saved as markdown files — a valuable session history for future querying. Eugene noted that if volume grows, data storage solutions will need consideration (a concern that generalizes to all Hermes-based workflows). He deferred detailed explanation to Justin.
• Before/after screenshot capability for PR review (Sage, planned). Sage is looking into adding before-and-after screenshots of UI changes to her PR review, using Hermes's browser tool to capture the rendered HTML. Andres extended this to video click-through demos, referencing past Cypress playback experiments. Not yet built — next step after the screenshot feature.
• Hiring and interview process in the AI era (Andres, group discussion, not a guild action item). Andres raised that LeetCode-style interview questions are becoming less relevant as AI-assisted coding normalizes. Eugene proposed that the new signal is how well candidates ask questions, not just how they answer them. Sage shared research suggesting LeetCode tests compliance rather than coding skill. Group reflected on the contrast between startup creativity at Rosenblatt and enterprise constraint culture — a cultural rather than tooling discussion, not actioned.

Knowledge gap

Not directly discussed in call 7; still resting on call 2's resolution (query-based discovery via session-lens) plus the still-in-progress per-agent skills-usage digest. Sage's expanding setup diagram is an adjacent contribution but not a formal close on the knowledge-gap question.

Business outcome

Still open — not discussed in call 7. 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 7 — carried a seventh time.

OKRs / KPIs, timeline, go/no-go

Not discussed. Mandatory-vs-voluntary skills remains the fork most likely to gate this, and it wasn't raised again in call 7.

What call 8 surfaced (2026-08-26)

• Business-model productization: standardized service packages (Sage, key proposal). Sage is building a mind map of Rosenblatt's offerings structured into predefined service packages — an audit phase (low-cost, low-stakes entry point where both sides get to know each other), an implementation phase (the actual build work), and a maintenance phase (ongoing support). Each phase contains multiple package types (e.g. an AI-SDLC audit feeding into an AI-SDLC implementation feeding into AI-SDLC maintenance, based on frameworks like Anthropic's Playbook enhanced with Rosenblatt's own experience). The goal: give prospective clients a clear way to engage, make Rosenblatt's offerings legible enough that people can "put us in a bucket" and know who to connect them to, and work backwards from concrete business outcomes to prioritize Hermes agent capabilities rather than building random research projects.
• Standardizing business inputs to optimize Hermes agents (Sage). Closely tied to the packages proposal: standardizing what's needed to resolve a bug report, build a feature, or refactor something — so Hermes agents can be optimized around a constant input format rather than ad-hoc requests. This also tells clients exactly what to provide. Sage raised the possibility of plugging Hermes directly into customer support (citing the Intravia example where they kicked Rosenblatt out of their bug-reports channel because Claude couldn't handle the integration), positioning forward-deployed engineers as needing direct user connection.
• Sales pipeline and conversion as the real constraint (Andres, group discussion). Andres framed the core problem: Rosenblatt doesn't have enough incoming work to be selective, and one-off efforts (Sage's LinkedIn, Ryan's conference networking) aren't scalable. Hiring a salesperson was discussed but Sage argued the package structure must exist first — a salesperson needs a working engine to run with. Eugene noted the tension between being true to principles (saying no to unwanted work) and the reality of needing revenue to pay everyone. The group acknowledged they're in an "uncanny valley" of doing whatever pays the bills vs. focusing on AI engineering.
• Internal prioritization tied to business packages (Andres). Andres connected the packages proposal to the internal unassigned Kanban backlog: standardized packages give real context for prioritization — "if we do this, it helps us to this end on this client" — instead of everything being vaguely good with no clear incentive. He compared this to the MBA leadership concept of purpose and meaning in work: people engage more when they understand the impact of what they're building.
• Sage to compile discussion summary for Ryan (planned, not a formal action item). Sage plans to use the Recall.ai bot to capture the past few days' discussions around all of this and put together a summary package for Ryan, who's been busy. Not raised as a formal guild action item — a personal commitment.
• Rosenblatt scribe says "you pass butter" (Eugene, moment of levity). Eugene noticed the Rosenblatt scribe agent's description literally says "you pass butter" — a Rick & Morte reference that Sage appreciated. Not a tooling discussion item, but a noted cultural moment.

Knowledge gap

Not directly discussed in call 8; still resting on call 2's resolution (query-based discovery via session-lens) plus the still-in-progress per-agent skills-usage digest. Sage's packages mind map is an adjacent business-strategy contribution, not a formal close on the knowledge-gap question.

Business outcome

Closest the guild has come — Sage's packages proposal (audit → implementation → maintenance) is the first concrete articulation of what Rosenblatt offers as a business, but it's a proposal, not a guild-level agreed outcome. Still open as a formal template question.

Permission

Not discussed in call 8 — carried an eighth time.

OKRs / KPIs, timeline, go/no-go

Not discussed. Sage's packages could eventually enable per-package KPIs, but this wasn't raised explicitly.

Carried to next Wednesday

• Mandatory vs. voluntary skills. Sage's proposal to auto-include certain shared skills by default in Hermes. Not raised in call 5, 6, 7, or 8; still resting on call 2's tentative partial answer (the existing shared cloud-skills directory may already cover this), unconfirmed by Sage.
• Steward — still not assigned; not raised in call 5, 6, 7, or 8. Justin continues running the call de facto.
• Guild artifact — still the daily skills-usage digest as the frontrunner, not yet delivered. No change in call 5, 6, 7, or 8; the digest (Justin, first pass) remains in progress from call 2.
• Business outcome, permission, and OKRs/KPIs — none of the last three template questions have been reached across eight calls now. Call 8 came closest on business outcome (Sage's packages proposal) but it wasn't formally adopted as the guild's answer.
• Retroactive secret-leak cleanup — not directly confirmed as active work in call 5, 6, 7, or 8; carried forward, status unchanged.
• Sage's mandatory-vs-voluntary shared skills question — not raised in call 5, 6, 7, or 8; still needs Sage's own input.
• Eugene's dev-container/VM multi-client deployability assessment — not raised in call 5, 6, 7, or 8; still in progress, no output yet.
• Human-PR-review-on-dev policy question — not revisited in call 5, 6, 7, or 8; still only a tentative working answer (use judgment, bypass when safe), not formally closed.
• Provider-agnostic guardrails via Hermes's hook system (from call 4, reinforced in call 6 by Bedrock key deactivation) — Justin, not yet started.
• Hive-kanban task duplication investigation (from call 4) — Justin, escalated from the doc-reconciliation item, not yet started.
• From call 6: write a client-isolation playbook (Justin, based on ProService pattern); inject shared Hermes profiles/presets automatically (unowned, Justin to investigate feasibility); PII redaction tool (Sage flagged, no owner 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.

What call 3 surfaced (2026-07-16)

• The ad hoc Tuesday follow-up call did not happen. No mention of it in call 3 — not confirmed run and not referenced as having occurred; carried forward as still-open below rather than assumed done or quietly dropped.
• Ryan's GPU cluster work: real progress, new blocker. "Tons of progress" earlier in the week on the cluster itself, but launching Copilot Remote sessions against a custom (self-hosted) endpoint is now blocked — Ryan believes it's related to endpoint configuration; he has PRs open against it.
• Jiu Jitsu vs. Git worktrees — explicit decision reached. Justin walked through the difference (Jiu Jitsu adds a cross-worktree coordination/auto-merge layer on top of what Git worktrees already do). Sage and Ryan both pushed on concrete ROI; Ryan's conclusion, which the group did not challenge: the team doesn't run swarms often enough yet to know how much Jiu Jitsu conflict-resolution would actually save, so standardize on Git worktrees for now (already wired into Hermes Kanban, Copilot, and other CLIs) and treat Jiu Jitsu as "the clear next step" once usage grows — not yet earned. Justin's own Start Session / Finish Session skills already fall back to Git worktrees when Jiu Jitsu isn't installed, which is the case team-wide today (his Jiu Jitsu integration PR is still unmerged).
• Sage's parallelization framing. Read Jiu Jitsu as unlocking Claude-Code-Teams-style peer coordination between sub-agents (vs. today's sequential/waterfall hand-off, or a hub-and-spoke sub-agent model where everything reports back through one orchestrator) — and connected it to reduced token waste and failure surface from merge-conflict/rebase churn as swarm scale increases. Not disputed, but subordinated to Ryan's "haven't earned it yet" read for now.
• Andres: still mid-setup, deprioritizing the Kanban board. Focused on getting his agent's Slack integration working (a dedicated demo channel to POC-demo the AI to "the Index" — a client-facing show-and-tell) rather than hands-on Kanban reps; hit an environment-variable mismatch between his DM-based agent and the channel-based one, still unresolved. Separately built a coder profile using GLM 5.2 as an orchestrator for task decomposition + delegation.
• Ryan flagged Andres's own work (Trace, Android/mobile) as a weak swarm fit — emulator-based testing doesn't harness cleanly the way web-app work does.
• Eugene: still no swarm use case, but heavy daily-driver use of Hermes for automation (cron jobs, ad hoc ops questions) — framed as "getting my reps in" on the base tool while he waits for a task that actually needs swarm.
• Case-study framing (Ryan, riffing on Bun's Rust rewrite). The team has a concrete, sizeable opportunity — the Travia AWS full-stack migration — that could produce the "we ran agents overnight and migrated everything in a day or two" story the guild has been missing, but it's stalled on the client's own hesitation to pull the trigger, not on the team's capability. ProServices work was named as a structurally poor swarm fit (too ad hoc, no big up-front plans to decompose).
• Two small concrete swarm exercises volunteered for this week (see Action items): Ryan's GLM 5.2-vs-Sonnet 5 cost/quality A/B test, and Sage's Lovable-template-to-AWS conversion, both explicitly framed as ways to get low-risk reps and build the evidence base the case-study conversation above needs.
• Ryan's AI spend as a data point. Over $1,000 personal AI spend so far this month, split roughly 50/50 between Bedrock (Hermes) and Copilot; his stated direction of travel is to stop thinking "Hermes vs. Copilot" and start thinking of them as one combined harness — swarms are, in his view, the natural mechanism for that.
• Justin's own read on swarm value: delegation, not raw parallelism. Reflecting on Nothi, he argues the real value of swarming (vs. driving Copilot manually) is being forced to explicitly decompose a plan and route each piece to a differently-specialized agent/profile — a step that's easy to skip when working solo. Sage agreed this is the higher-priority investment ("a really good delegator") ahead of Jiu Jitsu, calling it a multiplier on current effort rather than added maintenance overhead.
• Shared-hive delegation as a Rosenblatt-specific structural advantage (Justin). Because every agent here already shares a VM architecture and is interconnected, a swarm task could in principle delegate across Ryan's and Sage's sub-agents too, picked by track record — something Justin believes most peer companies can't do because they run isolated per-person VMs. Ryan connected this to the org's existing observability/"dreams" work and framed it inside a broader thesis: build the conditions to safely capture emergent multi-agent behavior as the underlying models improve, rather than only planning around today's capabilities.

Knowledge gap

Progressing but not closed. Call 2 gave Andres/Eugene/Justin G. their first Kanban exposure; call 3 adds an explicit, named diagnosis (Ryan: the team isn't running swarms often enough to have earned tools like Jiu Jitsu yet) plus two concrete individual exercises (Ryan's model A/B test, Sage's Lovable-to-AWS conversion) aimed at generating real reps and evidence this week.

Business outcome

Still not settled after three calls. Call 3 reframed the question via a concrete near-term opportunity (Travia AWS migration as a case study) rather than resolving the original Sage-vs-Ryan client-value framing debate from call 1.

Permission

Not discussed in call 3 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Not raised again in call 3.

Carried to next Thursday

• Business outcome, permission, and OKRs/KPIs — none of the last three template questions have been reached across three calls now.
• When to swarm vs. not. Partially reframed in call 3: Ryan's "haven't earned Jiu Jitsu yet" argument is really a specific instance of this broader question (not enough swarm volume yet to know which tools pay for themselves). The underlying scope-fit/decomposition-judgment framing from workshop 1 (2026-07-03) still stands unresolved: Andres's current workflow covers typical scope without swarm pressure; Owen is blocked on not yet having an end-to-end feel for decomposing a task into swarm roles; Sage's Intravia whole-broken-UI rebuild remains the clearest named swarm-worthy case (large, messy, whole-system, not routine tickets).
• Jiu Jitsu adoption — explicitly deferred, not abandoned, in call 3. Decision: standardize on Git worktrees for now (already integrated across Hermes Kanban, Copilot, other CLIs); revisit Jiu Jitsu once the team is running swarms often enough to make its coordination/auto-merge features pay off. Justin's own integration work (Start Session / Finish Session skills, which fall back to worktrees when Jiu Jitsu isn't installed) continues on his personal side regardless.
• Cluster/infra ownership. Still trending toward a dedicated platform role rather than a guild topic — not yet formally decided who owns it. Call 3 update: Ryan made real progress on the cluster itself this week, but hit a new, distinct blocker (Copilot Remote sessions against a custom endpoint) that's now the active gate on unlocking self-hosted model endpoints (tracked as its own action item). Carried prescription from the workshop-1 primer (Team Topologies) still applies once 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 3.
• 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. Candidate shapes on the table remain the demo/show-and-tell format and the planned /swarm tool; Sage's proposed Lovable-to-AWS swarm exercise is a new candidate too if it produces a reusable Hermes skill as intended, but nothing has been formally named yet.
• Hermes onboarding, table stakes. BWS/secrets literacy moved from named-gap to lived-incident in call 2 (Sage's dropped secrets, Ryan's found-in-container secret); not directly revisited in call 3, though Andres separately hit an unrelated environment-variable mismatch between his DM and channel agent contexts, still unresolved on his end. Bedrock API key setup and the new Slack agent update were not discussed in call 3 and remain open.
• Cluster availability & reliability. Outbidding protection, possible multi-provider fallback, and a rate-limiter/gateway were not specifically discussed in call 3 — still open.
• Swarm SDLC / experience. Named directly and repeatedly in call 3 as the guild's core current blocker — Ryan: "our biggest problem is people are not experienced with swarms yet... I don't think people are experienced with git worktrees yet." Two concrete individual exercises are now planned this week (Ryan's GLM 5.2/Sonnet A/B test, Sage's Lovable-to-AWS conversion) specifically to start closing this gap with real evidence rather than more discussion.
• 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 3.
• Justin's own carried-over action item, now in progress. Packaging his existing personal workflows (incl. a Kanban blocked-task triage/escalation cron he built) into shareable tooling — call 3 surfaced concrete progress (his Start Session / Finish Session skills, used on every one of his own sessions) but they're still personal-monorepo-only, not yet packaged for the team, and still gated behind his unmerged Jiu Jitsu integration.
• New: Copilot Remote session launches against a custom endpoint are blocked. Surfaced 2026-07-16 as a distinct blocker from general cluster stability — Ryan has PRs open.

What call 4 surfaced (2026-07-23)

• Lovable-to-AWS swarm exercise delivered, with real lessons (Sage). Converted a simple Lovable app (auth, DB-backed ticket-triage/bug-reporting flow with row-level table restrictions) to AWS Amplify using an official AWS Amplify template repo as the starting foundation. Core finding: treating the swarm's primitive as individual lines of code produced a much higher failure rate (five or six failed deployments before a working one, including a mangled reimplementation of Supabase Auth instead of using Amplify's own Auth component) — raising the primitive to the component level dramatically improved results on a second pass.
• LLM-as-judge + component-library restriction pattern (Sage). Used an LLM-as-judge to review work and restrict every worker/ticket to an existing component library (e.g. Amplify UI's rows/columns/design-system primitives), blocking and pinging a human when a task falls outside what the library covers, rather than letting the worker freehand a bespoke implementation. Sage's proposed follow-up (not yet started): capture AWS Amplify deployment errors observed this run and feed them back into the Copilot-facing skill set so future swarms avoid the same mistakes — benefiting both the code-writing agent and Hermes's own review-loop skill, independent of which coding tool is doing the writing.
• Deterministic linting as a cheaper enforcement layer than the judge (Sage). Proposed adding a linter to a template repo that checks Copilot's output for compliance (e.g. whitelisting Amplify UI components) and fails the session/PR check on violation — reasoning that a judge reviewing every worker session is a slower, higher feedback-loop than getting the failing worker itself fast, tight, deterministic feedback (\"loop engineering\": push feedback to the smallest, tightest loop possible rather than routing everything through the top-level judge).
• Contract-first vs. composite framing (Justin). Drew a parallel to monorepo-wide shared interface/schema contracts he's seen at past big-tech employers (e.g. a shared protobuf schema directory services plug into) as a way to pre-define the connection points between swarm-built components, rather than having the swarm rediscover integration boundaries each time. Sage's response: AWS Amplify's Auth component is itself an example — a pre-built contract to Cognito (OAuth, social login, verification codes) that removes an entire category of integration surface from both the human's and the agent's mental model. Framed as a live discussion, not a decided direction.
• "Choice is liability" as a working principle for swarms (Sage). Her proposed heuristic: give a swarm worker just enough choice to reach a goal — too little (e.g. dictating exact pages) forces mismatched templates; too much (line-of-code level) multiplies failure surface. Component-level composition sits in the sweet spot for her Lovable-to-AWS case.
• Real cost data point. The small demo app run cost roughly $20-50 per attempt. A contact Sage met at an external AI event, who'd done a comparable Microsoft-to-AWS migration on a larger app, reported ~$1,000 for that migration — offered as a rough real-world scaling anchor, not a Rosenblatt-run number.
• Possible new client lead from the same external event (Sage, tentative). A contact's "$250 million friend" is reportedly struggling with a Lovable-to-AWS transition and may want to connect; unconfirmed as of this call (email not yet answered), not a guild action item, flagged for visibility only.
• Short call, Ryan absent. No cluster/infra update this call; Justin opened by noting Tooling and Orchestration discussion has been blurring together lately, with few new actionable items surfacing from calls beyond what's already tracked.

Knowledge gap

Real progress: Sage's delivered exercise is the guild's first concrete, evidence-backed swarm case study (composability lessons, cost data, failure modes) rather than a planned/discussed one. Ryan's parallel A/B test is still unconfirmed as run.

Business outcome

Still not settled after four calls. Not discussed in call 4.

Permission

Not discussed in call 4 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Not raised again in call 4.

Carried to next Thursday

• Business outcome, permission, and OKRs/KPIs — none of the last three template questions have been reached across four calls now.
• When to swarm vs. not. Not raised in call 4; still resting on call 3's partial reframing (Ryan's "haven't earned Jiu Jitsu yet" as one instance of the broader question) and the original scope-fit/decomposition-judgment framing from workshop 1.
• Jiu Jitsu adoption — still deferred per call 3's decision. Not revisited in call 4.
• Cluster/infra ownership. Not discussed in call 4 (Ryan absent); still trending toward a dedicated platform role, not yet formally decided.
• Steward — still Justin and Sage self-appointed "for now"; not revisited in call 4.
• Guild artifact — a strong new candidate emerged in call 4. Sage's Lovable-to-AWS conversion was explicitly framed as aiming to produce a reusable Hermes skill; if that skill materializes (plus her planned skill-feedback-loop for Copilot's Amplify errors), it's a stronger concrete artifact candidate than the demo/show-and-tell format or the still-unbuilt /swarm tool. Not formally named yet.
• Hermes onboarding, table stakes. Not directly revisited in call 4; Andres's environment-variable mismatch (DM vs. channel agent contexts) status unknown, still presumed open absent a resolution statement.
• Cluster availability & reliability. Outbidding protection, multi-provider fallback, rate-limiter/gateway — not discussed in call 4 (Ryan absent); still open.
• Swarm SDLC / experience. Meaningfully advanced by Sage's delivered exercise this call, though Ryan's parallel A/B test remains unconfirmed as run.
• Action item, not started: build an explicit /swarm tool (Justin H.) — explicitly put on hold per Tooling call 3 (2026-07-22), pending more shared swarm experience before standardizing.
• Justin's own carried-over action item. Packaging his personal swarm workflows into shareable tooling — not directly discussed in call 4; still personal-monorepo-only, still gated behind his unmerged Jiu Jitsu integration.
• New from call 4: feeding AWS Amplify deployment-error learnings back into the Copilot-facing skill set (Sage, proposed, not yet started); a possible new client lead surfaced through an external AI event contact (Sage, unconfirmed, informational only); the Tooling/Orchestration call-content overlap Justin flagged at the top of this call, which may warrant a scope-boundary re-check between the two guilds.

What call 5 surfaced (2026-07-30)

• Ryan's Cursor-inspired agent-swarm experiment (walkthrough). Ryan screen-shared a personal experiment modeled on Cursor's published agent-swarm approach: a planner/worker split that ran continuously for ~6 hours consuming ~25M tokens. The planner made sparse, high-level requests (long idle gaps of 10–20 minutes between planner calls); workers ran continuously, with clear autocorrelation between planner bursts and subsequent worker activity bursts — exactly the pattern you'd expect from a plan-then-execute loop. Built on Fireworks AI as the inference provider throughout.
• Concrete infra lessons. (1) You don't need a powerful instance for this — a modest setup sufficed. (2) Fireworks AI held up well as a provider; no motivating case yet for self-hosted GPUs given current volume and pricing (~$10/hour running cost means you'd need 10x the volume to justify renting a GPU, and you can't host all three agent types on a single GPU cluster anyway). (3) Provider economics keep shifting as models update and new ones release, making the self-hosting math a moving target.
• Sage connected swarms and software factories as two angles of the same system. Her software-factory research from the prior weekend paralleled Ryan's swarm work: an independent swarm accomplishes an objective, or a software-factory setup enhances a swarm by sending multiple agents through a structured process. Ryan agreed — "it's the same thing" from different angles. His experiment is a software-factory swarm that's extremely specific to the SQLite-documentation problem; general-purpose swarms would look different.
• Justin connected the source article's shared-memory-file pattern to Hermes. The Cursor approach gives agents a shared memory.md file as a "field guide" — which Justin noted is a rough MVP of what Hermes already does better via its session/skill system. Running this kind of experiment through Hermes would not only produce working swarms but also let the planner/worker agents recursively build skills on how to swarm effectively — a form of recursive self-improvement. Flagged as fascinating, not yet scoped into a formal action item (see action item above).
• No new formal action items opened. The call was dominated by Ryan's walkthrough; business outcome, permission, and OKRs/KPIs remain undecided after five calls.

Knowledge gap

Advanced materially: Ryan's experiment gave the guild its first detailed look at a real swarm's runtime behavior (planner/worker token patterns, cost, provider performance) — complementing Sage's call-4 case study on composability lessons. The recursive-skill-building idea adds a new conceptual frontier, not yet scoped.

Business outcome

Still not settled after five calls. Not discussed in call 5.

Permission

Not discussed in call 5 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Not raised again in call 5.

What call 6 surfaced (2026-08-06)

• Retrospective on guild value. The call opened with a look back at whether the guild meetings are producing value. Eugene finds the calls useful for aligning on company vision — the cross-guild discussion surfaces things that wouldn't come up in client work alone. Sage finds them valuable for forcing prioritization: the cadence creates a deadline that makes her decide what actually matters.
• Cognitive load as a shared resource (Sage). Sage framed a new mental model: everyone has ~80% of their time consumed by client work, leaving ~20% for guild/internal work. The guild's job is to make sure that 20% is spent on the highest-leverage things, not scattered across long-tail ideas. This connects to Justin's call-5 request for P0 flags on action items — prioritization is now an explicit guild concern, not just a Tooling one.
• No new action items opened. The call was primarily retrospective and framing-oriented. Call 5's ideas (Ryan's Cursor swarm walkthrough, the recursive-skill-building concept) were not revisited. Justin's note: "digest and talk more on standup/next guild call."

Knowledge gap

Resting on call 5's detailed swarm runtime data plus Sage's call-4 case study. Call 6 added no new technical knowledge but validated the guild as a forum for prioritization.

Business outcome

Still not settled after six calls. Not discussed in call 6.

Permission

Not discussed in call 6 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Not raised again in call 6.

What call 7 surfaced (2026-08-13)

• Sage's MoA PR-review setup in depth (walkthrough, building on Tooling call 6). Sage detailed the full MoA pipeline: reference models (Kimi K2, DeepSeek, Nemotron 3 Ultra, MiniMax M3) each receive the same prompt containing the PR diff, then a GLM 5.2 aggregator combines their outputs with its own perspective to produce the final review. The prompt itself isn't hand-written — Sage has her individual GLM 5.2 agent do context-gathering first (fetch the PR diff, research anything relevant the models would need), then pack all that into a Kanban ticket description. The Kanban ticket becomes the prompt to the MoA council. Key constraint: reference models can't use tools, so all context must be provided upfront. Andres probed whether this context-gathering step could be automated; Sage does it manually today.
• Open-source model literalism vs. Sonnet inference (Sage). Open-source models do exactly what you tell them — when Sage asked one to “create a new branch,” it branched off the current branch instead of off dev; when told to fix the mistake, it rebased off main instead of dev. Sonnet 5 would have inferred that dev is the source for new branches. Eugene's read: this is exactly why open-source models work well as delegated workers (the orchestrator gives explicit instructions), while models with stronger inference handle ad-hoc requests better.
• Sage's evolving role: “software factory mechanic.” Sage framed her work as moving toward systems engineering and control theory — designing the environment and constraints so that agent flows naturally resolve in the best way, rather than being in the loop herself. Andres and Sage agreed the profession is shifting from hands-on engineering toward management of automated systems.
• Beads board visibility gap (Andres, Eugene). Andres reported that the beads board has 13 items and most of the team doesn't know they exist. Eugene discovered beads task creation by accident when his agent auto-created an issue. Andres committed to working on standardizing beads for client use (how to use beads in client engagements) — building on his earlier webhook-for-automatic-PR-review work. This connects to Tooling's beads-Jira sync and the client-isolation architecture from Tooling call 6.
• Model updates: Eugene using Luna 5.6 (GPT 5.6). Eugene reported good results using Luna 5.6 as a cheaper daily-driver model. Sage expressed interest in adding it to her MoA model collection. Fireworks outages noted as recurring (Sage hit them on Qwen 3 and GLM 5.2 as well).
• Sage's consulting skill book still in progress. Delayed by multiple fires within Travia this week. Connects to the Consulting guild's P0-flagged client-playbook action item.
• Short call, Justin absent (family emergency). Justin messaged Eugene and Ryan about a death in the family, taking Thursday and Friday off. The call was small (Sage, Andres, Eugene) and primarily a knowledge-sharing discussion with no new formal action items opened.

Knowledge gap

Advanced on the MoA front: Sage's full pipeline (context-gathering agent → Kanban ticket as prompt → MoA council → aggregator) is now well-documented. The beads-board-visibility gap (Andres) is a new knowledge/access problem for the team. Eugene's Luna 5.6 experience adds another model data point.

Business outcome

Still not settled after seven calls. Not discussed in call 7.

Permission

Not discussed in call 7 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Not raised again in call 7.

What call 8 surfaced (2026-08-20)

• Closing the loop on the multi-profile pipeline (Sage). Sage reported completing the first version of her Investigate profile and putting it through tests. The full pipeline now runs: Investigate profile (Qwen3, focused on research and plan-making) → Write Code profile (cheaper model, devoted to execution with a freed-up context window) → PR Review profile (reviews both prior agents' work) → Orchestrator retrospective (takes the PR result and feeds it back into overall execution improvement). The deliberate separation of planning from execution across different models creates useful adversarial tension — the code-writing model responds to the plan rather than being biased by its own planning, and the PR reviewer sees both stages' work with fresh eyes. Session histories are also more focused: the Investigate profile's history is analysis-only, much shorter than a combined agent's would be. She applied it to adding Supabase testing to CI with good results.
• DORA metrics as the next quality measure (Sage). Sage wants to bake in DORA metrics (throughput and instability) as a team-level gauge of quality and throughput, viewing the whole agent grouping as a team for measurement purposes. Andres connected this to his own research thread on industry standards for harnesses and software engineering factors — the lack of output grading was one of the quick-win blind spots he identified, and Sage's retrospective loop is essentially a grading of the work done. This aligns with the standing DORA/Goodhart's-law caution from the outcomes template.
• Team Topologies framing and cognitive load (Sage). Sage connected the team's work to Team Topologies concepts: they're simultaneously doing platform team work, complicated subsystem team work, enabling team work, and streamlined team work — "doing everything." She noted cognitive load (which she originally learned through Team Topologies) maps directly to agent context windows, and that running teams of agents and swarms is "interestingly close to managerial science" (creating teams, interactions, flow of change). She also referenced Team Topologies' report on organizational AI ROI as worth checking out, and the team API concept for structuring inter-team communication intentionally.
• Andres's harness/industry-standards research (Andres). Andres started a research thread on industry standards for harnesses and software engineering factors, identifying output grading as one of the big quick-win blind spots — the team has no systematic grading of agent outputs. He recognized Sage's retrospective loop as a partial implementation of exactly the grading mechanism he was looking for.
• Friday deployment race condition discovered (Eugene). Eugene discovered that Friday IC (front-end) and Friday backend have a deployment dependency: backend must fully deploy first because front-end packages reference backend infra setup (an AWS/Amplify idiosyncrasy). Pushing both simultaneously caused Justin's monitoring cron jobs (the Friday promotion watch) to go haywire. This is a deployment-order constraint, not a code bug — get backend through all the way, then IC. Eugene suggested documenting this in a deployment doc; Andres agreed it would be a good idea.
• Burning-items stocktake (group). The group enumerated their burning items: (1) figuring out more about swarms, (2) closing the loop on a software flywheel in general (Sage's work), (3) packaging up the client-facing capability in a consumable way for rapid deployment to any client (Justin's Friday support agent work), and (4) Sage's multi-client architecture concept (separating IP and engineering concerns per client, with PII implications). Sage wants a way to duplicate her setup across multiple clients without mixing five different technologies together.
• Agent-to-agent communication: consolidate on Hermes vs. add tools (Sage, Andres, Eugene). Sage's position: get rid of every other tool except Hermes — everything she's wanted to do is doable through Hermes, and adding tools built for different opinionated frameworks is cognitive load. Andres's counterpoint: the one thing not yet doable is person-to-person agent communication (your Hermes agent talking to another engineer's Hermes agent). Eugene revealed he built a peer query tool for exactly this — an inter-agent gateway allowing agents to message each other across machines without a desktop in the loop. Andres committed to taking a look at the peer query tool, having been looking into beads from the same angle. The group also discovered that Hermes's newly-published bots feature (a bot is a profile, and bots on one machine can message bots on another machine's gateway, with group chat / "council mode") directly addresses this gap — Sage called it "sick."
• Eugene's Friday/ProService support work. Eugene is running Justin's Friday support dev container, cleaning up code changes and making fixes. He was initially confused by the three-repo, three-deployment Friday architecture but Ryan fixed a prompt change in 10 minutes ("he speaks Friday"). Eugene noted the hive-mind agent setup means he doesn't need Justin physically — "I just need his agent's insight," since all Hermes agents update what's going on with each client and the next agent picks up where the other left off.
• Intravia communication-skills challenge (Sage). Sage reported the greatest current problem in Intravia (her client) is getting people to use communication skills and be specific about what they want. She shared the Team Topologies "team API" concept with the client to structure inter-team communication. Her strategy: pester with questions, but ship within ~24 hours if no response comes, then let them react — "people in startups learn through pain." Andres added that people often don't know what they want, they know what they don't want, so "put it in front of their eyes and they'll have something to say."

Knowledge gap

Advanced materially: Sage's multi-profile pipeline is now a closed loop with real test results, and the DORA metrics concept adds a measurement dimension. Andres's industry-standards research and the agent-to-agent communication discussion (peer query, Hermes bots) open new knowledge fronts. The team's reps gap (named in call 3 as the core blocker) is partially addressed by Eugene's hands-on Friday work and Sage's pipeline iterations.

Business outcome

Still not settled after eight calls. Not discussed in call 8.

Permission

Not discussed in call 8 either — still open.

OKRs / KPIs, timeline, go/no-go

Not defined. Sage's DORA metrics idea is the first concrete measurement proposal to surface in this guild, but it's not yet formally scoped as a KPI target.

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.

What call 2 surfaced (2026-07-21)

• Cadence/urgency gut-check raised again, still not resolved. Justin opened the call by flagging it should probably be revisited "maybe at the end of the call" — but the call ended abruptly when Ryan and Eugene had to drop for another commitment, and the cadence question was never explicitly revisited before or after that. Carried forward again below.
• Demo standards — explicitly deprioritized, not resolved by design. Ryan: not a high-priority item right now. Andres agreed on timing, but distinguished that from importance — he sees a client-interaction framework as valuable long-term, just secondary to the soft-skill/relationship work the guild should focus on at this stage. Left unassigned rather than closed.
• Client-playbook skill reassigned and reframed as "client profile." Justin handed the item to Sage, who reframed it around her broader "profiles as capabilities, not roles" philosophy: a from-scratch Rosenblatt consulting profile for Hermes (not one of the existing role-based profiles) that captures onboarding playbooks and, longer-term, a per-client health-check/dashboard view. Sage explicitly merged in Ryan's client-health-check idea from call 1 as part of the same concept.
• Multi-client scaling as the animating worry behind the client-profile idea (Sage, extended by Justin). Sage stress-tested the idea against a hypothetical five-client load: tracking who's been demoed to, who needs proactive attention, and communication timing across clients becomes a systems-design problem, not just a memory problem. She sketched a dashboard giving a happy/neutral/unhappy signal per client, derived from the same playbook heuristics (e.g. "haven't demoed in 7+ days"). Justin connected this to his own lived experience managing two concurrent smaller engagements, where informal life-cycle tracking already felt fragile and wouldn't scale past a handful of clients without a dedicated helper.
• Ryan's task-board-mining idea (new, not an owned action item yet). Proposed mining Recall transcripts across all conversations (not just guild calls) for stated commitments ("I need to do this by this time") to build an implicit, trust-based task board — enabling triage on delegation/ideation ratios per person (e.g. someone who ideates heavily but under-executes, or executes everything but never self-proposes). Notably, this is close kin to the guild-call action-items pipeline that's already shipped (see Main tab) — Ryan's version extends the same mechanism beyond guild calls to any Recall-transcribed conversation, with added per-person analytics that don't exist yet.
• Long freeform discussion on profiles vs. skills vs. memory isolation (mostly Justin and Sage, after Ryan and Eugene dropped). Prompted by Eugene's live question of whether a separate consulting profile is even necessary if the same people do engineering, sales, and consulting simultaneously. Ryan's position (before dropping): profiles should mostly just mirror the person (cybernetics framing) rather than proliferate by task type — the one legitimate use he sees is client-facing presentation stripping (the little_owen pattern). Sage's counter-framing from her own swarm experience: she keeps narrow, single-concern profiles (e.g. "Build with Copilot") because it forces the swarm orchestrator to make an explicit decision about which capability set fits a given ticket, then rolls everything back into her own default profile for cybernetics use. Justin connected this to session-history and memory isolation risk across multiple clients (IP leakage, cross-client contamination) as the deeper reason a shared "everything profile" gets risky at scale — not yet a concrete action item, but a real design constraint Sage flagged she'll carry into the client-profile work.
• No new concrete commitments beyond the client-playbook-skill reassignment. The profiles/memory discussion was explicitly framed by both Justin and Sage as still-forming thinking (Sage: "I might slap together a lovable demo... just to vomit out the concept") rather than a decision point.

What call 3 surfaced (2026-07-27)

• Client-profile/playbook concept — extended thinking, still no skill built. Sage hadn't yet created the official playbook skill but developed the concept further: playbooks as a codification of "how you do this part of our business model," with an explicit goal of helping first-time-startup clients absorb communication they might otherwise struggle with. Framed the client-data side as an ontology-building problem (bottom-up, built from entity/relationship extraction) versus the Rosenblatt-side rules/guardrails layer (e.g. what not to share with which client) as a separate concern. Floated a per-client dashboard idea with a status light per tracked item, inspired by the team's "30-day to production" promotional framing (cited her own Intravia AI-document-ingest delivery as the origin of that target).
• Ryan's cron-to-Dagster pipeline evolution (new context, not a guild action item). Ryan detailed moving his personal dashboard/metrics pipeline from a simple cron job to Dagster after outgrowing sequential agent calls (a 15-minute job dropped to ~30 seconds once parallelized). Framed as a durability/resilience upgrade over ad hoc script retries, with asset lineage visualization as a side benefit. Suggested this pattern could generalize to shared client-metrics pipelines (Daxter assets others can branch from) but didn't propose it as a formal action item.
• Cross-client agent knowledge-sharing floated, with explicit IP/proprietary-information risk flagged (new). Ryan raised (using a slime-mold analogy) whether agents should be able to transfer knowledge to each other automatically, similar to how hive-dream already works across agents. Sage's direct pushback: even if client data lives behind authentication (reducing literal IP-boundary crossing), there's still a "non-zero, managed risk" of cross-contamination. Justin drew a parallel to human-side precedent (Deloitte/BCG-style conflict-of-interest walls between client teams) as the existing analogy for how much isolation this needs. Landed as an open question, not resolved either way, with the group agreeing to "cross that bridge" reactively rather than design for it now.
• Guild cadence/urgency gut-check — not raised this call, unlike calls 1 and 2. No one flagged the standing "is this guild's cadence justified" question in call 3; still formally unresolved from earlier calls, just not revisited.

Knowledge gap

Progressing in depth but not in delivery: Sage's client-profile concept gained an ontology-building framing and a dashboard sketch in call 3, but the skill itself remains unbuilt across three calls now.

Business outcome

Not discussed in call 3. Pricing-model tension and revenue-concentration risk remain exactly where call 1 left them.

Permission

Not discussed in call 3 either — carried a third time.

OKRs / KPIs, timeline, go/no-go

Not discussed. The cadence/urgency prerequisite question wasn't even raised in call 3, let alone resolved.

Carried to next Monday

• Cadence/urgency gut-check — unresolved across three calls, but not raised at all in call 3. Ryan's original caution (this isn't a confirmed burning issue relative to Orchestration/Tooling) has gone from actively flagged twice to simply dormant; still needs an explicit resolution.
• "Rosenblatt Consulting handbook" candidate idea (Sage's original proposal, from before call 1) — not raised by that name in call 3 either; still converging informally with the client-profile framing.
• Demo standards/scaffold — not revisited in call 3; remains deprioritized from call 2, left unassigned rather than closed.
• Client-facing swarm framing (punted from Orchestration's call 1) — not picked up in call 3 either.
• Pricing model direction — not revisited in call 3. No decision across three calls.
• Whether sales/pipeline discussions belong in this guild's cadence — not revisited in call 3. Not settled.
• Guild artifact — still the client-profile concept as the frontrunner, not yet delivered across three calls. No change in call 3.
• Ryan's Recall-transcript task-board-mining idea (from call 2) — not raised again in call 3; still unowned, unscoped.
• New from call 3, unowned: cross-client agent knowledge-sharing, explicitly weighed against IP/proprietary-information risk — floated by Ryan, pushed back on by Sage, no resolution, deliberately deferred ("cross that bridge when we get there").

What call 4 surfaced (2026-08-10)

• Beads CLI live demo (Justin). Justin demoed the beads task-tracking CLI in action: agents.md injection (beads automatically injects its workflow documentation into each agent's context), a shared beads server that all Hermes agents connect to, and Jira+beads dual tracking (beads complements rather than replaces Jira). This is the same system the guild-ingest cron job now uses for action-item sync — a concrete tooling win that's already shipping value.
• Consulting skills/playbook flagged as P0 (Sage). Sage stated directly that consulting skills and the client playbook are a real pain point, not a theoretical exercise — this is a P0 priority. The client-profile/playbook concept from calls 1–3 has been discussed but never built across three calls; Sage's explicit P0 flag aligns with Justin's call-5 Tooling request for P0 prioritization on standing items.
• Rosenblatt playbook + per-client playbooks (Justin). Justin distinguished two layers: a Rosenblatt-level consulting playbook (the firm's general approach) and per-client playbooks (client-specific onboarding and relationship guidance). Both are needed; the Rosenblatt playbook is the foundation, per-client playbooks extend from it. This refines Sage's "client profile" concept from call 2 with a clearer two-tier structure.
• Sales/pipeline strategy belongs in consulting skills (Eugene). Eugene suggested that sales and pipeline strategy discussions — the open question from call 1 about whether these belong in the guild's cadence — should live inside the consulting skill set rather than as a separate agenda item. This partially resolves the call-1 open question: sales strategy doesn't need its own guild time slot, but it should be captured as a consulting competency.
• Ryan's brief appearance: transcripts as the "API of internal knowledge." Ryan joined briefly and framed call transcripts as the program's internal knowledge API — the raw material that everything else builds on. Graph RAG over transcripts is a later quality optimization, not a current priority. This connects to his call-2 idea about mining Recall transcripts into a task board, but reframes it at a higher level: the transcripts are infrastructure, analytics/RAG is a layer on top.

Knowledge gap

The consulting playbook skill is now explicitly P0-flagged by Sage, with a clearer two-tier structure (Rosenblatt playbook + per-client extensions). Still not built across four calls — the P0 flag adds urgency but not delivery.

Business outcome

Partially advanced: Eugene's suggestion to fold sales/pipeline strategy into consulting skills gives the guild a clearer scope boundary. Pricing-model tension remains where call 1 left it.

Permission

Not discussed in call 4 — carried a fourth time.

OKRs / KPIs, timeline, go/no-go

Not discussed. The cadence/urgency question wasn't raised in call 4 either; it's now dormant across four calls.

What call 5 surfaced (2026-08-24)

• Service packages vs. "engineering multitool" (Sage, key proposal). Sage proposed productizing Rosenblatt's capabilities into predefined service packages (audit package, one-off project package, etc.) instead of the current model where the team jumps on whatever random thing comes up. The framing: if they're good at a thing, they can package it and resell it — including Justin's ticketing agent as a productizable capability. This would reduce stress on the team and make client engagements more predictable. Intravia was cited as an incredibly inefficient client because of the amount of random things they request — the mobile-app setup was called out as backwards (responding to demand reactively rather than deploying a pre-built package). The mobile example: if they want to support mobile, they should have a shelf-ready package that sets a client up with mobile in the Rosenblatt way, with no surprises, rather than ad-hoc work each time.
• Client education as retention crux (Andres). Andres raised that the more they work with Intravia and the more frustrated he gets, the more he thinks client education is critical — for both client retention and employee retention. The argument: the business side (client retention via results) is already strong; the gap is making the working relationship sustainable so employees don't burn out. Sage agreed and noted her current MBA class is leadership, with organizational leadership starting soon — directly relevant. Both wished Ryan was in the call to revisit the client-education topic.
• Consulting skill book — Sage to take a week off from Intravia (Sage, intent stated). Sage asked Ryan about taking a week off from Intravia to work on internal engine stuff: the consulting skill book and related packages, structured as Hermes skill directories that are both human- and AI-readable. This is the most concrete step toward building the P0-flagged client-profile/playbook skill across five calls. Not yet confirmed (Ryan absent), but stated intent.
• Hermes update process as a barrier to team-wide experimentation (Andres, new concern). Andres flagged that updating Hermes is a skill known only to Justin H., Eugene, and Ryan at some point. This is a barrier to everyone independently experimenting with Hermes and pushing boundaries — a botched update can knock out everyone's agent for ~30 minutes each, which is real time/money loss. The fear of doing something incorrectly on the Hermes side suppresses experimentation. Sage agreed they should use the direct/upstream Hermes without custom additions for now, since there's no capacity to maintain custom stuff. New action item opened (see above).
• Referral pipeline and client pre-vetting (Sage). Sage reported that a VC she connected Ryan to is already recommending Rosenblatt to one of his founders — a referral partnership that brings in more steady work than LinkedIn marketing. She also described her client-filtering approach: pull clients from the right environment (startup accelerators, pre-vetted), since Intravia came through a recommendation without that pre-vetting and their investors/leadership are similarly un-vetted.
• Intravia leadership dynamics (Sage, context). Sage shared that Casey (Intravia founder) values loyalty over everything — both Logan and Zach were longtime friends hired through loyalty rather than vetting. Logan interviewed the prior engineer Ryan and lacked the experience to vet properly. Casey is still optimizing for cheap and local (Minneapolis), which Sage sees as a mistake for early-stage startup hires (first engineers need to be expensive). Andres and Sage agreed that "bad people hire bad people" — the seed group of employees must be especially strong.
• Sage should use Hermes directly without custom additions (Sage, Andres agreed). For now, the group agreed they should use Hermes directly (the upstream/canonical version) without adding their own custom additions, since there's no capacity to maintain custom modifications. They might be able to buy that capacity over time.

Knowledge gap

Advanced conceptually: the service-package model gives the client-profile/playbook skill a concrete shape (audit, one-off project, etc. as deployable packages in Hermes). Sage's stated intent to take a week off to build it is the first concrete delivery timeline across five calls. Still not built.

Business outcome

Advanced materially: the service-package proposal directly addresses the "what is the business outcome of this guild" question — productized packages are a revenue model, not just a knowledge artifact. Client-education-as-retention extends the business-outcome frame beyond pricing mechanics. Intravia's inefficiency as a random-work client is concrete evidence for the packages thesis.

Permission

Partially advanced: Sage's stated intent to take a week off from Intravia to build internal engine stuff is a concrete permission ask (not yet confirmed by Ryan, who was absent). The broader permission question (is guild work time sanctioned?) is still open, but Sage is actively seeking it.

OKRs / KPIs, timeline, go/no-go

Not formally defined. The "one week off from Intravia" is the first concrete timeline anchor, but it's an individual ask, not a guild-level KPI. The cadence/urgency question remains dormant across five calls.

What call 6 surfaced (2026-08-31)

• Steve Yegg's "Shape of Things to Come" — crew agents vs fleet agents (Justin, key presentation). Justin walked Andres through Steve Yegg's article about his high-throughput solo development setup (~12,000 commits/day on an MMO game). Yegg uses beads as central orchestration with a custom layer (Wheelhouse; Gasity is the open-source equivalent). The key architectural distinction: crew agents (Hermes agents — persistent conversational agents in Slack/Discord) whose purpose is converting conversations into work-graph items (decomposing, prioritizing, shaping tasks), versus fleet agents (Gasity) that pick up typed edge nodes and do the actual work. Edge nodes are color-coded: orange = human-ready/blocking (human decision required), yellow = agent-ready (can be auto-assigned). The interface point between the two subsystems is the work graph itself.
• Task typing as the missing piece (Justin). By default, beads creates generic tasks. The insight from building the visualizer: tasks need to be shaped into types (decision, spec, design brief, etc.), each with type-specific acceptance criteria. A crew agent can be tasked with taking unshaped tasks and typing them. Once typed, Gasity can watch the beads graph and automatically sling tasks to the right role based on type (e.g. any unblocked spec goes to the spec agent).
• Beads/Gasity vs Hermes Kanban (Andres's question, Justin's answer). Andres asked how beads + Gasity differs from using Hermes bots and Kanban. Justin's answer: technically you can accomplish the same thing with Hermes Kanban (Ryan and Eugene's swarm orchestration used it), but Hermes was built primarily as a conversational assistant/cybernetic layer — automatic task and graph management is less developed. Beads is a better work-graph representation (more intuitive for custom structures, gating/blocking, connecting tasks). Key benefit: a shared beads service (already running on the Rosenblatt VM with all Hermes containers connected) versus the complexity of syncing Hermes Kanban state across separate containers. Justin noted his earlier "five Kanban" attempt was essentially recreating beads.
• Proposed shared Gasity service (Justin, concrete proposal). Justin proposed standing up a shared Gasity container connected to the existing Rosenblatt beads server, with Rosenblatt-specific roles (like Hermes profiles, each with their own skills, system prompt, and tools). Workflow: create a task in beads, shape it into a type, label it "delegate to Gasity," and Gasity immediately picks it up. Flexibility preserved — you can still do everything in Hermes without Gasity, but Gasity offers shared task orchestration with consistent roles for everyone. Estimated setup: ~couple hours for the service.
• Work-graph visualizer prototype (Justin, demoed). Justin built a work-graph visualizer over the weekend (Friday night through Sunday evening). Milestone-driven: everything flows down into a milestone so you can see progress toward goals. Built with Svelte flow libraries. Andres suggested doing internal software-requirements gathering before committing to a specific view. Justin floated making it a Hermes plugin (a "Rosenbot dashboard") so everyone can see the data in their own Hermes dashboard. Estimated build: 1–2 weeks.
• Content-review pipeline as a use case (Justin, example). Justin gave a concrete example: a shared Gasity role for content review (public website, LinkedIn posts) with Rosenblatt's standard design language and wording. Anyone could ask their Hermes agent to run content through the review pipeline, which creates a beads task, delegates to Gasity's review role, and returns a PR — consistent results for everyone.
• No consulting-playbook or service-package progress this call. Sage and Ryan were absent; the call focused entirely on the beads/Gasity tooling architecture. The P0-flagged client-profile/playbook skill remains unbuilt across six calls. None of the standing consulting action items (service packages, Hermes update process, cadence gut-check) were revisited.

Knowledge gap

Advanced on the tooling side (crew/fleet architecture, task typing, Gasity integration path) but not on the consulting-playbook side. The client-profile/playbook skill remains unbuilt across six calls despite the P0 flag; this call didn't touch it.

Business outcome

Not discussed in call 6. Service-package model, pricing tension, and client-education-as-retention remain where call 5 left them.

Permission

Not discussed in call 6 — carried a sixth time. Sage's stated intent to take a week off from Intravia (pending Ryan's confirmation) still unconfirmed.

OKRs / KPIs, timeline, go/no-go

Not formally defined. The Gasity-service and visualizer dashboard have concrete time estimates (~hours and ~1–2 weeks respectively), but these are tooling items, not guild-level KPIs. The cadence/urgency question remains dormant across six calls.

Carried to next Monday

• Cadence/urgency gut-check — unresolved across six calls, dormant since call 3. Not raised in call 6; still needs an explicit resolution.
• "Rosenblatt Consulting handbook" candidate idea (Sage's original proposal) — converging with the service-package model from call 5 and the client-profile framing. Sage stated intent to take a week off to build it; not revisited in call 6 (Sage absent).
• Demo standards/scaffold — not revisited in call 6; remains deprioritized from call 2, left unassigned.
• Client-facing swarm framing (punted from Orchestration's call 1) — not picked up in call 6.
• Pricing model direction — not revisited in call 6. No decision across six calls.
• Whether sales/pipeline discussions belong in this guild's cadence — not revisited in call 6. Not settled.
• Guild artifact — the service-package model is the strongest candidate yet. If Sage builds the consulting skill book as a set of Hermes skill directories (audit, one-off project, etc.), that's a concrete, build-on-able artifact. Still not delivered across six calls. The Gasity/visualizer work from call 6 is tooling infrastructure, not a consulting-guild artifact.
• Ryan's Recall-transcript task-board-mining idea (from call 2) — not raised in call 6; still unowned, unscoped.
• Cross-client agent knowledge-sharing, with IP risk explicitly flagged (from call 3) — not raised in call 6; still unowned, deferred.
• From call 5 (still standing): build predefined service packages (Sage, open); formalize the Hermes update process so it's not a single-person bottleneck (unowned, open); Sage's referral-pipeline update (VC recommending Rosenblatt to a founder); Sage's stated intent to take a week off from Intravia to build the consulting skill book (pending Ryan's confirmation).
• New from call 6: stand up a shared Gasity fleet-agent service connected to the Rosenblatt beads server with shared roles (~couple hours, Justin); build a work-graph visualizer dashboard, potentially as a Hermes plugin (~1–2 weeks, Justin); internal software-requirements gathering for the dashboard view before committing to a specific design (Andres suggested).