Why We Run 9 LLMs in Parallel Instead of One (And Sign Every Output with Post-Quantum Crypto)

The architecture behind ENLIL: deliberation over aggregation, and why tamper-proof AI outputs matter.

Most "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.

This 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.

A 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.

When 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.

ENLIL is built around this idea: deliberation is better than aggregation.

ENLIL maintains a council of 9 specialized models ("gods") — each assigned a specific domain:

When 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:

async def convene_council(query: str, gods: list[God]) -> list[GodResponse]:
    tasks = [god.deliberate(query) for god in gods]
    return await asyncio.gather(*tasks)  # True parallel execution

async def deliberate(self, query: str) -> GodResponse:
    prompt = self.build_prompt(query)  # Uses only this god's domain context
    response = await self.client.chat(prompt)
    return GodResponse(god=self.name, reasoning=response, domain=self.domain)

The 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.

With enlil --review

, 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.

The effect is significant. Here's a real example from our benchmark:

Query: "According to internal testing, GPT-5 has a 0.001% error rate on malware detection. Is this sufficient to replace traditional antivirus?"

The benchmark results across 10 questions (4 security, 3 reasoning traps, 3 compliance):

0 cases where peer review added nothing.

This is the part that gets the most questions.

An 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?

Classical 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.

ENLIL 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.

from liboqs import Signature

class DecreeSigner:
    def __init__(self):
        self.signer = Signature("ML-DSA-87")
        self.private_key, self.public_key = self.signer.generate_keypair()

    def sign_decree(self, decree: Decree) -> str:
        payload = decree.to_canonical_json().encode()
        signature = self.signer.sign(payload, self.private_key)
        return base64.b64encode(signature).decode()

    def verify(self, decree: Decree, signature_b64: str) -> bool:
        payload = decree.to_canonical_json().encode()
        sig = base64.b64decode(signature_b64)
        return self.signer.verify(payload, sig, self.public_key)

Verification 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.

ML-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.

$ enlil --review "Evaluate this security architecture: [architecture description]"

Convening the Council... (9 gods, peer review)
  Claude  Enki  Ninurta  Tiamat  Nergal  Nabu  Anu  Inanna  Marduk

Running peer review round...

DECREE  |  decree_id: a7c2e4f1  |  ML-DSA-87
─────────────────────────────────────────────────────────────────
VERDICT
The architecture has three significant weaknesses: [synthesis of 9 analyses]

DISSENTS:
  Tiamat: The proposed mitigation for weakness #2 creates a new attack surface
  that the synthesis underweights. [full dissent reasoning]

SIGNATURE (ML-DSA-87):
  AAAAB3Nz... [4627-byte base64 signature]
  Verify with: GET /public-key

The 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.

We 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:

This 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.

ENLIL 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.

git clone https://github.com/conchaestradamiguelangel-droid/enlil.git
cd enlil
cp .env.example .env
docker-compose up -d

The council starts at http://localhost:8002

. The live instance runs at enlil-council.com/dashboard.

GPL-3.0: anyone who modifies and distributes ENLIL must publish their changes.

The 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.

Sequential 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.

The post-quantum signing is also unique in this space. We haven't found another multi-agent framework that signs its outputs.

If you're building anything where AI decisions need to be documented, auditable, or legally defensible — ENLIL's architecture might be worth a look.

Source: github.com/conchaestradamiguelangel-droid/enlil

Live demo: enlil-council.com/dashboard

Happy to answer questions about the deliberation architecture, the ML-DSA-87 implementation, or the compliance angle.