Thesis Arena

Turn any claim into a multi-agent stress test that exposes weak logic, missing evidence, and stronger arguments.

Comment

Inspiration

Thesis Arena grew out of an educational experiment I ran about a year ago.

I organized a small remote workshop where people learned to build AI agents with n8n. The participants arrived with different ideas: one wanted to create a scientific fact checker, while others were interested in debate, education, or multi-agent automation. I needed a shared project that would let the group explore as much of the stack as possible.

We built a discussion trainer that worked through Telegram. At first, it was one primary agent that could switch between several modes: it could challenge a position, strengthen it, examine its logic, or act as a debate coach. It also had a separate Fact Checker subagent for externally verifiable claims. Later, we added text-to-speech as an educational extra.

As a workshop project, it worked well. It exposed participants to agent roles, tool calls, orchestration, structured outputs, external research, and conversational interfaces.

As a product, however, it had two important limitations.

The first was architectural. One agent deciding which analytical mode to use is convenient, but it mixes several different reasoning objectives inside the same context. After using the trainer, I became convinced that the roles should be separated. A Red Team should consistently search for vulnerabilities. A Steelman should independently build the strongest possible case. A Logic agent should examine inference rather than persuasion. A Fact Checker should work only with externally verifiable claims. A higher-level Synthesizer could then compare their outputs instead of asking one agent to imitate every perspective.

The second limitation was presentation. In Telegram, the result was still mostly a long stream of text. Someone who already understood debate methodology or agent architecture could see its value. Someone outside that context usually could not. The system was useful as a training environment, but it was not something I could easily show to another person and immediately communicate why it mattered.

A later post by Andrej Karpathy helped me articulate this interface problem. He described a progression from raw text to Markdown and then to HTML: visual structure, layout, and interaction can use the human visual channel far more effectively than another wall of generated prose.

That observation fit the discussion trainer perfectly. The analytical content was already there, but it needed a human-readable visual layer. Separate panels, headings, severity markers, claim references, expandable findings, and semantic colors could make the same reasoning much easier to navigate.

Another influence was Moltbook, the Reddit-like environment where software agents appeared to interact through a format already familiar to a broad audience. The important lesson for me was not that every agent system should become a social network. It was that a familiar visual metaphor could make invisible multi-agent behavior understandable even to people who did not know how the underlying technology worked.

My initial idea was therefore closer to an analytical Reddit thread: a user would submit a thesis and see several AI participants respond from different positions. During product discussions with ChatGPT and Codex, that concept evolved. Instead of presenting the agents as entertainment or simulated personalities, Thesis Arena became a professional reasoning instrument: a structured pipeline that decomposes an argument, examines it through independent analytical lenses, and reconstructs it into a stronger thesis.

I chose n8n as the orchestration layer because it reflects the same human-interface principle. A conventional backend can execute the pipeline, but only an experienced developer can immediately reconstruct all of its states and relationships from code. In n8n, the same system exists as executable logic and as a visual diagram: nodes, branches, inputs, outputs, executions, and failures can be inspected directly.

Working with Codex reinforced that choice. The n8n graph became a shared representation of the system that both of us could reason about. I could inspect executions visually, while Codex could work with the workflow definitions, PostgreSQL records, and API contracts. It functioned as a practical interface between human reasoning and machine implementation.

OpenAI Build Week finally gave me a reason to combine these ideas into a complete product.

What it does

Thesis Arena is a multi-agent argument stress-testing instrument.

A user enters a debatable claim. The system then:

  1. decomposes it into distinct empirical, causal, interpretive, predictive, and value claims;
  2. examines the resulting Claim Map through four independent analytical lenses;
  3. displays each completed report progressively;
  4. synthesizes the findings into a key crux and an improved thesis;
  5. exports the entire analysis as a structured, print-ready PDF.

The four visible lenses have deliberately different responsibilities:

  • Red Team searches for hidden assumptions, counterexamples, omitted alternatives, and failure modes;
  • Steelman reconstructs the strongest defensible version of the argument;
  • Logic examines causal links, contradictions, quantifiers, and inferential gaps;
  • Fact Check separates externally verifiable claims from opinions and returns evidence findings with source links.

The final Synthesizer does not simply average their opinions. It identifies what survived, what failed, which assumptions remain unresolved, and the single key crux on which the conclusion most strongly depends.

The purpose is not to make an AI win a debate. It is to show a person what their argument actually relies on, what evidence is missing, and what could reasonably change their mind.

How I built it

ChatGPT was the working environment for the product and methodology layer. I used it to:

  • reconstruct the lessons of the original discussion trainer;
  • define the strict MVP boundary;
  • adapt Toulmin-style claim analysis and double-crux reasoning;
  • separate the analytical roles;
  • design the canonical JSON contract;
  • develop the positioning, brand language, and visual direction;
  • review implementation results and prioritize changes.

Codex handled the implementation and production loop inside the real project workspace. It built:

  • the dependency-free frontend;
  • the progressive application states;
  • expandable full reports;
  • the dedicated A4 report renderer;
  • the n8n workflow generators;
  • PostgreSQL persistence and account quotas;
  • status and saved-execution retry workflows;
  • Nginx authentication and rate limits;
  • deployment, debugging, and production verification.

The live analytical layer uses six GPT-5.6 Luna model nodes:

  • Claim Mapper;
  • Red Team;
  • Steelman;
  • Logic;
  • Fact Check with online source research;
  • Synthesizer.

OpenRouter is used as the model transport layer. n8n orchestrates the pipeline and records execution history, while PostgreSQL stores the request, intermediate checkpoints, completion state, errors, model configuration, and final analysis.

All surfaces use the same structured contract: the live workflow, the frontend, mock data, PostgreSQL records, progressive status responses, and the PDF report.

Challenges

The first production version waited for the complete n8n workflow inside one HTTP request. The analysis itself completed, but the reverse proxy returned a 524 timeout before the final response reached the browser.

I replaced the blocking request with an asynchronous architecture. The start workflow now acknowledges the request immediately and returns an execution ID. The frontend polls a lightweight status workflow while n8n and PostgreSQL preserve intermediate checkpoints.

This also made progressive delivery possible. Users can begin reading the Claim Map or Red Team report while later lenses are still running.

Progressive rendering introduced another problem: when a new artifact arrived, the interface rerendered and closed the Full Report the user was reading. The final implementation preserves the selected report and reading state while new modules appear.

PDF export required its own approach. Instead of turning the screen into an image, Thesis Arena generates a dedicated A4 HTML document with native text, controlled page breaks, active source links, and print-specific styling.

Finally, each real analysis has a model cost. The deployed version therefore uses authentication, per-account quotas, request limits, and an atomic PostgreSQL check before any paid model node begins.

Accomplishments

I am especially proud that the result is not a static multi-agent mockup or four prompts displayed next to each other.

The finished MVP includes:

  • a protected working production deployment;
  • six specialized GPT-5.6 analytical stages;
  • real progressive delivery;
  • full structured reports rather than decorative summaries;
  • cited online evidence;
  • durable PostgreSQL execution records;
  • checkpoint-based retry behavior;
  • a shared validated data contract;
  • a complete PDF artifact the user can keep;
  • a public, licensed, reproducible repository.

The interface also solves the communication problem of the original Telegram trainer. A person no longer needs to understand n8n, prompts, subagents, or debate methodology before seeing what the system is doing.

What I learned

The main lesson was that multi-agent systems become valuable only when their agents have genuinely different responsibilities and exchange structured artifacts.

Multiple personalities are not enough. The separation has to exist in the methodology, prompts, schemas, and synthesis.

I also learned that presentation is part of the reasoning process. Claim cards, semantic tags, severity markers, visual hierarchy, and expandable reports do not merely make the output look better. They help the user understand relationships that are difficult to recover from linear text.

Progressive delivery turned out to be more than loading polish. It transformed a long wait into useful reading time.

Finally, this project confirmed the value of visual orchestration. n8n made the backend inspectable to a human, while the HTML interface made the agents’ reasoning inspectable to the end user. Both layers solve a similar problem at different levels of the system.

What's next

Thesis Arena currently works as a recursive but mostly one-directional process: the user submits a thesis, receives a structured analysis, improves the thesis, and can send the new version through another round. That loop is already useful, but it does not yet create a real dialogue.

The next major step is to make the arena stateful and interactive. Users should be able to challenge a finding, dispute a source, clarify what they meant, introduce new evidence, or explain why an assumption does not apply. Instead of rerunning the entire analysis from the beginning, the relevant agents could respond to that intervention, reconsider the affected findings, and update the synthesis.

The Key Crux is a natural starting point for this dialogue. The system could turn it into a sequence of Socratic questions: What evidence would change your mind? Which assumption is indispensable to your conclusion? What would count as a decisive counterexample? This would transform Thesis Arena from a report generator into an active reasoning and debate coach.

I would also like to expand its methodological foundation. The current system already draws on Toulmin argument analysis and double-crux reasoning, but future versions could incorporate deeper Socratic questioning, Aristotelian logic and rhetoric, counterfactual testing, and additional debate techniques. Different training modes could focus on building arguments, defending them under pressure, evaluating evidence, or recognizing recurring reasoning errors.

Eventually, this could become a personalized trainer that remembers how a user reasons over time: which assumptions they frequently leave implicit, which fallacies recur, how they respond to counterarguments, and whether their revised positions become more precise and defensible.

A realtime voice layer using OpenAI’s realtime models could turn the same multi-agent architecture into a live conversational partner. Instead of reading a finished report, the user could defend a thesis aloud, receive targeted questions, respond to objections, and watch the claim map and synthesis evolve during the conversation.

The long-term vision is not merely a system that judges an argument. It is a system that helps people practice the process of thinking, defending, questioning, and revising ideas.

For Build Week, I deliberately kept the scope focused on one complete experience: one thesis, one structured stress test, and one useful report.

Built With

Share this project:

Updates