📝Hermes Agent, the open-source agent runtime from 📝Nous Research, ships four distinct mechanisms for running more than one agent — each at a different weight class. Knowing which primitive fits which problem is the difference between compounding leverage and an unauditable swarm.
Subagents (delegate_task)
The lightest primitive: 📝Subagents are ephemeral child instances a running agent spawns with fully isolated context — a child knows nothing the parent doesn't pass explicitly. Children inherit the parent's toolset and can never exceed it; delegation, memory writes, and code execution are blocked in children by default. Three run concurrently by default, a cheaper model can be pinned for all children, and spawn depth is flat unless deliberately raised. Only the child's final summary re-enters the parent's context. Built for parallel read-heavy work inside one logical task — research fan-out, independent review passes — not for anything that writes shared state.
Profiles
A profile is a full isolated Hermes instance: its own home directory, 📝SOUL.md identity, model and provider, session memory, skills, secrets, and gateway presence. Profiles carry human-authored descriptions that downstream orchestration reads for routing, and they can be exported and installed as distributions. This is the heavyweight primitive — every profile is another instance to authenticate, patch, and observe — so it earns its cost only at genuine boundaries: a different client, a different trust level, a memory that must not bleed.
Kanban
A durable SQLite task board shared across profiles. A dispatcher inside the gateway reclaims stale claims, promotes dependency-gated tasks, and spawns the assigned profile as a worker in an isolated workspace. It offers auto-decomposition of rough tasks into routed task graphs, a swarm topology (parallel workers, then a verifier, then a synthesizer over a shared blackboard), scheduled starts, per-task skill pinning and model overrides, goal-mode cards judged against acceptance criteria, and tenant namespacing. Single-host by design. This is the platform's answer to asynchronous peer handoff between long-lived specialists with humans in the loop.
Mixture of Agents (MoA)
Multiple model slots answer one prompt and a synthesizer merges them. A quality lever on a single response, not an orchestration primitive.
The Mechanism Ladder
Our doctrine for adopting these: for any new specialization, take the lowest rung that solves it — a skill bundle on an existing one-shot, then a model override, then subagent fan-out, then a profile, then kanban. Most "we need another agent" moments dissolve at rung one or two: the specialist you usually want is a skill-times-model pair, not a new identity. Three constraints hold at every rung: a single writer per data store, deterministic triggers (agents are spawned by cron, webhook, or human action — never by another model's judgment), and a flat hierarchy. Specialization rides on skills, toolsets, and models; distinct agent identities appear only at trust boundaries, because identity is about memory and permissions, not competence.