Skip to main content
LatticeAG

Poly Series

PolyBrain

Hermes Skill

Hermes Agent skill for multi-model orchestration - parallel subagents, citation enforcement, source verification.

Quick start

Start with the primary command, then continue with the full workflow below.

git clone --depth=1 https://github.com/mosesman831/PolyBrain.git /tmp/polybrain

Problem

Single-agent LLM runs are serial, single-model, and unverified: a lone model researches, writes, and asserts in one pass, so an early wrong turn or hallucination propagates straight into the final answer. Long research briefs require re-reading sources, cross-checking claims, and fixing citation drift by hand. Most multi-agent frameworks look parallel but bind every subagent to the same model config, so a model's blind spots repeat across the whole team. Results arrive without evidence - summary-style outputs that force the user to re-verify everything downstream.

Solution

PolyBrain turns a single objective into a coordinated multi-agent workflow: it decomposes the task, routes work to specialized roles, executes subtasks in parallel, synthesizes the outputs, and verifies every claim against cited sources. It is built as a local, config-driven, reproducible Hermes Agent skill - not a hosted service - so model routing, parallelism, and timeouts live in config.yaml and every run lands in a timestamped artifact folder. The key architectural choice is multi-model, not just multi-agent: each role (orchestrator, researcher, builder, synthesizer, verifier) can be bound to a different LLM and provider. A dedicated verifier checks each claim against its cited source and returns PASS/FAIL, and uncited claims are dropped rather than silently included.

How it works

01

Clone and install the skill into Hermes: git clone --depth=1 https://github.com/mosesman831/PolyBrain.git /tmp/polybrain, remove the .git folder, and copy the skill to ~/.hermes/skills/research/polybrain.

02

Configure per-role model aliases and providers in ~/.hermes/skills/research/polybrain/config.yaml - orchestrator, researcher, builder, synthesizer, verifier, and fallback can each use a different model (e.g. DeepSeek for research, Claude for synthesis).

03

Validate the config with python ~/.hermes/skills/research/polybrain/scripts/validate_config.py before the first run.

04

Use it in chat - tell Hermes what you want (e.g. "Use PolyBrain to research Apple's latest earnings and competitors") and Hermes loads the skill and runs the orchestration script; or run the script directly by piping the objective to python ~/.hermes/skills/research/polybrain/scripts/orchestrate.py.

05

The Orchestrator decomposes the objective into a JSON task plan (text-only, with robust JSON recovery when models add extra prose), then the Researcher (web + browser, must include URLs) and Builder (terminal + file) roles execute subtasks in parallel via ThreadPoolExecutor.

06

The Synthesizer merges all outputs into the final deliverable; the Verifier then checks each claim against its cited source and returns PASS/FAIL - uncited claims are dropped from the final output.

07

Every run is saved in a timestamped artifact folder (.hermes/plans/polybrain) for traceability, and transient failures are retried before a run is marked failed.

Technical architecture

Each handoff carries structured context through the product's execution path. Hover a node to inspect its role.

01

Objective Decomposition

Step 1: Objective Decomposition receives structured context from the prior stage and prepares it for the next handoff.

02

Role Routing

Step 2: Role Routing receives structured context from the prior stage and prepares it for the next handoff.

03

Parallel Research

Step 3: Parallel Research receives structured context from the prior stage and prepares it for the next handoff.

04

Parallel Build

Step 4: Parallel Build receives structured context from the prior stage and prepares it for the next handoff.

05

Synthesis

Step 5: Synthesis receives structured context from the prior stage and prepares it for the next handoff.

06

Claim Verification

Step 6: Claim Verification receives structured context from the prior stage and prepares it for the next handoff.

07

Final Answer

Step 7: Final Answer receives structured context from the prior stage and prepares it for the next handoff.

When to use

  • High-signal research briefs where claims must be backed by cited sources, not vibes.
  • Multi-topic questions that decompose into parallel sub-tasks (competitor analysis, market research, earnings deep-dives).
  • Work that benefits from different models on different roles - a cheap model for research, a premium model for synthesis.
  • Any task where you need claim-by-claim verification before the answer reaches you.
  • Reproducible research pipelines you want saved as timestamped artifacts for traceability.
  • Mixed research-and-build tasks (research plus code/terminal/file work on the same objective).

Not for

  • Tasks that can't produce citations (opinions, creative writing, purely private/internal knowledge).
  • Quick chat Q&A where a single fast model is cheaper and good enough.
  • When your chosen models hang - some providers (e.g. gpt-5-mini) can hang in hermes chat subagent calls (300s+); test with hermes chat -q "ping" -m your-model first.

Features

Multi-model role routing - different models/providers per role in config.yaml

Parallel by default - research and build tasks run concurrently via ThreadPoolExecutor

Citation enforcement - researchers must include URLs; uncited claims are dropped

Source verification - a dedicated verifier checks each claim and returns PASS/FAIL

Premium orchestration flow - clean task splitting, parallel execution, final synthesis

Robust JSON parsing - orchestrator output recovered even when models add extra prose

Retry logic - transient failures retried before a run is marked failed

Artifact logging - every run saved in a timestamped folder for traceability

Config-driven and reproducible - model aliases, providers, parallelism, timeouts in config.yaml

Local skill install - no hosted service; runs inside Hermes Agent with your own models and keys

Role-based tool restrictions - researcher gets web/browser, builder gets terminal/file

Debug runner - orchestrate_debug.py for sequential, verbose troubleshooting

Install and usage

usage.sh
# 1. Clone and install the skill
git clone --depth=1 https://github.com/mosesman831/PolyBrain.git /tmp/polybrain
rm -rf /tmp/polybrain/.git
cp -r /tmp/polybrain ~/.hermes/skills/research/polybrain
rm -rf /tmp/polybrain

# 2. Edit config.yaml with your model aliases
#    (orchestrator, researcher, builder, synthesizer, verifier, fallback)
hermes config edit  # then edit ~/.hermes/skills/research/polybrain/config.yaml

# 3. Validate config
python ~/.hermes/skills/research/polybrain/scripts/validate_config.py

# 4. Use it - just tell Hermes what you want in a chat:
"Use PolyBrain to research Apple's latest earnings and competitors"
# Hermes loads the skill and runs the orchestration script for you.

# Advanced/manual use - run the script directly:
echo "Summarize Apple's latest quarterly earnings with sources" |   python ~/.hermes/skills/research/polybrain/scripts/orchestrate.py

Architecture explorer

Problem

Single-agent LLM runs are serial, single-model, and unverified: a lone model researches, writes, and asserts in one pass, so an early wrong turn or hallucination propagates straight into the final answer. Long research briefs require re-reading sources, cross-checking claims, and fixing citation drift by hand. Most multi-agent frameworks look parallel but bind every subagent to the same model config, so a model's blind spots repeat across the whole team. Results arrive without evidence - summary-style outputs that force the user to re-verify everything downstream.

Solution

PolyBrain turns a single objective into a coordinated multi-agent workflow: it decomposes the task, routes work to specialized roles, executes subtasks in parallel, synthesizes the outputs, and verifies every claim against cited sources. It is built as a local, config-driven, reproducible Hermes Agent skill - not a hosted service - so model routing, parallelism, and timeouts live in config.yaml and every run lands in a timestamped artifact folder. The key architectural choice is multi-model, not just multi-agent: each role (orchestrator, researcher, builder, synthesizer, verifier) can be bound to a different LLM and provider. A dedicated verifier checks each claim against its cited source and returns PASS/FAIL, and uncited claims are dropped rather than silently included.