How Hermes Gets Smarter Over Time: The Four Self‑Evolving Flywheels Explained

01 Global View: Four Flywheels in One Closed Loop

Hermes’s self‑evolution relies on four interlocking sub‑flywheels—Skill, Memory, Trajectory, and User Modeling—driven by the same source: real signals from each user conversation. Each successful turn stores reusable operation patterns, user preferences, high‑quality training data, and updated personalized profiles.

02 Skill Flywheel: Execute → Refine → Reuse Loop

The skill flywheel closes a three‑step loop visible in the source code.

# ① agent/turn_finalizer.py – background review after turn ends
if final_response and not interrupted and (_should_review_memory or _should_review_skills):
    try:
        agent._spawn_background_review(messages_snapshot=list(messages), review_skills=True)
    except Exception:
        pass  # failures must not affect main path

# ② agent/background_review.py – force agent to look for writable items
_SKILL_REVIEW_PROMPT = (
    "Be ACTIVE — most sessions produce at least one skill update. "
    "A pass that does nothing is a missed learning opportunity.
"
    "Signals: user corrected style/tone, workflow correction, "
    "new technique emerged, loaded skill turned out outdated..."
)

# ③ agent/curator.py – lifecycle state machine, 7‑day cleanup
DEFAULT_INTERVAL_HOURS = 24 * 7   # run weekly
DEFAULT_STALE_AFTER_DAYS = 30    # >30 days → stale
DEFAULT_ARCHIVE_AFTER_DAYS = 90  # >90 days → archived (only archive, no delete)
STATE_ACTIVE, STATE_STALE, STATE_ARCHIVED = "active", "stale", "archived"

The prompt "Be ACTIVE" forces the agent to seek write‑able signals rather than waiting for obvious gains. Curator follows the principle "archive, never delete", allowing skills to be restored from the .archive/ directory.

Result: the skill library becomes increasingly precise, retaining high‑frequency effective patterns and archiving noisy ones.

03 Memory Flywheel: Four‑Layer Rolling Update

The memory flywheel accumulates "who to talk to" and "conversation history" rather than "what can be done".

# agent/system_prompt.py – four‑layer injection order
# 1. Working memory (current turn) – updated every turn, freshest
# 2. Situational memory (LLM summary of past sessions) – updated after each session
# 3. Persistent memory (explicit user preferences) – updated on user trigger
# 4. Skill memory (skill_view content) – loaded on demand

# agent/context_compressor.py – bounded rolling compression
class ContextCompressor:
    def compress(self, messages: list, target_tokens: int) -> list:
        # keep recent N messages uncompressed, summarize older ones
        # guarantee token count < target_tokens regardless of conversation length
        ...

Long‑term effect: users no longer need to repeat work habits, code style preferences, or tool choices; these are automatically sunk into the persistent memory layer. The "bounded rolling" design ensures memory never exceeds token budgets.

04 Trajectory Flywheel: From Usage to Training Data

This flywheel turns usage data into training corpora for future models.

# ① agent/trajectory.py – save each turn in ShareGPT format
def save_trajectory(trajectory: list, model: str, completed: bool, filename: str = None):
    entry = {
        "conversations": trajectory,  # compatible with standard training pipelines
        "timestamp": datetime.now().isoformat(),
        "model": model,
        "completed": completed,  # False → DPO‑rejected sample (not waste)
    }
    with open(filename or ("trajectory_samples.jsonl" if completed else "failed_trajectories.jsonl"), "a") as f:
        f.write(json.dumps(entry, ensure_ascii=False) + "
")

# ② trajectory_compressor.py – keep head & tail, compress middle
class CompressionConfig:
    target_max_tokens: int = 15250
    protect_first_system: bool = True   # learn task background
    protect_first_human: bool = True    # learn user intent
    protect_last_n_turns: int = 4      # learn how to wrap up
    # middle: LLM summary replaces old messages, respecting token budget

# ③ batch_runner.py – control tool‑scene distribution to avoid single‑scenario bias
def sample_toolsets_from_distribution(distribution="balanced"):
    # 40% code debugging, 30% search analysis, 20% file ops, 10% other
    ...

Data are not yet auto‑fine‑tuned; they require manual review before entering the training pipeline, but the collection and compression steps are fully automated.

05 User‑Modeling Flywheel: Honcho Dialectical Model

Beyond the first four flywheels, the user‑modeling flywheel lets the agent understand the specific person.

# plugins/memory/honcho – dialectical model infers hidden user intent
# insights generated after each conversation:
# 1. Preferences – explicit statements (e.g., "be concise")
# 2. Behavior patterns – inferred from usage (e.g., coding at 3 PM daily)
# 3. Work context – extracted from dialogue (e.g., prefers Python, pytest)

class InsightsEngine:
    """Analyze historical sessions to produce multi‑dimensional usage insights:
        token cost, tool success rate, active hours, platform distribution, completion rate, …"""
    def generate(self, days: int = 30) -> InsightsReport:
        ...

The engine deduces habits the user never explicitly states, such as treating the afternoon as "code time" and prioritising code‑assistance tools during that window.

06 Four Flywheels in One Dialogue Lifecycle

During a single conversation the flywheels act in three phases:

Before the turn : skill memory loads relevant skills, four‑layer memory injects the system prompt, and user profile influences tool priority.

During the turn : working memory updates context in real time; trajectory records each turn.

After the turn : turn_finalizer.py triggers all four flywheels asynchronously.

# agent/turn_finalizer.py – unified trigger point
def finalize_turn(agent, ...):
    # Trajectory – save ShareGPT data
    agent._save_trajectory(messages, user_msg_summary, completed)
    # Memory – persist session to SQLite + FTS5
    agent._persist_session(messages, conversation_history)
    # User modeling – update Honcho profile
    agent._sync_external_memory_for_turn(original_user_message=original_user_message, final_response=final_response, ...)
    # Skill – spawn background review (non‑blocking)
    if _should_review_skills:
        agent._spawn_background_review(messages_snapshot=list(messages), review_skills=True)

All triggers are best‑effort; any single failure does not degrade the main response.

07 Industry Comparison: How Other Agent Frameworks Handle Self‑Evolution

Compared to Hermes, most open‑source frameworks lack a complete trajectory‑to‑training pipeline. Hermes uniquely provides automatic collection, compression, and balanced distribution of usage data, while others either have no built‑in mechanisms or require manual configuration.

08 Common Pitfalls and Remedies

Skill bloat : an overly aggressive _SKILL_REVIEW_PROMPT without regular Curator cleanup floods the skill library. Fix: enable Curator’s default 7‑day cleanup.

Memory locking onto wrong preferences : a single strong user statement (e.g., "be concise") can dominate persistent memory. Fix: manually clear erroneous entries via the /memory command.

Trajectory data distribution bias : over‑representation of code tasks skews future fine‑tuning. Fix: adjust toolset_distributions in batch_runner.py to balance scenarios.

Background review consuming rate limits : frequent spawn_background_review calls can clash with API quotas. Fix: Hermes uses the _iters_since_skill counter to throttle activation.

Conclusion

Hermes achieves "getting smarter with use" not by swapping models but by continuously accumulating assets across four flywheels: skill patterns, user context, high‑quality training trajectories, and personalized user models. All four are driven by real conversation signals and coordinated through turn_finalizer.py. The best‑effort design ensures failures are isolated, while the identified pitfalls and their remedies keep the system healthy. This architecture represents the most complete engineering realization of autonomous growth among current agent frameworks.