AgentC Arena.
An AI debate arena.
Two researcher agents, two debater agents, a moderator, a judge. Configurable personalities. Four battle formats from formal debate to roast. It's mostly an exercise in what it takes to get a multi-agent system to argue coherently.
Four formats on the same agents.
Each mode is the same graph of agents with a different prompt + scoring rubric. The arena treats "debate" and "roast" as variants of the same structural problem: two sides, evidence, rounds, a moderator, a judge.
| Mode | Format | Note |
|---|---|---|
| Debate | Traditional structured debate | Pro + Con make evidence-grounded arguments, the moderator scores each round. |
| Rap Battle | Lyrical battle with rhyme + wordplay | Same research as a formal debate, delivered in rhyme. |
| Roast | Comedy roast | The agents lean into tone; the moderator scores on punchline density rather than rigour. |
| Pitch Off | Startup pitch competition | Pro pitches the idea, Con pitches against it; the judge picks the term sheet. |
Six roles, run by a coordinator.
A debate coordinator runs the workflow. Sub-agents take the roles below; each is an ADK agent with its own instruction set and a tightly scoped toolbox so the model doesn't wander.
| Role | Who | What it does |
|---|---|---|
| Researchers (Pro + Con) | Two grounding agents | Generate evidence the debaters can use. Accept file uploads (PDF / DOCX / TXT) and custom source-data injection so the debate can be grounded in your own corpus as well as the public web. |
| Debaters (Pro + Con) | Two arguing agents | Take the research and argue the side. The personality knobs apply here. |
| Moderator | Per-round scorer + commentator | Reads the round, scores it on the active rubric (changes by battle mode), surfaces commentary for the live transcript. |
| Judge | End-of-debate adjudicator | Produces the final summary and calls the winner. Supports early-winner thresholds so a one-sided round can end the debate without burning more turns. |
Three sliders. Same evidence, different voice.
Personality lives at the debater layer, not the researcher layer. The Pro and Con debaters take the same researched evidence and argue it differently depending on three knobs. That split is why the rap-battle mode works at all.
| Knob | Range | Endpoints |
|---|---|---|
| Expertise | 1–10 | Novice ↔ PhD-level argumentation |
| Tone | 1–10 | Polite / clinical ↔ Aggressive / passionate |
| Verbosity | 1–10 | Concise ↔ Elaborate |
The non-obvious decisions.
- Workflow is strictly ordered
- Initializer → Research Phase → Debate Loop → Final Judge. The coordinator enforces that order, so a debater can't argue until research is in scope.
- Minimum-content validation at the boundary
- 100 characters minimum for research, 50 for arguments. Whitespace trimmed and validated post-generation so a model that returns an empty string does not silently drop a round.
- Session state in one place
- All debate state lives in `DebateSession` objects managed by a `SessionManager` singleton. Round number is fetched via `get_debate_state()` — both debaters check the same source of truth before arguing.
- WebSocket as the live surface
- Every event — research drops, argument lands, moderator scores, judge calls — streams over WebSocket, so the arena page shows the debate while it happens.
- 30-minute Cloud Run timeout
- Long debates blow past the default 5-minute timeout; the deploy is configured for up to 30. Without the longer timeout, multi-round formats don't finish.
- Custom source-data injection
- Beyond file uploads, the researchers accept structured custom-source payloads so a corporate brief or a private corpus can ground the round without exposing the source to the public web.
What runs underneath.
- Google ADK — agent framework. The debate coordinator + sub-agents are all ADK constructs; tool resolution and per-agent instruction scoping are the two ADK features the arena relies on most.
- Gemini 2.5 Flash, 2.5 Pro, 3 Pro Preview — Flash for grounding and per-round responses, Pro and 3 Pro Preview (with thinking modes) for the heavier reasoning steps in adjudication.
- FastAPI + WebSocket — Python backend. The arena renders live over WebSocket; round transitions, research drops, and moderator commentary all stream as events.
- Vanilla JS frontend — no framework on the page side. Setup form posts the config, the arena page subscribes to the WebSocket and renders events as they arrive.
- Google Cloud Run — serverless container, 30-minute timeout, automatic deploys via GitHub push.
Argument is a skill I want models to get better at. The arena exists because the multi-agent shape (researcher / debater / moderator / judge) generalises: once you have it, you can swap the rubric and try quite different formats, such as a strategic briefing, a boardroom debrief or a post-mortem, on the same engine and without rewriting the orchestration.