WikifitaGitHub live67e8de5
outro · antigravity-ecosystem/antigravity-hermes-wiki

Hermes Agent Research Wiki — System Architecture, Agent Loop & Cognitive Memory

Complete analysis of the 12-file Hermes Agent Research Wiki: system architecture, Do-Learn-Improve agent loop, Honcho cognitive memory, Freirean pedagogy, hardware optimization, and Co-Scientist math analysis.

Baixar raw

Hermes Agent Research Wiki — System Architecture, Agent Loop & Cognitive Memory

Source: /Users/alefita/.gemini/antigravity/worktrees/autoresearch-study/hermes-agent-research-wiki/ Created: May 27-28, 2026 Framework: Karpathy "LLM Wiki" pattern — compile-time knowledge engineering

1. What Is the Hermes Research Wiki

The Hermes Agent Research Wiki is a structured knowledge base following Karpathy's "LLM Wiki" pattern — a compile-time knowledge writeback system that replaces reactive RAG with pre-compiled, frontmatter-tagged, cross-referenced wiki pages. It was produced during the Antigravity 2.0 session autoresearch-study and contains 12 files covering the full technical stack from hardware inference to mathematical research proposals.

1.1 File Inventory

hermes-agent-research-wiki/
  index.md              -- Auto-generated ToC with tag cloud
  log.md                -- Append-only changelog
  SCHEMA.md             -- Immutable format rules
  SYSTEM_ARCHITECTURE.md -- Hardware topology & data flow
  GLOSSARY.md           -- Mathematical term definitions
  scripts/wiki_tool.py  -- Automated linting & index compilation
  wiki/
    antigravity_sdk.md       -- AGY SDK three-pillar architecture
    hermes_agent.md          -- Do-Learn-Improve paradigm
    honcho_memory.md         -- Cognitive memory layer
    sleeping_assimilation.md -- Background weight consolidation
    hardware_local_inference.md -- Dual-machine optimization
    co_scientist_math.md     -- Formal proof & Escolinha

1.2 The LLM Wiki Pattern

The wiki follows Karpathy's pattern where knowledge is:

  • Compiled at write time, not queried at read time
  • Structured with YAML frontmatter (type, title, tags, status)
  • Cross-referenced with wikilinks that are validated by wiki_tool.py
  • Audited automatically for orphan pages, broken links, and untagged entries

This is not RAG. RAG retrieves relevant chunks at query time from a vector store. The LLM Wiki pattern pre-processes knowledge into dense, authoritative pages that the agent loads into context. The trade-off is up-front compilation cost for zero-latency reads.

2. System Architecture

2.1 Hardware Topology

The architecture spans two machines connected via WebSocket/SSE:

graph TB
    subgraph "MacBook Pro M3 (Development)"
        AGY[Antigravity 2.0 SDK/CLI]
        AGY_MODEL[Gemini 2.5 Pro]
        AGY_TOOLS[MCP Tools]
        MLX[Apple MLX Runtime]
    end

    subgraph "Ryzen 5 (Execution Server)"
        HERMES[Hermes Agent]
        HERMES_MODEL[Local LLM - llama.cpp]
        RTX[RTX 2060 6GB - Layers 0-18]
        GTX[GTX 1050 Ti 4GB - Layers 19-30]
        SYS_RAM[System RAM - Remaining]
        CRON[Background Cron Tasks]
    end

    subgraph "Shared Cognitive Plane"
        HONCHO[Honcho Memory Daemon]
        HONCHO_DB[(Entity Graphs)]
    end

    AGY <-->|"WebSocket/SSE"| HERMES
    AGY <-->|"API"| AGY_MODEL
    HERMES <-->|"llama.cpp"| HERMES_MODEL
    HERMES_MODEL --> RTX
    HERMES_MODEL --> GTX
    HERMES_MODEL --> SYS_RAM
    AGY <-->|"context/query"| HONCHO
    HERMES <-->|"background dream"| HONCHO
    HONCHO --> HONCHO_DB

2.2 Dual-GPU Layer Partitioning

The Ryzen server runs Gemma 4 MoE 27B at Q3_K_L quantization (~12.5GB), split across hardware:

ComponentLayersRoleVRAM
RTX 2060 6GB0-18Fast attention, routing, early FFN~6GB
GTX 1050 Ti 4GB19-30Later FFN layers~4GB
System RAM (16GB)RemainingExpert weights, KV overflow~2.5GB

Total available VRAM: ~10GB. With Q3_K_L quantization, a 27B MoE model fits within this budget when expert weights in system RAM are loaded on-demand.

2.3 Key Optimizations

TurboQuant: Dynamic MoE expert offloading with prediction-based prefetch. Instead of loading all expert weights into VRAM, TurboQuant predicts which experts the router will activate and prefetches them into GPU memory ahead of time.

KV-Direct: Reconstructs the key-value cache from the residual stream, eliminating the need to store the full KV cache. Reduces VRAM from ~3.2GB to ~350MB for 8K context — a 90% reduction. Trade-off: slight increase in compute time for cache reconstruction.

Layer Partitioning Strategy: The RTX 2060 handles layers 0-18 (attention-heavy, latency-sensitive) while the GTX 1050 Ti handles layers 19-30 (FFN-heavy, compute-bound). This maps workload to hardware strengths — the RTX 2060's higher memory bandwidth benefits attention, while the GTX 1050 Ti's simpler architecture suffices for FFN compute.

3. The Do-Learn-Improve Agent Loop

3.1 Hermes Agent Paradigm

The Hermes agent (Nous Research) operates on a three-phase cycle:

flowchart LR
    DO["DO<br/>Execute multi-step task"] --> LEARN["LEARN<br/>Analyze logs, extract patterns"]
    LEARN --> IMPROVE["IMPROVE<br/>Compile into reusable Skill File"]
    IMPROVE -->|"registered in<br/>permanent library"| DO

Do: Execute a multi-step task using current knowledge and tools. Every action is logged with full context.

Learn: After task completion, analyze the execution logs. Identify reusable patterns, failure modes, and optimization opportunities. This is not passive reflection — it is structured log analysis with specific extraction criteria.

Improve: Compile the extracted patterns into a Skill File — a reusable, registered capability in the agent's permanent library. Skills are versioned, shareable, and composable.

3.2 Cross-Platform Messaging

Hermes connects to 20+ messaging platforms:

  • Telegram, Discord, Slack, WhatsApp
  • WebSockets (custom integrations)
  • SMS (via gateway)
  • Email (IMAP/SMTP)

This enables the agent to be invoked from any communication channel and maintain context across platforms.

3.3 Background Autonomy

Hermes supports cron-based autonomous execution. Tasks can be scheduled to run without human intervention:

  • Periodic knowledge compilation
  • Scheduled monitoring and alerting
  • Background training loops
  • Automated testing and validation

3.4 Dual-Agent MCP Bridge

The integration between Antigravity and Hermes uses a dual-agent MCP bridge:

graph LR
    subgraph "Antigravity (MacBook)"
        A_TOOLS[MCP Tools]
        A_REASON[High-Context Reasoning]
    end

    subgraph "Hermes (Ryzen)"
        H_PROC[Procedural Loops]
        H_MSG[Messaging]
        H_PERSIST[Persistent Memory]
    end

    A_TOOLS <-->|"MCP Bridge"| H_PROC
    A_REASON -->|"delegation"| H_PROC
    H_PERSIST -->|"context"| A_REASON
  • Antigravity provides high-context reasoning (Gemini 2.5 Pro, 1M context) and interactive development
  • Hermes provides persistent procedural loops, cross-platform messaging, and background autonomy
  • Each agent exposes capabilities to the other via MCP tool definitions

4. Honcho Cognitive Memory Integration

4.1 What Is Honcho

Honcho (Plastic Labs) is a cognitive memory layer that replaces traditional RAG with entity-based reasoning. Instead of storing documents as vectors and retrieving by similarity, Honcho maintains structured semantic graphs for three entity types:

EntityRepresentsGraph Content
UserThe human principalPreferences, knowledge state, communication patterns
AgentThe AI systemCapability history, confidence patterns, failure modes
WorldExternal contextDomain knowledge, relationships, temporal state

4.2 Background "Dreaming"

Honcho's most distinctive feature is offline reasoning loops — called "dreaming" — that run between active sessions:

flowchart TD
    SESSION["Active Session<br/>(conversation data)"] --> SCAN["Dream Cycle<br/>Scan conversations"]
    SCAN --> CLUSTER["Cluster Concepts"]
    CLUSTER --> INFER["Run Inferences"]
    INFER --> UNIFY["Write Unified Conclusions"]
    UNIFY --> STORE["Store in Entity Graphs"]
    STORE -->|"enriched context"| NEXT["Next Session"]

During dreaming, Honcho:

  1. Scans recent conversations across all sessions
  2. Clusters related concepts and themes
  3. Runs inferences to derive implicit knowledge
  4. Writes unified conclusions with confidence scores
  5. Stores results in the entity graphs for future retrieval

4.3 Interaction Mechanisms

MechanismPurposeReturns
Context ingestionFeed conversation data into HonchoAcknowledgment
Dynamic queryingAsk Honcho for relevant contextStructured conclusions with confidence scores
Specialized toolshoncho_context, honcho_search_conclusions, honcho_askDomain-specific responses

4.4 Shared Memory Blueprint

The architecture deploys Honcho as a Dockerized service on the Ryzen server, accessible by both machines:

  • MacBook (Antigravity) queries Honcho for interactive context during research sessions
  • Ryzen (Hermes) feeds conversation data and triggers dream cycles during background operation

This creates a shared cognitive plane where knowledge accumulated by either agent is available to both.

5. Sleeping Assimilation — Background Weight Consolidation

5.1 The Biological Analog

The sleeping_assimilation.md page describes the most architecturally ambitious concept: a biological sleep-cycle analog for local LLM weight updates. During "sleep" (background idle time), the system consolidates daytime learning into model weights.

5.2 The Four Phases

flowchart LR
    subgraph "Phase 1: Episodic Extraction"
        E1["Query Honcho"] --> E2["Focus on educational sessions"]
        E2 --> E3["Extract key learning moments"]
    end

    subgraph "Phase 2: Synthesis"
        S1["Raw conversations"] --> S2["Gemini rewrites"]
        S2 --> S3["Dense QA training pairs"]
    end

    subgraph "Phase 3: Parametric Updates"
        P1["LoRA/QLoRA<br/>(.bin adapter)"]
        P2["LARQL<br/>(weight graph updates)"]
    end

    subgraph "Phase 4: Validation"
        V1["Static benchmark test"]
        V2{"Pass?"}
        V3["Commit weights"]
        V4["Revert"]
    end

    E3 --> S1
    S3 --> P1
    S3 --> P2
    P1 --> V1
    P2 --> V1
    V1 --> V2
    V2 -->|Yes| V3
    V2 -->|No| V4

5.3 LARQL — Lazarus Query Language

LARQL treats FFN (feed-forward network) layers as queryable relational databases. Instead of fine-tuning the entire model, LARQL performs surgical weight updates using SVD decomposition:

W_new = W + eta * (u_target * v_target^T)

Where:

  • W is the original weight matrix
  • eta is the learning rate
  • u_target and v_target are SVD-derived vectors targeting specific factual knowledge
  • The update is rank-1, modifying only the subspace relevant to the new information

This is mechanistic interpretability applied to weight editing — the FFN layers are treated as key-value stores, and LARQL queries them to find the right insertion point.

5.4 The Karpathy AutoResearch Loop

The sleeping assimilation pipeline follows Karpathy's AutoResearch pattern:

FileMutabilityPurpose
program.mdImmutableDefines the goal and success criteria
prepare.pyImmutableValidation script (determines pass/fail)
train.pyMutableTraining script (evolved by the loop)

The loop: propose code change to train.py -> train for fixed time -> evaluate with prepare.py -> git commit if improved, revert if not. This is evolutionary search over the training hyperparameter space.

6. Hardware for Local Inference

6.1 The Dual-Machine Architecture

MachineCPUGPURAMRole
MacBook Pro M3Apple M3 (12-core)Integrated (24GB unified)24GBInteractive development, models up to 16B
Ryzen 5AMD Ryzen 5RTX 2060 6GB + GTX 1050 Ti 4GB16GB24/7 background agent, 10GB total VRAM

6.2 Model Deployment Strategy

MacBook (interactive): Apple MLX for models up to 16B parameters. MLX leverages the unified memory architecture — no CPU-GPU data transfer bottleneck. Suitable for research sessions requiring fast inference.

Ryzen (background): llama.cpp with Metal/CUDA for the 27B MoE model. The dual-GPU layer partitioning maximizes throughput while staying within VRAM constraints. KV-Direct reduces KV cache overhead by 90%.

6.3 Hardware-Software Co-Design

Every optimization is hardware-aware:

  • TurboQuant exploits the RTX 2060's memory bandwidth for expert prefetch
  • KV-Direct is necessary because 10GB total VRAM cannot hold a full 8K KV cache for 27B params
  • Layer partitioning maps attention (latency-sensitive) to RTX 2060 (faster) and FFN (compute-bound) to GTX 1050 Ti
  • MLX on MacBook eliminates the von Neumann bottleneck by keeping everything in unified memory

7. Co-Scientist Math Analysis & Escolinha

7.1 The General Closure Function Theorem

The co_scientist_math.md page documents Alefita's mathematical research proposal, which collapses exponential search O(2^n) into polynomial algebraic inference using five mathematical tools:

ToolRole
Split-Dual Complex Algebraz = x + yj + epsilon*d where j^2=+1, epsilon^2=0 — extends complex numbers with a dual component
Phase DiscriminantPhi(z) = Re(z * conj(z)) mod Lambda — topological invariant for classification
Davies-Meyer Differentiable GeneratorContinuous mapping of cryptographic compression — enables gradient-based optimization over hash-like functions
Birkhoff Polytopeconv(P_n) — convex hull of permutation matrices, used for stability constraints
Williams Space-Time TradeoffTIME[t] subset SPACE[sqrt(t log t)] — expanding space compresses time

7.2 Erdos Problem #676

The specific application: every large integer can be represented as n = ap^2 + b. The approach:

  1. Lift the problem to a toroidal manifold T^2
  2. Map orbits under the prime set and powers of 2
  3. Check intersection via topological invariant (phase discriminant)

This is isomorphic to the unit distance problem approach (see unit-distance): ascend to a higher-dimensional algebraic structure, solve there, and project back.

7.3 The "Escolinha" Framework

Escolinha (Portuguese for "Little School") is a Freirean pedagogical framework where:

  • Alefita acts as educator-student (the one who knows the domain but learns from the agent's computational perspective)
  • The agent acts as student-educator (the one who computes but learns domain intuition from Alefita)

The framework uses Socratic dialogue, not token feeding. The agent identifies its own confusion points ("temas geradores" — generative themes, a Freire concept) and asks for clarification. This is encoded in the system prompt structure and session interaction patterns.

Connection to Paulo Freire: Freire's Pedagogy of the Oppressed (1968) rejects the "banking model" of education (depositing knowledge into passive students). The Escolinha applies this to AI: the human does not "deposit" instructions into the agent. Instead, both parties engage in dialogical co-construction of knowledge. The agent's ability to identify its own confusion is the analog of Freire's "problem-posing education."

8. Supporting Infrastructure

8.1 SCHEMA.md — Format Rules

The schema defines immutable format rules for all wiki pages:

  • YAML frontmatter with required fields (type, title, tags)
  • Content in GitHub-flavored Markdown
  • Cross-references via wikilinks
  • Code blocks with language identifiers
  • Tables for structured data

8.2 wiki_tool.py — Automated Tooling

A zero-dependency Python CLI (no PyYAML — fallback parser included):

CommandFunction
python wiki_tool.py lintValidate frontmatter, detect broken wikilinks, flag untagged pages
python wiki_tool.py indexGenerate index.md with table of contents and tag cloud
python wiki_tool.py auditFull audit: lint + orphan detection + link graph

8.3 GLOSSARY.md — 8 Technical Terms

TermDefinition
Split-Dual Complex Algebraz = x + yj + epsilon*d, j^2=+1, epsilon^2=0
Phase DiscriminantPhi(z) = Re(z * conj(z)) mod Lambda
Birkhoff Polytopeconv(P_n) — convex hull of permutation matrices
Davies-Meyer Differentiable GeneratorContinuous mapping of cryptographic compression
LARQLMechanistic interpretability treating FFN as queryable relational DB
QLoRA4-bit NormalFloat quantization with low-rank adapters
KV-DirectResidual cache reconstruction eliminating 90% of KV cache overhead
TurboQuantDynamic MoE expert offloading with prediction-based prefetch

9. Significance and Cross-References

9.1 The Wiki as Research Infrastructure

The Hermes Research Wiki is not documentation — it is a research instrument. Each page is a hypothesis about how the multi-agent ecosystem should work. The wiki_tool.py ensures consistency. The SCHEMA.md enforces discipline. The cross-references create a knowledge graph that any agent (human or AI) can navigate.

9.2 Connection to the Unit Distance Research

The Co-Scientist math analysis directly informed the unit-distance research. The split-dual complex algebra and phase discriminant tools were originally proposed for Erdos Problem #676 but the algebraic machinery (especially the Birkhoff Polytope for stability and Williams' space-time tradeoff) influenced the H16 multi-quadratic CM approach.

9.3 Connection to the ClickFix Response

The multi-agent swarm architecture described here (Antigravity for reasoning, Hermes for procedural execution, Honcho for cognitive memory) is the same architecture that powered the clickfix-handoff incident response. The domain independence of the swarm methodology was validated in both mathematical research and cybersecurity forensics.

9.4 Connection to CAMDOM

The hardware-aware engineering philosophy (optimizing for specific GPU configurations, exploiting system limitations as features) mirrors the approach Alefita used in camdom, where BLE race conditions were transformed from bugs into features for the QUIC/TCP ACK multiplexing system.

Cross-References

  • antigravity-strawberry-research — The Strawberry Deep Research that builds on the Peirce type-token analysis from this wiki
  • antigravity-unified-scheduler — The Unified Scheduler Thesis that applies the Davies-Meyer differentiable generator concept
  • antigravity-mcp-tools — MCP tool integrations that connect to the dual-agent bridge architecture
  • unit-distance — The mathematical research that used the Co-Scientist framework
  • clickfix-handoff — The incident response that validated the multi-agent swarm architecture
  • camdom — Hardware-aware engineering philosophy applied to BLE mesh networking