Subagents vs Agent Teams? 🧠 Hermes Bots, Goal Loops & Kanban Graphs

Subtitle Summary (technological concepts, features, and analysis)

Core thesis: when to use subagents vs persistent agent teams

• The video argues that a single strong “orchestrator” agent with limited delegation to subagents is often sufficient.
• A permanent multi-agent team can improve quality/efficiency only when tasks are truly decomposable and can run in parallel.
• Permanent teams add coordination cost, delay, and evaluation overhead.
• Practical rule: don’t start with autonomous peer agents; instead, delegate limited, independent work to specialists when complexity demands it.

Cost / token efficiency results (single agent vs delegation)

• The video demonstrates a research workflow where delegated subagents reduce token usage significantly:
  • With delegation: ~45,000 → ~18,000 tokens
  • Another comparison: ~102,000 vs ~37,000 depending on the setup.
• Key nuance: token savings mainly happen because the parent/orchestrator receives compressed, synthesized outputs, rather than reading everything directly.
• Caution: total tokens may still be higher overall because subagents also consume tokens—even if the parent’s token usage drops sharply.

Delegation behavior details (important limitation)

• When delegating, subagents start with a fresh conversation:
  • They do not inherit the parent’s conversation history, tool calls, or prior context.
  • Their available context comes only from fields the parent provides (e.g., target/context in the delegation call).

---

“Goal loops” to improve quality without adding many agents

• Introduces a /goal command (Hermes feature) to define a persistent target state across iterations.
• Instead of creating many specialized agents up front:
  • Define what “done” means (success criteria + testing rules).
  • Have the agent loop up to ~20 steps, validating progress against the criteria.
• Criteria can be updated during execution (e.g., requiring peer-reviewed sources), and the agent continues refining using further delegations.
• Model strategy note:
  • The goal can specify using lower-intelligence subagents for cheaper research.
  • A higher-intelligence model then synthesizes results.

---

Hermes “bot mode” (specialists with persistent memory) before Kanban

• Bot mode uses profiles/bots that store:
  • skills, memory, and work context
  • can use different typical models per role (e.g., powerful model for orchestrator, cheaper for researcher).
• Coordination is described using a group chat style, forming a graph-like communication structure.
• Limitation mentioned: group chat exchange may only happen a few times (e.g., three) before stopping/checking.

---

Hermes Kanban: moving to true task graphs / control graphs

Why Kanban is different from delegation

• Delegated tasks: the parent is blocked until the child returns.
• Kanban:
  • The orchestrator can launch agents without waiting.
  • Work is managed as a queue/task graph with visibility into states and history.
• Strong recoverability + persistence:
  • Delegation failure can end the process as “incomplete.”
  • Kanban can support retries and resuming (e.g., lock/unlock/start again).
• Transparency + auditability:
  • Delegation may compress context, risking loss.
  • Kanban uses persistent storage (described as SQLite), enabling review of full history.

Kanban components and states

• Uses a card pipeline with sections such as:
  • Triage: turn a raw idea into a defined task/spec
  • Pending execution: waiting on dependencies or no executor available
  • Done / In progress / Blocked: may require human intervention
  • Verification: explicit auditing by a chosen reviewer agent
• Also supports:
  • Scheduling tasks
  • Dependencies between cards
  • Assigning cards to specific profiles (roles)

Autodecomposition + decomposer models

• Kanban can automatically decompose a rough card via submodels:
  • A “specifier” model converts ideas/goals into proper tasks.
  • A “Kanban decomposer” breaks tasks into subtasks assigned to performer profiles.
• Cost-control strategy emphasized:
  • Use maximum intelligence for decomposition/planning
  • Use lighter execution models for running clear cards
  • Goal: reduce token burn while preserving quality and structure.

Kanban test workflow shown

• A “test task” enters Kanban triage; a dispatcher runs a cycle (backend polling).
• Autodecomposition converts it into multiple cards.
• The board then demonstrates:
  • tasks moving through ready → running → done
  • root tasks waiting for child tasks
  • summaries/reports feeding back to the orchestrator.

---

Orchestrator strategy: when to replace autodecomposer

• Two decomposition approaches compared:
  1. Autodecomposer enabled: Kanban decomposer breaks tasks automatically.
  2. Disable autodecomposer: the orchestrator decomposes using Kanban skills/tools.
• Claims:
  • An orchestrator with a “soul” can maintain more persistent/role-specific context than the automatic decomposer.
  • Turning off autodecomposer gives more control over job design, roles, and review process.
• Continuity advantage:
  • Kanban enables returning later, inspecting blocked tasks, and resuming without restarting the conversation or re-spawning subagents.

---

Test results / conclusions from the video

• For the author’s “simple research” case:
  • Single agent with delegation ≈ similar token usage and quality to orchestrator without autodecomposer
  • Autodecomposer + goal loop increased overhead for this specific task
• However:
  • Kanban may still be worthwhile due to high transparency and persistent control, even if token cost is higher.
• Final recommendation:
  • Start with the simplest level: a single responsible lead + limited delegation/loop.
  • Add multi-agent teams/heavier orchestration only when required by complexity, independence, parallelism, and transparency requirements.

---

Main speakers / sources

• Speaker: Callum (“WanderLootz”)
• Source context: Hermes documentation and community best practices (bots, goal loops, delegation, Kanban), referenced within the video.