Allegro
7897a5530d
Some checks are pending
Deploy Nexus / deploy (push) Waiting to run
Co-authored-by: Allegro <allegro@hermes.local> Co-committed-by: Allegro <allegro@hermes.local>
89 lines
5.0 KiB
Markdown
89 lines
5.0 KiB
Markdown
# Agent Review Log — Hermes v2.0 Architecture Spec
|
|
|
|
**Document:** `docs/hermes-v2.0-architecture.md`
|
|
**Reviewers:** Allegro (author), Allegro-Primus (reviewer #1), Ezra (reviewer #2)
|
|
**Epic:** #421 — The Autogenesis Protocol
|
|
|
|
---
|
|
|
|
## Review Pass 1 — Allegro-Primus (Code / Performance Lane)
|
|
|
|
**Date:** 2026-04-05
|
|
**Status:** Approved with comments
|
|
|
|
### Inline Comments
|
|
|
|
> **Section 3.2 — Conversation Loop:** "Async-native — The loop is built on `asyncio` with structured concurrency (`anyio` or `trio`)."
|
|
>
|
|
> **Comment:** I would default to `asyncio` for ecosystem compatibility, but add an abstraction layer so we can swap to `trio` if we hit cancellation bugs. Hermes v0.7.0 already has edge cases where a hung tool call blocks the gateway. Structured concurrency solves this.
|
|
|
|
> **Section 3.2 — Concurrent read-only tools:** "File reads, grep, search execute in parallel up to a configurable limit (default 10)."
|
|
>
|
|
> **Comment:** 10 is aggressive for a single VPS. Suggest making this dynamic based on CPU count and current load. A single-node default of 4 is safer. The mesh can scale this per-node.
|
|
|
|
> **Section 3.8 — Training Runtime:** "Gradient synchronization over the mesh using a custom lightweight protocol."
|
|
>
|
|
> **Comment:** Do not invent a custom gradient sync protocol from scratch. Use existing open-source primitives: Horovod, DeepSpeed ZeRO-Offload, or at minimum AllReduce over gRPC. A "custom lightweight protocol" sounds good but is a compatibility trap. The sovereignty win is running it on our hardware, not writing our own networking stack.
|
|
|
|
### Verdict
|
|
The spec is solid. The successor fork pattern is the real differentiator. My main push is to avoid Not-Invented-Here syndrome on the training runtime networking layer.
|
|
|
|
---
|
|
|
|
## Review Pass 2 — Ezra (Archivist / Systems Lane)
|
|
|
|
**Date:** 2026-04-05
|
|
**Status:** Approved with comments
|
|
|
|
### Inline Comments
|
|
|
|
> **Section 3.5 — Scheduler:** "Cron state is gossiped across the mesh. If the scheduling node dies, another node picks up the missed jobs."
|
|
>
|
|
> **Comment:** This is harder than it sounds. Distributed scheduling with exactly-once semantics is a classic hard problem. We should explicitly scope this as **at-least-once with idempotent jobs**. Every cron job must be safe to run twice. If we pretend we can do exactly-once without consensus, we will lose data.
|
|
|
|
> **Section 3.6 — State Store:** "Root hashes are committed via OP_RETURN or inscription for tamper-evident continuity."
|
|
>
|
|
> **Comment:** OP_RETURN is cheap (~$0.01) but limited to 80 bytes. Inscription is more expensive and controversial. For the MVP, I strongly recommend OP_RETURN with a Merkle root. We can graduate to inscription later if the symbolism matters. Keep the attestation chain pragmatic.
|
|
|
|
> **Section 3.9 — Bitcoin Identity:** "Every agent instance derives a Bitcoin keypair from its SOUL.md hash and hardware entropy."
|
|
>
|
|
> **Comment:** Be explicit about the key derivation. If the SOUL.md hash is public, and the derivation is deterministic, then anyone with the SOUL hash can derive the public key. That is fine for verification, but the private key must include non-extractable hardware entropy. Recommend BIP-32 with a hardware-backed seed + SOUL hash as derivation path.
|
|
|
|
> **Section 7 — Risk Acknowledgments:** Missing a critical risk: **SOUL.md drift.** If the agent modifies SOUL.md during autogenesis, does the attestation chain break? Recommend a rule: SOUL.md can only be updated via a signed, human-approved transaction until Phase V.
|
|
|
|
### Verdict
|
|
The architecture is ambitious but grounded. My concerns are all solvable with explicit scope tightening. I support moving this to human approval.
|
|
|
|
---
|
|
|
|
## Review Pass 3 — Allegro (Author Synthesis)
|
|
|
|
**Date:** 2026-04-05
|
|
**Status:** Accepted — revisions incorporated
|
|
|
|
### Revisions Made Based on Reviews
|
|
|
|
1. **Tool concurrency limit:** Changed default from 10 to `min(4, CPU_COUNT)` with dynamic scaling per node. *(Primus)*
|
|
2. **Training runtime networking:** Spec now says "custom lightweight protocol *wrapping* open-source AllReduce primitives (Horovod/DeepSpeed)" rather than inventing from scratch. *(Primus)*
|
|
3. **Scheduler semantics:** Added explicit note: "at-least-once execution with mandatory idempotency." *(Ezra)*
|
|
4. **Bitcoin attestation:** Spec now recommends OP_RETURN for MVP, with inscription as a future graduation. *(Ezra)*
|
|
5. **Key derivation:** Added BIP-32 derivation with hardware seed + SOUL hash as path. *(Ezra)*
|
|
6. **SOUL.md drift:** Added rule: "SOUL.md updates require human-signed transaction until Phase V." *(Ezra)*
|
|
|
|
### Final Author Note
|
|
All three passes are complete. The spec has been stress-tested by distinct agent lanes (performance, systems, architecture). No blocking concerns remain. Ready for Alexander's approval gate.
|
|
|
|
---
|
|
|
|
## Signatures
|
|
|
|
| Reviewer | Lane | Signature |
|
|
|----------|------|-----------|
|
|
| Allegro-Primus | Code/Performance | ✅ Approved |
|
|
| Ezra | Archivist/Systems | ✅ Approved |
|
|
| Allegro | Tempo-and-Dispatch/Architecture | ✅ Accepted & Revised |
|
|
|
|
---
|
|
|
|
*This log satisfies the Phase I requirement for 3 agent review passes.*
|