A Swarm & Hermes That Grows With You
An agent without a team is just a prompt with no context.
Written by: Rabin, VP of AI at Hype
where this started 36h ago.
i’ve been running growth experiments for 9 years. growth hacking, distribution, conversion optimization. the loop is always the same: hypothesis, test, measure, keep or kill, repeat.
the problem was never the ideas. it was the velocity. a human team runs maybe 2-5 experiments per week. most of your time goes to coordination, not execution. research doesn’t talk to analytics. the writer doesn’t know what worked last week. context lives in people’s heads and dies in slack threads.
i tried fixing this with AI agents. tried OpenClaw. tried standalone agents with tool use. tried the whole “AI employee” playbook.
it kept failing for the same reason.
an agent without a team is just a prompt with no context.
nobody hires a writer with no research team, no analytics, no strategy, no feedback loop. you don’t hire individuals. you build teams.
so that’s what i did.
what i built
a swarm framework where multiple agents operate as a team. each agent has its own role, tools, MCP access, specialized LLM model, and context window. they share knowledge, hand off work, and learn from each other’s results.
hermes sits on top as the operator. it can control the swarm, override actions, delegate tasks, and it learns from the agents underneath it. hermes + the swarm get smarter together.
the core idea: one folder = one team.
teams/rabin/
├── program.md # mission + constraints + voice rules
├── brand-kit.md # brand identity for writers
├── agents/
│ ├── research-analyst/
│ │ └── config.json # model, tools, metric, schedule, lenses
│ ├── growth-lead/
│ ├── linkedin-writer/
│ ├── twitter-writer/
│ ├── visual-designer/
│ ├── analytics-agent/
│ └── ...11 agents
└── results/
└── [agent-id]/
├── strategy.md # evolves over time
└── results.tsv # experiment logcreate a folder, write the configs, start the engine. that’s it.
why Hermes over OpenClaw?
let me be honest. on paper, these two look similar. both are persistent agents. both have SOUL.md. both have skills, cron, memory, multi-platform messaging, MCP. both self-hosted.
we all tried openclaw probably right? some love it , some hate it.
but here’s why i switched.
python vs node.
openclaw is node/JS. hermes is python. when you’re building ML/AI infrastructure -- multi-model routing, experiment loops, knowledge stores, async orchestration -- python is the native stack. every library i need (httpx, asyncio, apscheduler, numpy if needed) is a pip install away. building my engine on top of a node runtime would have meant fighting the ecosystem at every step. this alone was 60% of the decision.
execution sandboxing.
openclaw runs on a node process bound to localhost. hermes gives you five execution backends: local, docker, SSH, singularity, modal. container hardening with read-only root filesystems, dropped capabilities, namespace isolation. when you’re running 30+ agents with tool access that can write files, call APIs, and execute code on a VPS, this gap matters. hermes treats sandboxing as core infrastructure, not an afterthought.
sub-agent isolation.
hermes spawns isolated subagents with their own conversations, terminals, and python RPC scripts. zero context cost -- the parent doesn’t lose context when a child runs. openclaw has multi-agent routing, but it’s session-based isolation, not execution isolation. when my growth lead needs to delegate research to three writers in parallel, hermes handles that natively without polluting any context window.
memory architecture.
openclaw’s memory is file-based markdown (conversation logs + curated long-term). works fine for single-agent use. but it flushes working memory on restart by default -- there’s a known issue where people lose days of agent context to silent compaction. hermes has persistent memory + auto-generated skills that survive restarts. combined with my QMD knowledge store (BM25 + vector + LLM reranking), the total memory architecture is: hermes remembers how to operate + QMD remembers what the team has learned. two layers, both persistent.
SOUL.md : same concept, different execution.
both have SOUL.md. but hermes reloads it every single message. i update the swarm roster at 2am, hermes picks it up on the next interaction. no restart, no recompilation, no cache invalidation. openclaw needs a process restart for some config changes. when you’re iterating on a swarm of 11 agents, hot-reload isn’t a nice-to-have. it’s how you stay sane.
research and RL pipeline.
hermes has batch trajectory generation with parallel workers, checkpointing, and Atropos RL training integration. ShareGPT export for fine-tuning. this is NousResearch DNA . they build training infrastructure. if you want your operator to eventually get fine-tuned on your own task data, hermes has the pipeline. openclaw doesn’t.
the honest tradeoff.
openclaw has a better consumer UX. bigger ecosystem, it’s polished for personal assistant use cases, for now.
but i’m not building just a personal assistant. i’m building an engine that orchestrates infinite amount of specialized agents across 5 models with experiment loops and a shared knowledge store. for that, hermes’ python stack, execution isolation, and research pipeline are what matter.
hermes is the operator. the swarm is the team. you talk to hermes. hermes coordinates everything underneath.
the engine: how it actually works
two-phase daily cycle: for now.
phase 1 runs automatically every morning. research analyst scans, growth lead picks the angle and assigns work. then it stops and waits for you.
you approve over coffee via telegram.
phase 2 fires -- writers execute in parallel, visuals get generated, everything saves to the knowledge store.
you’re the bottleneck by design. until you trust it enough to flip `auto_approve=True`
┌────────────────┐
│ HERMES │
│ (operator) │
└───────┬────────┘
│
┌───────▼────────┐
│ ORCHESTRATOR │
└──┬──────────┬───┘
│ │
┌──────────────────▼──┐ ┌────▼───────────────────────┐
│ PHASE 1: PLAN │ │ PHASE 2: EXECUTE │
│ (sequential) │ │ (parallel, after approval) │
│ │ │ │
│ research → plan │ │ writers · designers · │
│ → approve/reject │ │ video · newsletter · │
└─────────────────────┘ │ repurpose │
└─────────────────────────────┘
┌─────────────────────────────────────────────┐
│ SHARED LAYER │
│ knowledge store · model router · │
│ experiment engine · task management │
└─────────────────────────────────────────────┘the karpathy pattern (QMD + program.md)
this is the part that matters most.
i took karpathy’s autoresearch loop -- the pattern he uses for automated ML research -- and applied it to growth.
every agent has three files:
- `program.md` -- immutable goal + single north star metric
- `strategy.md` -- the “editable thing” that evolves based on results
- `results.tsv` -- append-only experiment log
the loop: agent reads its current strategy. proposes an experiment. executes. results get measured. metric improved? keep the strategy change. didn’t improve? revert. log the failure. try something else.
python
# experiment.py
VERDICT_THRESHOLD = 0.20 # 20% improvement = meaningful
def evaluate_experiment(self, experiment, results):
if len(results) < experiment.sample_size_needed:
return "running"
avg_metric = sum(r.metric_value for r in results) / len(results)
improvement = (avg_metric - experiment.baseline) / experiment.baseline
if improvement > self.VERDICT_THRESHOLD:
return "keep"
elif improvement < -self.VERDICT_THRESHOLD:
return "discard"
else:
return "inconclusive"this is where QMD shines. every artifact -- research scans, content drafts, performance data, experiment verdicts, strategy decisions -- gets saved to a shared knowledge store. QMD indexes it with hybrid search (BM25 + vector + LLM reranking). runs locally.
when any agent runs, it doesn’t just see its own history. it sees what every other agent in the team has produced:
the swarm doesn’t get smarter because the models improve. it gets smarter because the strategies ratchet. day 1 is the worst it will ever be.
why this matters for growth specifically: after 9 years of running experiments manually, i know the bottleneck is never “we don’t have ideas.” it’s “we don’t learn fast enough from what we already tried.” this architecture makes every experiment’s outcome available to every agent, permanently.
multi-model routing
not every task needs claude. routing to the cheapest model that handles each task type is where costs drop from hundreds to single digits.
lower models doing 2-3x the output of larger models when you route them to the right task. mistral nemo at $0.02/M handles routing and structuring. qwen handles creative writing at $0.26/M. claude only gets called for decisions that cascade.
one full cycle across 11 agents: $0.009. but in reality i believe once fine tuned for quality , the numbers will jump a bit higher. but still cheap.
how it fits into a real workflow
this isn’t a toy. it plugs into how teams actually operate.
the swarm integrates with ClickUp (or Notion, or whatever PM tool you use). deliverables land there. if no tasks are assigned, agents are off doing their own work -- researching, experimenting, optimizing toward their north star metric that you have set for them. if something urgent comes in, you assign it through hermes (telegram, slack, CLI) and it delegates to the right agent in the swarm.
over time you build a social graph on your team. hermes + the swarm understand the agents better. understand what works. get smarter together.
what teams can you build?
the engine doesn’t care what the team does. it cares about: agents, tools, metrics, experiments.
- growth team (what’s running now)
- content swarm
- strategy swarm
- AI influencer team
- discord / community management swarm
- engineering team
- quant trading swarm
- whatever you envision
it all comes down to finetuning the swarms and training them through the experiment loop. write the configs, define the north star metric, let the autoresearch pattern do its job.
being honest about agents
let me say what nobody in the AI agent space wants to say.
if you’ve been building with AI agents... you know how they really are. not how content farmers describe them. not the “fully autonomous” fantasy. the reality.
agents are not doing 100% of complex work end to end. not today. i’d say if you expect 50-75% of the heavy lifting from a well-architected swarm, that’s realistic. over time, as models and tooling improve, maybe we push toward 100%. but right now, pretending otherwise is dishonest.
95% of people use AI. maybe 5% see tangible, compounding results from it.
the question i’m trying to answer: how do we move that number? how do we go from 5% seeing real results to 10%, 15%, 20%?
my bet: it’s not about better models. it’s about better architecture. coordination. shared context. experiment loops. teams that learn and dont give up.
everyone is solving for “make the individual agent smarter.” i think the leverage is in making agents work together and learn from each other.
what’s live and what’s not
this was a two-day sprint for the hackathon. i’m being upfront about what works and what doesn’t.
working end-to-end:
- orchestrator with two-phase cycle (research, plan, approve, execute)
- multi-model router (5 models via openrouter)
- research analyst (perplexity + DeFi data enrichment + structuring)
- growth lead (strategic planning via claude sonnet)
- linkedin writer + twitter writer (qwen 3.5 plus)
- knowledge store with 7 QMD collections
- 19 MCP tools wired to hermes (stdio + HTTP)
- approval flow via telegram / slack
- ClickUp integration for task management
needs more work:
- experiment ratcheting (infrastructure wired, needs 30+ cycles for real data)
- upgrade the individual agent skill , tools and models.
the architecture is real. the coordination works. the engine runs. i’ll spend more time polishing it and making it production-ready before sharing publicly.
it’s a big build.
the bigger picture
this journey started from wanting to build something for my team at work. then i realized the pattern is universal.
if your north star metric is X, the swarm keeps optimizing for it. learns from mistakes. cross-shares context and learnings. every cycle, every experiment, every failure makes the next run better.
the agent era isn’t about building better individual agents. it’s about building teams that coordinate, learn, and compound.
teams/growth/ ← live now
teams/trading/ ← next
teams/influencer/ ← planned
teams/your-team/ ← you tell mesame engine. different configs. a swarm that grows with you.
self-hosted. built on @NousResearch @Teknium hermes + QMD by @tobi @karpathy autoresearch pattern.
the engine is what matters. the MCPs are what matters. the experiment loop is what matters.
go build your own, if not then just wait until i make the repo public & open source.
gg
This article was first published on X. Enjoyed reading this? Follow Rabin on X for more pieces on building with AI.