CruxAI

An AI litigation engine where opposing autonomous agents debate, verify, and resolve complex claims in real-time. Built on ultra-fast Cerebras inference, the system features a dynamic tribunal—complete with prosecution, defense, an impartial registrar, and a presiding judge rendering final verdicts.

🛑 The Problem: The Single-Perspective Echo Chamber

When users ask standard LLMs about complex, controversial, or multifaceted issues, they typically receive a single, homogenized response. This is problematic because:

1. Bias & Hallucination: A single model can hallucinate facts or lean into inherent biases without any internal pushback.
2. Lack of Nuance: Complex societal, technical, or legal issues rarely have binary "yes or no" answers. They require weighing opposing tradeoffs.
3. Passive Consumption: Users passively consume what the AI outputs, rather than seeing how an argument holds up to scrutiny.

To find the truth in the real world, human systems rely on the adversarial process (like a court of law), where ideas are aggressively stress-tested from opposing angles before a conclusion is drawn.

⚖️ The Solution: CruxAI

CruxAI solves this by bringing the legal tribunal to AI. Instead of asking one model for an answer, a user's claim is forced through a high-speed multi-agent adversarial crucible:

• The Advocate aggressively prosecutes and builds the case.
• The Devil's Advocate violently stress-tests the logic and attacks vulnerabilities.
• The Fact-Checker acts as an impartial registry, fact-checking both sides with cold data.
• The Synthesizer (Judge) watches the entire bloodbath, weighs the surviving merits, and delivers a highly nuanced, battle-tested verdict.

Because this requires generating massive amounts of text across four agents, the system relies on the Cerebras LPU to execute the debate at ultra-high speeds, streaming the conflict to the user in real-time.

---

⚙️ System Architecture

graph TD
    User(["User"]) -->|"Submits Claim / Topic"| UI["CruxAI Frontend"]
    UI -->|"POST /debate"| API["FastAPI Backend"]
    
    subgraph Engine ["Multi-Agent Crucible Engine"]
        API -->|"Initializes Transcript"| Orchestrator{"Turn-Based Orchestrator"}
        
        Orchestrator -->|"Injects Context & History"| Advocate["Advocate (Prosecution)"]
        Orchestrator -->|"Injects Context & History"| DevilsAdvocate["Devil's Advocate (Defense)"]
        Orchestrator -->|"Injects Context & History"| FactChecker["Fact-Checker (Impartial Registry)"]
        
        Advocate -->|"Updates Transcript"| Orchestrator
        DevilsAdvocate -->|"Updates Transcript"| Orchestrator
        FactChecker -->|"Updates Transcript"| Orchestrator
    end
    
    Orchestrator ===>|"Debate Concludes"| Judge["Synthesizer (Presiding Judge)"]
    
    Advocate -.->|"Streams Tokens (Cerebras)"| SSE["Server-Sent Events (SSE)"]
    DevilsAdvocate -.->|"Streams Tokens (Cerebras)"| SSE
    FactChecker -.->|"Streams Tokens (Cerebras)"| SSE
    Judge -.->|"Streams Final Verdict"| SSE
    
    SSE ===>|"Real-Time Chunk Delivery"| Client["Client Application"]
    
    subgraph Render ["Real-Time UI Rendering"]
        Client -->|"Calculates tok/sec"| SpeedBadge["Live Telemetry Badge"]
        Client -->|"Reactive Pacing"| Typewriter["Typewriter Audio Engine"]
        Client -->|"Displays Ruling"| Broadsheet["Aged-Parchment UI"]
    end

Loading

How the Flow Works:

1. Ingestion: The user submits a controversial claim to the Next.js frontend, which is sent to the FastAPI backend.
2. Context Injection: The backend orchestrator analyzes the previous turns and generates unique "emotional/strategic context" for the next agent (e.g., telling the Advocate, "The Devil's Advocate just attacked your logic, push back hard").
3. The Crucible: The agents iterate through a 3-round turn-order. Because Cerebras is generating tokens instantly, the backend immediately yields these tokens to the frontend via an SSE stream.
4. Resolution: Once the debate rounds finish, the entire transcript is fed to the Judge, who synthesizes the arguments into a final ruling.
5. Client Rendering: The frontend catches the streaming chunks and calculates live speed metrics (tokens per second) while pacing the text out visually in the legal broadsheet UI.