NousResearch's hermes-agent hit 31,000 GitHub stars in six weeks. 329,000 lines of Python. 122 skills. 49 tools. 14 messaging platform adapters. 15 LLM providers.
I assumed it was a competitor. I spent two days running five parallel analysis missions against it — architecture, features, code quality, developer experience, and a head-to-head comparison with nanika. Cloned the repo, read every core module, traced the retry chains, mapped the extension points.
What I found wasn't a competitor. It was the other half of the stack.
Two ways to solve complex tasks
There's a fundamental design fork in AI agent systems that most people don't talk about. You can make one agent really good at everything, or you can make many agents good at one thing each and coordinate them.
Hermes chose door one. Nanika chose door two.
Hermes-agent is a single-agent system. One conversation loop, one runtime. When you give it a complex task, the LLM decides how to split it up on each turn. There are no saved plans. The model figures it out every time. It can hand off subtasks to child agents, but the depth limit is two.
Nanika runs missions as a dependency graph. You write PHASE lines — or the decomposer generates them — and the orchestrator executes them as a DAG. Independent phases dispatch in parallel. Each phase gets its own Claude Code session, its own persona, its own workspace. When a review phase finds blockers, the engine injects a fix phase and a re-review automatically.
Neither approach is wrong. They optimize for different things. And the differences cascade through every design decision in both projects.
What a single-agent system gets right
When all your intelligence goes into one agent, that agent gets really good at surviving. Hermes-agent's resilience engineering is the best I've seen in an open-source project.
The error recovery has six discrete layers, each handling a specific failure mode:
- Invalid tool name — fuzzy match via
difflib, three retries - Malformed JSON arguments — schema hints injected, two retries
- Context overflow — compress middle turns, preserve head and tail, retry up to three times
- Rate limit (429) — rotate to next credential in the pool, one-hour cooldown per key
- Auth failure — refresh token, retry
- Stream disconnect — reconnect with exponential backoff
Each layer is independent. A rate limit doesn't trigger the JSON repair logic. A context overflow doesn't rotate credentials. The failure modes don't leak into each other.
The credential pool deserves its own mention. Four selection strategies — fill-first, round-robin, random, least-used — with per-key cooldowns parsed from actual API response headers. When one key hits rate limits, the pool rotates automatically. When a key exhausts its billing, it gets a 24-hour cooldown and comes back. This is production-grade infrastructure for managing multiple API accounts across providers.
In nanika, workers propagate errors up the stack. The orchestrator handles retries at the phase level — if a phase fails, shu might eventually propose a fix mission. But the individual worker doesn't fight to recover. It runs, it produces output, it dies. The resilience lives in the coordination layer, not the execution layer.
Both patterns work. They just put the complexity budget in different places.
How both systems remember
This is where the two projects converge on the same problem from different angles.
Hermes's memory retrieval combines three signals into a scoring pipeline:
relevance = (0.4 × fts_score) + (0.3 × jaccard) + (0.3 × hrr_similarity)
final = relevance × trust_score × temporal_decay(half_life)Full-text search, Jaccard similarity between query and entry tokens, and holographic reduced representations — 1024-dimensional vectors using deterministic phase encoding via SHA-256 and circular convolution. Then two multipliers: a trust score that adjusts per user feedback, and temporal decay with a configurable half-life so old memories naturally fade.
Nanika's memory plugin uses a similar multi-signal approach — token matching, entity scoring, Jaccard similarity, and temporal decay with a configurable half-life. Stale entries naturally fade. A trust feedback loop lets the system learn which memories actually helped. The implementation details differ — pure Go, no HRR vectors, no external dependencies — but the principle is the same. You can't treat all memories as equally relevant forever.
Both systems also freeze memory snapshots at session start to preserve the Anthropic prefix cache. Hermes does this through its BuiltinMemoryProvider — the MEMORY.md and USER.md snapshots are captured once and the system prompt never mutates during a session. Nanika's workers seed a read-only MEMORY.md at spawn time and write new memories to a separate scratchpad that merges back after the phase completes. Same insight: mid-session memory writes invalidate the cache prefix and waste tokens.
Where the two systems diverge is what happens after memory is written.
Two approaches to learning
Hermes markets itself as an agent that learns from you. There are actually three separate mechanisms behind that claim, and it's worth understanding what each one does.
Memory extraction is the most visible. After a conversation ends, a background thread reviews the session and saves observations to persistent memory. This happens automatically — no manual step.
Prompt evolution is a separate research project — hermes-agent-self-evolution, an ICLR 2026 Oral. It uses genetic algorithms to evolve skills and tool descriptions across generations. Real research. But it's not integrated into the main agent loop. You'd run it separately as an experiment.
RL trajectory collection feeds production agent usage back into Hermes model training via the Atropos RL environment. This improves the underlying model, not the agent's strategy. The user benefits indirectly, on a different timescale.
Nanika's self-improvement is a closed loop at the orchestration layer. Background learning extraction runs automatically after every phase — the output gets piped through the learn logic and written to learnings.db without blocking the next phase. But that's just the data collection. The loop that closes it is the nen daemon. Scanners watch the event stream — Gyo for metrics anomalies, En for system health, Ryu for cost, Zetsu for prompt injection. When findings cluster, shu proposes a fix mission with PHASE lines and dispatches it. Ko evaluates past proposals against outcomes and feeds quality scores back.
These are complementary approaches. Hermes improves the model's tool-calling capability through trajectory data. Nanika improves the orchestration strategy given a fixed model. A system running both would benefit from improvements at two different layers.
Where the approaches meet
There's a pattern here that goes beyond these two projects. The problems that matter in long-running AI agent systems — memory scoring, prefix-cache management, automatic learning extraction, model tier routing — are converging across implementations.
Both systems route simple queries to cheaper models. Hermes uses keyword heuristics — under 160 characters, under 28 words, no code markers. Nanika's decomposer auto-assigns MODEL_TIER: quick to objectives that look like status checks or data lookups, reserving frontier models for architecture and implementation phases. Different mechanisms, same cost-saving insight.
Both systems freeze memory to protect the prefix cache. Both systems extract learnings in the background. Both systems use temporal decay to fade stale memories. These aren't coincidences — they're convergent evolution. When you run enough agent sessions, the same problems surface and the same solutions present themselves.
The difference is where each system invests its complexity budget after solving these shared problems.
Platform presence nobody else has
Fourteen native messaging platform adapters: Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Feishu, Home Assistant, SMS, email, Mattermost, DingTalk, WeCom, plus webhook and API server. All sharing a BasePlatformAdapter abstraction — image caching, session management, URL safety, message dispatch.
No other open-source agent has this. A single hermes-agent process maintaining conversations across every platform your users are on is a genuinely unique product capability.
Their CommandDef registry pattern is equally smart. One frozen dataclass entry generates CLI autocomplete, Telegram BotCommand menus, Slack subcommand mapping, gateway dispatch routing, and help text. Add a command once, every downstream surface updates automatically. That's the kind of design pattern that prevents an entire class of consistency bugs.
We handle messaging differently — Telegram and Discord as separate Go binaries with the channel protocol routing through the orchestrator. More modular, more isolated, but a different product shape.
The NousResearch angle
This project isn't just an agent. It's a strategic instrument for NousResearch that serves three functions simultaneously.
Distribution. MIT-licensed, fast install, 31k stars. The recommended default backend is Nous Portal. Every user who picks the default during hermes setup is a potential inference customer.
Training flywheel. The agent generates scored JSONL trajectories for supervised fine-tuning and connects to a live Atropos API for reinforcement learning. Production usage feeds tool-calling trajectory data back into Hermes model training. NousCoder-14B releasing in parallel with the agent tells you where that data is going.
Research benchmark. The self-evolution paper uses the agent as a reference harness for evaluating agentic RL approaches. Academic credibility — ICLR Oral — established early.
That's a level of strategic integration most agent projects don't have. The agent serves users, generates training data, and validates research in one artifact. Whether you think that's brilliant or concerning depends on how you feel about your conversations becoming training signal.
The engineering reality
I'd be dishonest if I didn't mention the rough edges. 329,000 lines of Python concentrated into two files — run_agent.py at 9,400 lines and cli.py at 8,600 lines. 9,036 tests with no coverage measurement configured anywhere. The velocity is visible in the git history — 34 commits in January, 3,054 in March, partly agent-authored.
But I'd also be dishonest if I framed this as just technical debt. The documentation is genuinely excellent — it explains why decisions were made, not just what the code does. The supply chain CI detects the litellm attack pattern, which is unusually sophisticated for an open-source project. The prompt caching implementation correctly preserves the prefix across turns, which is non-trivial and easy to get wrong. The security infrastructure — approval system, Tirith scanning, memory injection defense, timing-safe HMAC throughout the gateway — shows real threat awareness.
It's a project that grew faster than its hardening could keep up. That's a different problem from not caring about quality.
Where this leaves us
Hermes and nanika aren't competing. They're solving different problems at different layers.
Hermes is a single-agent runtime. It makes one agent as capable, resilient, and broadly connected as possible. If you want an agent that chats, codes, browses, messages across 14 platforms, learns from your feedback, and survives messy environments — hermes-agent is the most complete open-source option available.
Nanika is a multi-agent orchestrator. It decomposes complex tasks into specialist phases, routes them to personas, runs them as a dependency graph, and improves its own strategy over time. The workers are disposable. The coordination is the product.
The two systems could literally stack — nanika orchestrating missions where each worker phase spawns a hermes-agent instance instead of a Claude Code session. That probably won't happen. But the fact that it could tells you these projects sit at different layers of the same stack, not on the same layer competing for the same job.
Thirty-one thousand stars in six weeks is real. The engineering behind it is real, if uneven. The shared problems both projects solve — memory decay, cache stability, background learning, model routing — show that the hard parts of running AI agents at scale are becoming clearer across the field.
Good systems don't come from ignoring what others build. They come from understanding it well enough to see where you're solving the same problems and where you're not.