---
name: antigravity-hermes-wiki
type: analysis
title: "Hermes Agent Research Wiki — System Architecture, Agent Loop & Cognitive Memory"
description: "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."
tags: [antigravity, hermes, honcho, karpathy, llm-wiki, agent-loop, cognitive-memory, freire, co-scientist, local-inference]
timestamp: 2026-07-22
---
# 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:
```mermaid
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:
| Component | Layers | Role | VRAM |
|-----------|--------|------|------|
| RTX 2060 6GB | 0-18 | Fast attention, routing, early FFN | ~6GB |
| GTX 1050 Ti 4GB | 19-30 | Later FFN layers | ~4GB |
| System RAM (16GB) | Remaining | Expert 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:
```mermaid
flowchart LR
DO["DO
Execute multi-step task"] --> LEARN["LEARN
Analyze logs, extract patterns"]
LEARN --> IMPROVE["IMPROVE
Compile into reusable Skill File"]
IMPROVE -->|"registered in
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:
```mermaid
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:
| Entity | Represents | Graph Content |
|--------|-----------|---------------|
| **User** | The human principal | Preferences, knowledge state, communication patterns |
| **Agent** | The AI system | Capability history, confidence patterns, failure modes |
| **World** | External context | Domain knowledge, relationships, temporal state |
### 4.2 Background "Dreaming"
Honcho's most distinctive feature is offline reasoning loops — called "dreaming" — that run between active sessions:
```mermaid
flowchart TD
SESSION["Active Session
(conversation data)"] --> SCAN["Dream Cycle
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
| Mechanism | Purpose | Returns |
|-----------|---------|---------|
| **Context ingestion** | Feed conversation data into Honcho | Acknowledgment |
| **Dynamic querying** | Ask Honcho for relevant context | Structured conclusions with confidence scores |
| **Specialized tools** | `honcho_context`, `honcho_search_conclusions`, `honcho_ask` | Domain-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
```mermaid
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
(.bin adapter)"]
P2["LARQL
(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:
| File | Mutability | Purpose |
|------|-----------|---------|
| `program.md` | **Immutable** | Defines the goal and success criteria |
| `prepare.py` | **Immutable** | Validation script (determines pass/fail) |
| `train.py` | **Mutable** | Training 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
| Machine | CPU | GPU | RAM | Role |
|---------|-----|-----|-----|------|
| MacBook Pro M3 | Apple M3 (12-core) | Integrated (24GB unified) | 24GB | Interactive development, models up to 16B |
| Ryzen 5 | AMD Ryzen 5 | RTX 2060 6GB + GTX 1050 Ti 4GB | 16GB | 24/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:
| Tool | Role |
|------|------|
| **Split-Dual Complex Algebra** | `z = x + yj + epsilon*d` where `j^2=+1`, `epsilon^2=0` — extends complex numbers with a dual component |
| **Phase Discriminant** | `Phi(z) = Re(z * conj(z)) mod Lambda` — topological invariant for classification |
| **Davies-Meyer Differentiable Generator** | Continuous mapping of cryptographic compression — enables gradient-based optimization over hash-like functions |
| **Birkhoff Polytope** | `conv(P_n)` — convex hull of permutation matrices, used for stability constraints |
| **Williams Space-Time Tradeoff** | TIME[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):
| Command | Function |
|---------|----------|
| `python wiki_tool.py lint` | Validate frontmatter, detect broken wikilinks, flag untagged pages |
| `python wiki_tool.py index` | Generate `index.md` with table of contents and tag cloud |
| `python wiki_tool.py audit` | Full audit: lint + orphan detection + link graph |
### 8.3 GLOSSARY.md — 8 Technical Terms
| Term | Definition |
|------|-----------|
| **Split-Dual Complex Algebra** | `z = x + yj + epsilon*d`, `j^2=+1`, `epsilon^2=0` |
| **Phase Discriminant** | `Phi(z) = Re(z * conj(z)) mod Lambda` |
| **Birkhoff Polytope** | `conv(P_n)` — convex hull of permutation matrices |
| **Davies-Meyer Differentiable Generator** | Continuous mapping of cryptographic compression |
| **LARQL** | Mechanistic interpretability treating FFN as queryable relational DB |
| **QLoRA** | 4-bit NormalFloat quantization with low-rank adapters |
| **KV-Direct** | Residual cache reconstruction eliminating 90% of KV cache overhead |
| **TurboQuant** | Dynamic 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