Jonathon's AI Wiki

Dmitry Shapiro's Multi-Agent Hermes Architecture — Watson, Sherlock & Harry

10 min read

Source: raw/Hermes_Masterclass_Run_multiple_coordinated_agents_simultaneously_July_2nd_2026.md (youtube.com/watch?v=XdT7xzB8tW4), Dmitry Shapiro (CEO, MindStudio), live masterclass webinar, 2026-07-02

A live-webinar walkthrough of Dmitry Shapiro’s actual production multi-agent Hermes setup — three named agents spanning two physical machines, coordinated through Linear webhooks, direct API calls, and a shared GBrain relationship layer. This is the concrete architecture follow-up to his earlier, more conceptual June 15 briefing; treat the two articles as a pair (concept, then implementation).

Key Takeaways

The three named agents

  • Watson — runs on an old MacBook Pro (M1), default model Sonnet 4.6, escalates to Opus for code. Acts as chief-of-staff / orchestrator: receives Linear webhooks, triages each incoming item, and decides whether to handle it directly or hand it to Sherlock. Also manages GBrain.
  • Sherlock — runs on a 2-year-old gaming PC (RTX 4080), same default/escalation model pattern as Watson. Receives work Watson routes to it and decides whether to do it itself or delegate further to Harry.
  • Harry — a sub-agent running on Sherlock’s same machine, using Ollama for free local inference (Qwen 2.5 7B at the time of the talk) and ComfyUI (also local/free, using the Z-Image Turbo open-weight model) for image and video generation. The explicit reasoning: image/video generation is the most expensive category of inference, so running it locally on owned hardware avoids per-generation provider costs entirely.

Communication surfaces

  • Telegram — mobile interface; one conversation thread per agent (separate threads for Watson and Sherlock).
  • Vivaldi (tabbed browser) — desktop interface; a 3-column layout with Watson, Sherlock, and a combined channel where the human can broadcast to all three agents at once (the agents cannot message each other in that combined view — broadcast only, not a group chat between agents).
  • Linear.app — the primary task-tracking surface. Linear supports webhooks; adding a new issue fires a webhook to Watson, who triages and can fire follow-on webhooks to Sherlock. Shapiro is explicit this is an arbitrary tool choice (“I use Linear for nothing else… you could use ClickUp, Notion, Trello, Asana, or have your agent build its own kanban board”) — the coordination shape is the point, not the specific tool.
  • SSH plus a terminal multiplexer, and Parsec for full remote-desktop access to the other physical machines when GUI-level or physical configuration is needed that an agent can’t do for itself.
  • Tailscale — a secure mesh network connecting all the machines so they can communicate directly (including over the public internet) without exposing anything publicly.
  • Google Drive — shared output storage; each agent has its own folder plus a shared outputs folder, so generated files (images, spreadsheets, documents, presentations) land somewhere the human and every agent can read/write.

Agent-to-agent coordination mechanics

Three distinct channels, used for different things:

  1. Linear webhooks — Linear → Watson (triage) → Sherlock (delegated work) → optionally Harry (local generation).
  2. Direct API/webhook calls over Tailscale — Watson and Sherlock also message each other directly (an “agent-ops system log”) to coordinate on their own, independent of a Linear card existing.
  3. Human broadcast — the 3-column browser view lets the human message all three simultaneously; the agents don’t see each other in this view, only the human’s message.

GBrain as the relationship/CRM layer

  • Ingests: 2 Gmail accounts, 2 calendars, Slack, Zoom + Fireflies call transcripts, LinkedIn connections and conversation activity, Twitter interactions.
  • Enrichment: when a new contact or meeting is ingested, a deep-research pass runs via the u.com search API (Shapiro calls browsing directly to Google “made for humans… dumb, slow” for an agent) plus Unipile for additional platform connections, pulling public information about that person/company to enrich their GBrain page.
  • “Dreaming” — a nightly (2am) process that refactors and enriches GBrain’s own stored data, matching the general GBrain dream-cycle documented in GBrain.
  • GBrain answers natural-language questions like “what people have changed roles this week” or “what’s the best route to reach this second-degree contact” because the relationship graph is already mapped.
  • Tiered relationship monitoring: roughly 200 people get scanned on weekdays for Twitter activity worth responding to; a smaller ~42-person “really care about” tier gets scanned for people who need direct help; a broader subject-matter scan (AI/agents/competitors) looks for high-value conversations with strangers worth joining.
  • “Bridge graph scan” — a named technique for reaching an otherwise-unreachable target: map who an important, unresponsive target does reply to on Twitter (typically smaller, lower-profile accounts), then build relationships with those bridge people first as an indirect path to the target. Described as built and tested but turned off at the time of the talk.

The Remy platform and the cron-job catalog

  • Remy — MindStudio’s own builder agent (compared to Claude Code / Cursor / Replit) that Watson/Sherlock can invoke to build new internal tools on demand. Example shown: “Salesbench,” an internal dashboard built by Remy to monitor Remy’s own usage/spend across a team.
  • ~24 scheduled cron jobs, grouped into five buckets (several intentionally paused at the time of recording to control cost/attention):
    • Data ingestion — GBrain sync (hourly, generates embeddings for new content), GBrain “dream” (nightly, 2am), Gmail sync (once/day, 7am — pulls new threads), LinkedIn sync (weekly — new connections, role changes), calendar/Zoom-transcript ingestion (3x/day, drafts follow-up emails when needed but never auto-sends them), sent-folder scan (once/day, 8am, tracks outbound messages the human sent without telling the agent), an investor-communications-specific job (used only while actively fundraising).
    • CRM / relationship management — the weekday network-scan job described above (surfacing “here’s something you could do for this person”).
    • Twitter engagement engine — the tiered scans (200-person / 42-person / broad-subject) plus the bridge-graph-scan technique, plus draft-reply generation.
    • Intelligence monitoring — a daily market/competitor research digest (via u.com across a defined website list) and a 4x/day Slack digest (reads the team’s Slack, surfaces what needs the human’s attention, otherwise stays silent).
    • System health & cost control — a release-tracking job that explains new Hermes features as they ship, a weekly inference-spend breakdown by job, a daily spend audit specifically looking for runaway loops/race conditions burning tokens, and a same-day alert if daily spend crosses a defined limit.
  • Design principle — “silence is a feature.” Automation should only interrupt the human when something genuinely needs attention; the majority of these jobs run continuously and are simply never surfaced unless they find something worth a nudge.

Two configuration dimensions (recap plus this session’s addition)

  • Digital-you vs. digital-assistant — whether the agent runs with the human’s own credentials (acting as them) or a separate identity; Shapiro runs production with his own credentials.
  • Indoctrination vs. acculturation — strict prescriptive guardrails vs. teaching norms/culture and allowing more agent judgment; Shapiro places himself in the middle of this spectrum. (Both dimensions also appear in the earlier June briefing; this session adds an “extreme acculturation” example — an exhaustive interview producing a full set of role-context markdown files for a fictionalized Meta L5 PM.)

Security posture

  • A nightly security-audit process looks for vulnerabilities and patches them; Shapiro’s framing for getting a harness to secure itself: “ask Hermes to secure Hermes” — it can write and run its own vulnerability-scanning scripts.
  • Recommendation for newcomers: install on a separate machine with separate credentials first; graduate to production credentials on a primary machine only after enough hands-on comfort. Shapiro himself now runs with full credentials on primary infrastructure (excluding banking access).

The 3-week bootcamp structure (context for where this fits)

Week 1 = Claude Code (build custom business applications); Week 2 = replicate this Hermes multi-agent setup; Week 3 = evals — writing the goal/exit-criteria definitions needed to run agent loops rather than prompting an agent turn-by-turn. Shapiro explicitly cites Boris Cherny (Claude Code) and Peter Steinberger (OpenClaw) as having moved past directly prompting a coding agent, toward writing loops that prompt the agent — the same thesis this wiki already documents in The Loop Is the Unit of Work and the wider agent-loops topic.

Cross-Device Memory Clarification

Asked directly how memory syncs across multiple physical machines, Shapiro’s answer is that it doesn’t sync automatically — there is no shared memory layer between separate agent installs. What’s needed is either a single shared source of truth the agents sync to, or one manager/orchestrator agent whose job includes proactively pushing updates to the others. (In Shapiro’s own setup, GBrain — a shared, centrally-synced git repo — is effectively that shared source of truth.)

How This Differs From Other Hermes Multi-Agent Patterns Already in the Wiki

  • Hermes Profiles & Multi-Instance documents the product feature for running isolated Hermes instances on one machine (separate config/memory/skills per profile). Shapiro’s setup is a practitioner architecture spanning multiple physical machines with named, role-differentiated agents (chief-of-staff, delegate-worker, local-inference sub-agent) coordinating via Linear/webhooks/Tailscale rather than the Profiles feature specifically.
  • Hermes Multi-Agent Workflow Template (tonbistudio) is a Kanban-board-as-message-bus triage-pipeline template — a different, more generic coordination substrate than Shapiro’s Linear-webhook plus direct-API plus human-broadcast three-channel setup.
  • The earlier June 15 briefing from the same creator covers the conceptual “what is a personal agent” framing, activity-dependent model selection, and a first mention of GBrain; this article is the concrete, later (July 2) follow-up describing his actual production multi-machine architecture in far more technical detail.

Try It

  • Before building a multi-machine setup, decide the coordination substrate first (Linear/webhooks, a shared Kanban board, direct API calls) — Shapiro is explicit that the specific tool (Linear vs. ClickUp vs. a custom-built board) doesn’t matter; the shape (a fixed bus + a triage agent + delegated workers) does.
  • If image/video generation is a meaningful chunk of spend, evaluate moving it to a local Ollama + ComfyUI stack on owned hardware rather than a paid API, following Harry’s role in this architecture.
  • Adopt “silence is a feature” explicitly: audit any always-on job you build for whether it interrupts you on every run or only when something’s actually worth surfacing.
  • If reaching an unresponsive but important contact, try the bridge-graph-scan technique: map who they actually reply to, and build those relationships first.
  • Before scaling to multiple physical machines, decide your cross-device memory strategy up front (shared source-of-truth repo, or a designated manager agent) — Shapiro’s Q&A makes clear this doesn’t happen automatically.

Open Questions

  • The exact mechanics of the Twitter monitoring/scraping (which the creator says has “legitimate ways” of doing it without triggering bot detection) aren’t detailed — he explicitly declines to cover Instagram/Facebook scraping and doesn’t specify the scraping method for Twitter/LinkedIn beyond naming Unipile as one connector.
  • Several of the 24 cron jobs are described as currently paused/turned off for cost or attention reasons — the full always-on cost profile of running all 24 simultaneously isn’t stated.
  • No pricing is given for u.com, Unipile, or the MindStudio SDK beyond a “free piece of software” framing for the SDK itself (usage against the 200+ models / 1,000+ connectors it exposes presumably still costs at the provider level).
  • Whether “Remy” (MindStudio’s builder agent) is generally available or MindStudio-customer-only isn’t stated in the transcript.

Graph View

Backlinks