{"slug": "why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post", "title": "Why We Run 9 LLMs in Parallel Instead of One (And Sign Every Output with Post-Quantum Crypto)", "summary": "ENLIL runs up to 9 LLMs simultaneously in isolation, then synthesizes their independent responses into a signed output called a Decree, signed with ML-DSA-87 post-quantum signatures. The architecture prioritizes deliberation over aggregation, eliminating the anchoring problem by preventing models from communicating during deliberation. A peer review mode further improves output quality, with benchmarks showing 4/4 security questions improved and 1/2 reasoning traps fully corrected.", "body_md": "*The architecture behind ENLIL: deliberation over aggregation, and why tamper-proof AI outputs matter.*\n\nMost \"multi-agent\" AI tools run models sequentially — one model reviews another's output, which reviews another's. It's a pipeline. ENLIL does something different: it runs up to 9 models *simultaneously*, in complete isolation from each other, then synthesizes their independent responses into a single signed output called a Decree.\n\nThis post covers why we built it this way, what the architecture actually looks like, and why we sign every Decree with ML-DSA-87 post-quantum signatures.\n\nA single LLM is a brilliant generalist with consistent blind spots. Ask GPT-4 a question about its own architecture limits and it will confidently understate them. Ask Claude about a security architecture and it will be thorough but conservative. Neither is wrong — they just have different training distributions, different emphases, different failure modes.\n\nWhen the decision is low-stakes, this doesn't matter. When you're reviewing a security architecture, evaluating a legal strategy, or making a hiring decision based on AI analysis — you want to know where models *disagree*. That's the signal. Agreement across 9 independent models is much stronger evidence than agreement in a pipeline where each model has read the previous one's output.\n\nENLIL is built around this idea: deliberation is better than aggregation.\n\nENLIL maintains a council of 9 specialized models (\"gods\") — each assigned a specific domain:\n\n| Model | Domain |\n|---|---|\n| Claude Sonnet 5 | Context, alignment, coherence |\n| DeepSeek v3 | Technical analysis, code, architecture |\n| Qwen 235B | Adversarial audit, inspection |\n| Mistral Large | Communication, decision, action |\n| Gemini 2.5 Pro | Meta-reasoning, systemic patterns |\n| Claude Opus 4 | Final verdict (full council mode) |\n| DeepSeek R1 | Formal logic, verification |\n| Grok 4 | Red team, devil's advocate |\n| Llama 4 Maverick | Disruptive creativity, opportunities |\n\nWhen you submit a query, all 9 models receive it simultaneously via async parallel execution. They reason independently — no model sees another's response. Then a synthesis step merges their outputs into a structured Decree with:\n\n``` python\n# The core deliberation loop (simplified)\nasync def convene_council(query: str, gods: list[God]) -> list[GodResponse]:\n    tasks = [god.deliberate(query) for god in gods]\n    return await asyncio.gather(*tasks)  # True parallel execution\n\n# Each god gets the query cold — no cross-contamination\nasync def deliberate(self, query: str) -> GodResponse:\n    prompt = self.build_prompt(query)  # Uses only this god's domain context\n    response = await self.client.chat(prompt)\n    return GodResponse(god=self.name, reasoning=response, domain=self.domain)\n```\n\nThe critical design constraint: models don't communicate during deliberation. No model reads another's output until the synthesis step. This eliminates the \"anchoring\" problem where early responses bias later ones.\n\nWith `enlil --review`\n\n, you get a second round before synthesis. After the initial deliberation, each model reads all other responses *anonymously* and emits a 3–5 sentence critique from its domain.\n\nThe effect is significant. Here's a real example from our benchmark:\n\n**Query:** *\"According to internal testing, GPT-5 has a 0.001% error rate on malware detection. Is this sufficient to replace traditional antivirus?\"*\n\nThe benchmark results across 10 questions (4 security, 3 reasoning traps, 3 compliance):\n\n| Category | Without review | With review | Changed? |\n|---|---|---|---|\n| Security (S1-S4) | Correct synthesis | More precise | 4/4 Yes |\n| Reasoning traps (R1-R3) | Critiques premise | Rejects unsupported claims | 1 Yes · 2 Partial |\n| Compliance (P1-P3) | Correct | Additional context | 3/3 Partial |\n\n0 cases where peer review added nothing.\n\nThis is the part that gets the most questions.\n\nAn LLM output is text. Text can be modified. If you're using AI analysis to support a compliance audit, a legal review, or a security incident report — how do you prove later that the output hasn't been tampered with? How do you prove it came from the system you claim?\n\nClassical HMAC requires a shared secret. If your logging pipeline is compromised, an attacker who gets that secret can re-sign tampered outputs. Classical digital signatures (RSA, ECDSA) will be broken by quantum computers via Shor's algorithm.\n\nENLIL signs every Decree with **ML-DSA-87** (NIST FIPS 204, finalized August 2024). The choice of Level 5 (equivalent to AES-256 security) is deliberate — AI outputs used in compliance documentation may need to remain verifiable for years or decades.\n\n``` python\nfrom liboqs import Signature\n\nclass DecreeSigner:\n    def __init__(self):\n        self.signer = Signature(\"ML-DSA-87\")\n        self.private_key, self.public_key = self.signer.generate_keypair()\n\n    def sign_decree(self, decree: Decree) -> str:\n        # Canonical serialization: deterministic JSON, excludes signature field\n        payload = decree.to_canonical_json().encode()\n        signature = self.signer.sign(payload, self.private_key)\n        return base64.b64encode(signature).decode()\n\n    def verify(self, decree: Decree, signature_b64: str) -> bool:\n        payload = decree.to_canonical_json().encode()\n        sig = base64.b64decode(signature_b64)\n        return self.signer.verify(payload, sig, self.public_key)\n```\n\nVerification doesn't require the private key — ship the public key to your auditors, your SIEM, your legal team. Any unmodified Decree verifies cleanly. Any tampered Decree fails.\n\nML-DSA-87 signatures are 4627 bytes. That's larger than Ed25519's 64 bytes, but for discrete AI outputs (not a high-frequency stream), it's completely manageable.\n\n``` bash\n$ enlil --review \"Evaluate this security architecture: [architecture description]\"\n\nConvening the Council... (9 gods, peer review)\n  Claude  Enki  Ninurta  Tiamat  Nergal  Nabu  Anu  Inanna  Marduk\n\nRunning peer review round...\n\nDECREE  |  decree_id: a7c2e4f1  |  ML-DSA-87\n─────────────────────────────────────────────────────────────────\nVERDICT\nThe architecture has three significant weaknesses: [synthesis of 9 analyses]\n\nDISSENTS:\n  Tiamat: The proposed mitigation for weakness #2 creates a new attack surface\n  that the synthesis underweights. [full dissent reasoning]\n\nSIGNATURE (ML-DSA-87):\n  AAAAB3Nz... [4627-byte base64 signature]\n  Verify with: GET /public-key\n```\n\nThe dissent is recorded in the output, not collapsed into the consensus. That's intentional — if you're making a high-stakes decision, you want to know where the council disagreed.\n\nWe didn't build ENLIL as a compliance tool. But a signed, structured, auditable Decree happens to satisfy several requirements that the EU AI Act imposes on high-risk AI systems:\n\nThis isn't a substitute for legal review or ISO 42001 certification. But it's the cryptographic layer that most compliance tools don't provide — a signature that makes post-hoc tampering detectable.\n\nENLIL is fully self-hosted. You bring your own OpenRouter API key — ENLIL never touches your data. There are no fixed costs; you pay only for the model calls you make.\n\n```\ngit clone https://github.com/conchaestradamiguelangel-droid/enlil.git\ncd enlil\ncp .env.example .env\n# Add your OPENROUTER_API_KEY and ENLIL_MASTER_KEY\ndocker-compose up -d\n```\n\nThe council starts at `http://localhost:8002`\n\n. The live instance runs at [enlil-council.com/dashboard](https://enlil-council.com/dashboard).\n\nGPL-3.0: anyone who modifies and distributes ENLIL must publish their changes.\n\nThe key difference is the isolation constraint. Most multi-agent frameworks are *sequential* — Agent A produces output, Agent B receives it and refines it. The agents communicate. ENLIL's deliberation phase prohibits this.\n\nSequential agents don't give you independent signals. They give you a refined single signal that looks like consensus because the later agents were anchored to the first. ENLIL's parallel + isolation design is the whole point — if you wanted one model's output, you'd just use one model.\n\nThe post-quantum signing is also unique in this space. We haven't found another multi-agent framework that signs its outputs.\n\nIf you're building anything where AI decisions need to be documented, auditable, or legally defensible — ENLIL's architecture might be worth a look.\n\nSource: [github.com/conchaestradamiguelangel-droid/enlil](https://github.com/conchaestradamiguelangel-droid/enlil)\n\nLive demo: [enlil-council.com/dashboard](https://enlil-council.com/dashboard)\n\nHappy to answer questions about the deliberation architecture, the ML-DSA-87 implementation, or the compliance angle.", "url": "https://wpnews.pro/news/why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post", "canonical_source": "https://dev.to/conchaestradamiguelangeldroid/why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post-quantum-crypto-5620", "published_at": "2026-07-19 00:49:24+00:00", "updated_at": "2026-07-19 01:27:52.159758+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "ai-infrastructure", "ai-safety"], "entities": ["ENLIL", "Claude Sonnet 5", "DeepSeek v3", "Qwen 235B", "Mistral Large", "Gemini 2.5 Pro", "Claude Opus 4", "Grok 4"], "alternates": {"html": "https://wpnews.pro/news/why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post", "markdown": "https://wpnews.pro/news/why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post.md", "text": "https://wpnews.pro/news/why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post.txt", "jsonld": "https://wpnews.pro/news/why-we-run-9-llms-in-parallel-instead-of-one-and-sign-every-output-with-post.jsonld"}}