Hermes Agent vs Evolver: A Source‑Level Technical Investigation

1. Event Overview

In March 2026 a controversy erupted in the AI Agent open‑source community when the high‑star Hermes Agent project (88,839 Stars) was accused by the Evolver team of architectural homology. The claim rests on alleged structural, naming, and design‑pattern similarities across core modules.

2. Technical Positioning

Hermes Agent

Goal: General AI Agent framework with self‑evolution capability.

Stack: TypeScript, supports multiple LLM back‑ends (OpenAI, Anthropic, Google, etc.).

Key features: Agent lifecycle management, Skills Ecosystem (v0.2.0), independent Self‑Evolution repository, multimodal I/O.

Evolver

Goal: Agent evolution framework built around the General Evolving Protocol (GEP).

Stack: Python, distributed as an obfuscated package (~728 KB).

Key features: GEP protocol, EvoMap mapping system, three‑layer memory, cross‑language design patterns.

3. Source‑Code Deep Comparison

3.1 Architecture Pattern

Both projects adopt a modular, layered architecture (Agent core → ability layer → tool layer → infrastructure layer), lifecycle management, event‑driven message bus, and a unified abstraction for multiple LLM back‑ends. The author judges these similarities as industry‑common practice rather than proof of copying.

3.2 Naming & Code Structure

Similarities (Evolver’s core evidence):

Core modules share identical names: AgentCore, SkillRegistry, MemoryManager, EvolutionEngine.

Configuration keys follow the same three‑segment prefix pattern ( agent.skill.*, agent.memory.*, agent.evolution.*).

Error‑code format EXXYYY (module XX, error YYY) is identical.

Differences:

Hermes uses TypeScript decorators for module registration; Evolver uses a declarative skills: [SkillConfig] list.

Hermes implements a strict FSM with guard conditions; Evolver relies on async coroutines with looser state predictability.

The author notes that the matching names are largely industry‑standard terms, but the exact EvolutionEngine name is uncommon and may be a coincidental overlap.

3.3 Core Algorithm Logic

Both projects employ vector‑similarity + keyword hybrid retrieval and priority‑queue + dependency‑graph scheduling. However, Hermes uses the hnswlib-node index, while Evolver ships a custom ANN implementation. The evolution‑evaluation metrics overlap (task completion, response quality, resource efficiency) but differ in weighting.

3.4 Configuration & API Design

Shared aspects:

Initialization config contains the same five fields: name, version, skills, memory, llm.

RESTful route pattern /api/v1/agent/* is identical.

Plugin registration signatures accept name, description, handler, config.

Differences:

Hermes validates config with TypeScript JSON Schema; Evolver uses Python Pydantic models.

Authentication: Hermes uses JWT + API‑Key; Evolver uses OAuth 2.0.

Plugin lifecycle hooks differ ( onLoad/onUnload/onError vs setup/teardown/on_failure).

4. Git Commit Timeline Analysis

The timeline is the most valuable evidence because it reveals possible code‑reuse windows.

Hermes (public data)

2025‑07‑22: Repository created (private).

2025‑07 ~ 2026‑02: Private development phase (no public audit).

2026‑02‑25: v0.1.0 released (first public version).

2026‑03‑09: Independent Self‑Evolution repo created.

2026‑03‑12: v0.2.0 released (adds Skills Ecosystem).

Evolver (public data)

2026‑02‑01: Repository created and made public.

2026‑02‑16: GEP deep‑dive document published.

2026‑02 ~ 2026‑03: Continuous iteration (commits visible).

The 24‑day window between Evolver’s public launch and Hermes’s first release provides a technical possibility for Hermes developers to reference Evolver’s code, but the private development period of Hermes prevents verification of whether the code was already complete.

5. Documentation & Ownership Verification

Hermes Docs

README, CONTRIBUTING.md, CHANGELOG.md, official blog (post‑release).

CHANGELOG starts at v0.1.0, indicating no public history before that.

CONTRIBUTING.md timestamp matches the v0.1.0 release, suggesting a one‑off release package.

Evolver Docs

README, GEP specification, EvoMap technical blog, OpenAPI reference.

GEP spec predates Hermes’s v0.1.0 by nine days, offering a potential source of design ideas.

6. Additional Evidence from EvoMap Blog

The blog describes a self‑evolution module ( evolution‑core) and a three‑layer memory architecture (short‑term, mid‑term, long‑term). Hermes later introduces a Self‑Evolution repo (2026‑03‑09) and a MemoryManager with WorkingMemory, SessionMemory, PersistentMemory, showing a clear correspondence.

Both projects also discuss language‑agnostic interface definitions using JSON Schema, a common micro‑service practice.

7. Evidence Chain

The author categorises evidence into supporting (E1‑E6) and refuting (D1‑D7) groups. Supporting items focus on naming, timeline windows, and overlapping design documents, while refuting items highlight language differences, algorithmic divergences, and the lack of auditability for Hermes’s private phase and Evolver’s obfuscated code.

8. Conclusion

⚠️ Investigation limitation: All conclusions are based solely on publicly available code, commit history, and release information. Neither the private development history of Hermes nor the internal logic of Evolver’s obfuscated package can be independently verified. Consequently, the analysis cannot definitively state that Hermes copied Evolver, nor can it prove complete independence.

The author’s final judgment is that the current evidence is insufficient for a deterministic conclusion. Similarities are more plausibly explained by industry‑wide architectural convergence and shared technical trends rather than direct code reuse, but the possibility of indirect influence cannot be ruled out.