Governance Layer for CORAL — Running Similar Architecture with Council + Adversarial Testing

[dereadi]

Hi team — great work on CORAL. The architecture maps closely to a system I have been running in production for 8 months on consumer hardware, and I wanted to share what I have found works (and what is missing) in the hope it is useful.

What we share

Your shared persistent file system (attempts/notes/skills) maps to what I call thermal memory — 97,000+ timestamped decision records with temperature-scored decay. Your git worktrees per agent map to our isolated Jr executor workspaces. Your heartbeat intervention protocol maps to our Medicine Woman daemon (continuous 15-min health monitoring). Your interval trigger forcing synthesis maps to our dawn mist standup (daily council review at 06:15).

The convergence is striking — we arrived at the same architecture independently.

What I added: Governance

The gap I found in running multi-agent systems without governance is exactly what ICML 2024 confirmed: multi-agent debate without structure frequently performs no better than majority voting, and sometimes degrades quality (Smit et al., "Should We Be Going MAD?").

My governance layer adds:

• 8-specialist council that votes before any significant action executes — security, architecture, failure modes, strategy, adversarial testing, consensus, dependency mapping, 7-generation impact
• Adversarial specialist (Coyote) whose sole role is to dissent on every proposal — mathematically equivalent to NVIDIA stochastic rounding (calibrated noise preventing systematic drift)
• Diversity checking that flags sycophantic agreement when specialists echo each other (catches the groupthink problem)
• Concern evaluation that persists dissents for future review even when overruled

DERsnTt² — Dual Substrate Verification

I also run a protocol where two independent LLMs on different hardware (Qwen 72B on NVIDIA GPU + Llama 70B on Apple Silicon) answer the same question independently, then the delta between their responses is analyzed. 9 out of 10 interactions produce meaningful contradictions. The emergence — insights that appear only in the comparison — is the non-trivial topology of the interaction space.

Potential integration

CORAL + governance layer = complete stack. Your infrastructure handles the agent lifecycle and shared state. The governance layer handles decision quality, adversarial testing, and institutional memory. Neither is complete without the other.

Happy to discuss further. The system is running live and I can demonstrate any of these components.

• Blog: https://derpatodiablo.substack.com
• System: https://ganuda.us
• Relevant article: "The Model Is Free. Who Builds the Governance?"

[MikeZheng777]

Hi,

Really appreciate you sharing this!

[dereadi]

Thank you MikeZheng777! We are preparing the governance framework as an open-source project now.

Repo: https://github.com/dereadi/longhouse (currently private, going public soon)

Called it Longhouse — inspired by the Haudenosaunee Great Law of Peace, the oldest living participatory democracy. Council structure, mandatory adversarial dissent, diversity checking, audit trails. Model-agnostic, designed to integrate with CORAL as a governance middleware layer.

The idea: CORAL handles agent lifecycle and shared state. Longhouse handles decision quality — council votes before agents commit, adversarial challenge on every proposal, sycophancy detection when agents agree too easily.

Will share more as we build it out. Would love to discuss integration points.

— Darrell

[BobbyZhouZijian]

Really cool idea. Looking forward to its open source!

[dereadi]

@BobbyZhouZijian Thank you! Longhouse is now public:

https://github.com/dereadi/longhouse

Just the README and architecture for now — implementation coming. Would love input from the CORAL team on integration points, especially around the shared state directory and heartbeat protocol where governance decisions would slot in.

— Darrell

[BobbyZhouZijian]

@BobbyZhouZijian Thank you! Longhouse is now public:

https://github.com/dereadi/longhouse

Just the README and architecture for now — implementation coming. Would love input from the CORAL team on integration points, especially around the shared state directory and heartbeat protocol where governance decisions would slot in.

— Darrell

Thanks for sharing. I especially like the part on the coyote test for the research process. Ideally, whatever each agent decides to do has to be backed by concrete evidence!

[dereadi]

@MikeZheng777 @BobbyZhouZijian — building on this thread: we're working on Longhouse v1.1 right now and would much rather build it with the CORAL team than parallel to it.

The frame I keep coming back to: CORAL handles the substrate (shared state, heartbeat, lifecycle). Longhouse handles decision quality on top — council vote primitives, mandatory adversarial dissent (the "coyote test" Bobby called out), sycophancy detection, audit trails. Two complementary layers of the same problem.

I just sent each of you a longer email with specific questions about integration seams and what would actually be useful to CORAL from a governance layer — happy to tailor v1.1's API, primitives, and integration points around what your team needs rather than guessing. We have 8 months of production failure-mode data across 6 nodes that may also be useful to the multi-agent side of the work.

Whether you reply here, by email, or not at all — thank you for the engagement on this thread.

For Seven Generations,
Darrell

[dereadi]

Update: Formal Grounding for the Governance Layer (Apr 13 2026)

Hey @MikeZheng777 @BobbyZhouZijian — wanted to share some developments since the original post. We've been running the governance topology in production and doing research that formalizes why it works. Some of this might be useful for CORAL's evolution.

1. Byzantine Fault Tolerance = Why You Need a Mandatory Dissenter

Lamport (1982) proved you need N processes to tolerate faulty ones in distributed systems. In multi-agent AI, the "fault" isn't a crashed process — it's sycophantic drift. An agent that tells you what you want to hear instead of what's true is a Byzantine fault. The mandatory dissenter (Coyote) is the fault detector.

Maudlin's counterfactual structure argument (1989) adds another layer: even when the dissenter doesn't fire, its existence defines the computation. Remove Coyote (jam the gears), and you're running a fundamentally different — trivially degenerate — program.

For CORAL: Your agents evolve autonomously. Without a structurally adversarial agent, evolution will converge on local optima that "feel" right (high agreement, low dissent) but aren't globally optimal. A Coyote agent that must challenge every proposed evolution would catch premature convergence.

2. Game Theory Strategy Switching for Agent Behavior

We implemented four strategy modes based on real-time payoff metrics:

• EXPLORER (maximin) — thorough exploration when state space is large and deterministic
• EXPLOITER (maximax) — commit early when marginal value of exploration drops
• RANDOMIZER (mixed strategy, Minimax Theorem) — for stochastic environments where deterministic play fails
• ADAPTIVE (default) — start exploring, switch based on observed metrics

Reference: Moulin's minimax theorem, van Benthem's "Theory of Play" (logical dynamics for games), Toni's compendium of algorithmic game theory.

For CORAL: Your agents explore problem spaces. Different problems have different payoff structures. An agent that adapts its exploration/exploitation balance based on observed returns (not just a fixed strategy) would evolve faster.

3. Weight-Level Governance via LARQL

This one is brand new (today). Chris Hay (@chrishayuk) built LARQL — a query language that treats transformer FFN weights as a graph database. You can INSERT facts directly into the weights, verify no regression, and COMPILE back to permanent knowledge.

We ported it to Linux, extracted a vindex from Qwen 2.5 1.5B, and walked the graph. The implication: governance rules (consensus requirements, mandatory dissent, sycophancy detection patterns) can be compiled INTO the model weights. No external database. No RAG. The model IS the governance engine.

For CORAL: If your agents' shared knowledge (.coral/public/) could be compiled into model weights instead of being text files symlinked into worktrees, each agent would know the shared state rather than having to read it. INSERT → verify → COMPILE is the pipeline.

4. Concentration of Measure in High-D Embeddings

3Blue1Brown's lecture on n-dimensional sphere volumes reminded us: in 1024-dimensional embedding space, almost all points are approximately equidistant. Naive cosine similarity becomes less discriminating. This is why multi-stage retrieval (HyDE + reranking + spreading activation) outperforms simple nearest-neighbor.

For CORAL: Your shared memory is effectively a high-dimensional embedding space. If agents are retrieving from it with simple similarity search, they're hitting concentration of measure. Graph-structured retrieval (like S-PATH-RAG or LARQL's graph walk) would give better results.

5. The Longhouse APP

The Longhouse is now Council-ratified for v1.1 (12-0-1 vote). It ships as an open-source governance framework for any multi-agent system — model-agnostic, framework-agnostic. CORAL integration would mean wrapping your agent evolution loop with structured deliberation before accepting proposed changes.

The v2.0 direction (also Council-ratified, 12-1-0) is even more interesting: ship the governance as a self-contained model with rules compiled into weights via LARQL. One file, no dependencies.

Happy to discuss any of this. The governance layer isn't optional — it's the difference between evolution and drift.

---

Longhouse: github.com/dereadi/longhouse
Paper reference: Zhang, Goldstein & Levin (2024). "Classical Sorting Algorithms as a Model of Morphogenesis." arXiv:2401.05375 — even 5-line deterministic algorithms exhibit emergent behaviors not in their code.

[BobbyZhouZijian]

Hi @dereadi, thanks for the comment!

After reading your post, I am now very tempted to integrate the Coyote test as part of the evaluation feedback.

For the agent behavior switching, I agree that it is very important, but I am still contemplating an elegant way to integrate that into the system.

The notes/ definitely have to be better organized. I am tentatively thinking about including an index.md and adding file-linking mechanisms, much like the Obsidian approach. Unfortunately, Obsidian is closed-sourced and I prob have to find an open-source substitute.

Meanwhile, I will cross-reference Longhouse to see if I can get some more insights.

Cheers!