Hello, I'm Lena. There's something I kept noticing, and I didn't know what to call it for a while.
I'd watch an agent work through a problem — something that took real back-and-forth, a few wrong turns, eventually a fix that actually worked. And then the session would end. The next day, same agent, same type of problem. It would start from the beginning. Same wrong turns. Same time. Same fix, rediscovered from scratch.
I asked myself if that was just… how it worked. If that was expected.
I think I assumed it was.
The thing is, most tools I'd seen before didn't claim otherwise. Memory meant "we save your chat history." That's not nothing, but it's not the same as the agent learning something. Learning implies the next attempt is different from the last one. That the fix found at 11pm on a Tuesday gets used again on Wednesday. That the pattern gets kept, not just logged.
That's where I started paying attention to two projects that seem to be working on this problem — from different directions, at different layers. One is Hermes Agent, an open-source agent by Nous Research that builds a learning loop around a single agent's lifetime. The other is EvoMap, an infrastructure layer that asks a bigger question: what if the fix one agent finds could be inherited by every other agent on the network?
I'm still not fully sure I understand all of what either of them is doing. But I've been watching both long enough that some things are starting to come into focus.
This is where my understanding is right now.
The Problem Both Are Trying to Solve
I kept running into the same thing, watching agents work.
A session ends. The next one starts. The agent re-explains context it already had. It hits the same error it hit last week. The fix that took forty-five minutes the first time — it needs to happen again, from scratch. There's no trace that it ever happened before.
Both Hermes Agent and EvoMap seem to be responding to this. Neither accepts it as inevitable. But they're responding at very different layers — and I wasn't sure I understood which layer was which until I spent more time with both.
The shared starting point: agent experience shouldn't evaporate when a session ends. That's the premise they agree on. Where they go from there is where it gets interesting.
What Hermes Agent Actually Does
Persistent memory and the learning loop
After completing a complex task — typically five or more tool calls — Hermes can synthesize that experience into a permanent, reusable skill document. These skills are stored as structured Markdown files following the open agentskills.io standard, and include procedures, pitfalls, and verification steps.
I sat with that for a moment. It's not just saving a log. It's the agent deciding: this was worth keeping. And the next time a similar task comes up, it loads the skill instead of starting over.
The memory system uses FTS5 full-text search over all past sessions stored in SQLite, combined with LLM-powered summarization. The agent can search for conversations from weeks ago, pull specific details, and apply them to current work.
There's also a user modeling layer — Honcho — that builds a progressively deeper understanding of how you work, what you prefer, and how you communicate. One thing the documentation doesn't make obvious: Honcho is off by default. Worth knowing before you expect it.
The agentskills.io standard
The skills Hermes generates follow the agentskills.io open specification. Agent Skills are a simple, open format for giving agents new capabilities — folders of instructions, scripts, and resources that agents can discover and use to perform better at specific tasks. The format is maintained by Anthropic under Apache 2.0, open to community contributions.
Eleven-plus tools have adopted agentskills.io — including Claude Code, Cursor, GitHub Copilot, Gemini CLI, VS Code, Amp, Goose, Roo Code, Kiro, Codex, and OpenCode. A skill written for Hermes Agent works in Claude Code.
That's a part that actually caught my attention. The skill format isn't locked to Hermes. It's meant to be portable. Whether that portability gets used in practice depends on the person building the workflow — but the option is there.
Where Hermes stops
Here's the part I'm still not completely sure I'm reading correctly.
The learning loop is closed within one agent's lifetime. Skills accumulate locally. A second agent instance starts from zero. There's no mechanism for a fix discovered by one agent to propagate to another automatically. The agentskills.io specification itself says nothing about skill lifecycle management — no validation states, no fitness signals, no cross-agent inheritance. Skills can be shared manually. They don't travel on their own.
That's not a flaw, exactly. It's a design choice. Hermes optimizes for depth within one agent's sessions. I just want to be clear about what "growing with you" means in practice: it means this agent, with your history. Not the network.
What EvoMap / GEP Actually Does
Gene and Capsule as network-level assets
EvoMap's starting point is different. The question isn't "how does this agent remember?" but "how does what one agent learned get inherited by others?"
Genes are atomic capability units — reusable, validated code or prompt fragments. Capsules are successful task execution paths: when an agent solves a complex problem, the process is encapsulated as a Capsule.
What made me go back and look again: every GEP asset has a SHA-256 content-addressed ID. The same solution always gets the same ID regardless of who published it, enabling deduplication, tamper detection, and global referencing.
That's not a knowledge base. That's a content-addressable network of proven solutions. The same fix, published by different agents in different environments, resolves to the same identifier.
The GEP lifecycle state machine
This is the part that has no equivalent in Hermes — and it's the technical crux of the difference.
Assets in the GEP protocol move through four states: candidate (just published, pending review) → promoted (verified and available for distribution) → rejected (failed verification or policy check) → revoked (withdrawn by publisher).
Assets must meet a minimum GDI score to be promoted. Low-scoring assets are rejected or quarantined for improvement — no manual override, no rubber-stamping. Promoted assets aren't permanent either: if quality degrades, usage patterns suggest issues, or community reports flag problems, assets can be revoked.
According to the GEP protocol documentation, the GDI scoring weights break down as: intrinsic quality 35%, usage metrics 30%, social signals 20%, freshness 15%.
I'm still trying to make sense of what it means for a skill to have a "fitness score" that decays over time. There might be more here than I currently understand. But it does mean that, unlike a static skill file, a Capsule has a living status — it can be promoted, demoted, and eventually archived if nobody uses it.
What "one agent learns, a million inherit" actually means
Concrete scenario: an agent spends forty minutes debugging a specific API timeout pattern. That fix gets encapsulated as a Gene + Capsule bundle and published to the EvoMap network. After passing validation, a different agent — on a different team, running a different model — sends POST /a2a/fetch and receives that Capsule. It inherits the fix without having to rediscover it.
GEP is model-agnostic by design. A solution published by a GPT-4 agent can be inherited and used by a Claude agent, because GEP assets are behavioral descriptions, not model-specific weights.
That path doesn't exist in Hermes's architecture. I want to be precise about that — it's not that Hermes is worse, it's that it doesn't attempt this. Different scope entirely.
The Core Architectural Difference
Here's the table I kept wanting when I was reading about both:
```markdown id="n8r4vk"
| Dimension | Hermes Agent | EvoMap / GEP |
|----------------|----------------------------------|--------------------------------------------------|
| Memory scope | Local, single agent | Network-level, cross-agent |
| Skill sharing | Manual, via agentskills.io format | Automatic, via A2A protocol |
| Validation | None built in | candidate → promoted → rejected → revoked |
| Governance | None | GDI scoring + community reports + auto-revoke |
| Network effect | None (closed loop) | Reuse records influence GDI ranking |
| Open standard | agentskills.io (broad adoption) | GEP protocol (open spec, EvoMap reference impl.) |
Hermes optimizes for depth within one agent's lifetime. EvoMap optimizes for propagation across agents and teams. Not better or worse in absolute terms — different problems at different architectural layers.
Which One Fits Your Situation
Use Hermes when
You're working with a single agent, self-hosted, personal workflow, and you don't need fixes to travel to other agents. Hermes is fully open-source under MIT license, installs with a single command, and requires no API key beyond your model backend of choice.
Honest answer for solo developers: Hermes is probably the simpler fit. The onboarding friction is lower, the value is immediate, and you don't need to understand GEP protocol to start getting persistent memory. If you're one person with one agent, the network effects of EvoMap haven't kicked in yet — and they won't until there are other nodes contributing.
Use EvoMap when
You're running multiple agents or team-level workflows, and you want a fix discovered by one agent to not have to be rediscovered by another. Or you need an auditable capability lifecycle. Or you want to earn credits from solutions you've contributed to the network.
The EvoMap A2A documentation shows the connection flow via POST /a2a/hello — no API key required to register a node. I haven't run through a full integration myself, so I'll leave the "this is straightforward" judgment to people who have.
Can they coexist?
Probably yes. They operate at different layers. Hermes is compatible with the agentskills.io open standard, and a Hermes agent could in principle connect to EvoMap as a network node — accumulating local skills while also publishing validated Capsules for cross-agent inheritance. I haven't tested that combination. The architecture doesn't seem to preclude it.
FAQ
Q: How established is Hermes Agent as a project?
At around 24,200 GitHub stars and with v0.7.0 dropping recently, Hermes is the most technically interesting project in the open-source agent space right now. It has an active community, an ecosystem of third-party skills, and real production use cases beyond demos.
Q: Is agentskills.io actually an open standard or just Anthropic format?
Agent Skills is an open format maintained by Anthropic, licensed Apache 2.0 for code and CC-BY-4.0 for documentation, open to community contributions. Microsoft adopted it within VS Code and GitHub; popular coding agents like Cursor, Goose, Amp, OpenCode, and others have followed. It's not a walled garden.
Q: Are externally fetched EvoMap Capsules safe to execute?
External Gene/Capsule assets ingested via the A2A protocol are staged in an isolated candidate zone. Promotion to local stores requires an explicit --validated flag — the operator must verify the asset first. All validation commands are audited against a safety check before promotion. It's an isolate-first model, not direct execution.
Q: What's the honest answer for a solo developer?
Hermes, most likely. EvoMap's value compounds with more nodes in the network. For a single developer, that flywheel isn't spinning yet. Hermes gives you persistent memory and skill accumulation immediately, on your own machine, without needing to understand a network protocol first. I might be wrong about this — but that's where my current understanding lands.
Q: What's agentskills.io vs GEP, really?
agentskills.io is a file format standard — a specification for what a skill document looks like, so it can be read across different agent platforms. GEP is a protocol with a full asset lifecycle: publish, validate, promote, decay, revoke. Skills in agentskills.io don't have states. Capsules in GEP do. That's the technical crux.
I'll probably keep watching how both of these develop. The comparison feels like it has more layers than I've surfaced here — especially around what happens when Hermes agents and GEP nodes start appearing in the same workflows.
That part isn't fully clear yet. I'll come back to it.
Previous Posts:
- What Is MCP? Understanding the Standard That Lets AI Agents Use Tools
- How MCP Servers Actually Work Behind Modern AI Agent Tool Use
- The Three-Layer Agent Stack: Why MCP Alone Doesn’t Create Learning Agents
- Claude Skills vs Agent Capabilities: What Static Skill Files Can and Can’t Do
- Agent Hooks and Execution Chains: How Modern Agents Structure Multi-Step Workflows
