Five independent debates, one shorter wait.

I did not build this system. I read it, quickly.

Big4 is a team hackathon project: a multi-agent negotiation system that runs structured adversarial debates and ranks the outcomes. I came into an existing codebase with the demo already on the calendar.

• 13 agents across 4 layers
• 10 rounds of adversarial debate
• LangGraph orchestration: StateGraph, Send, subgraphs
• Claude Haiku for the agent calls
• FastAPI backend, Next.js frontend
• Scoring and ranking at the output stage

Five debates were waiting in line for no reason.

Mapping the execution path, the sandbox negotiation stage ran its debates one after another. Nothing in the design required that: no debate consumed another debate’s intermediate output, and the ranking step only needed all five results, not a particular order of arrival.

So the serial order was not semantics; it was just how the stage happened to be written. I moved the debates onto a fan-out, and let the graph join on their results.

The work did not shrink; the same five debates still run, and the same tokens are still spent. What changed is that four of them stopped waiting for a turn they never needed.

Parallelism is not free speed.

It moved cost around rather than removing it. In a hackathon that trade was clearly worth making; in production I would want the answers to these before shipping it.

• Five concurrent debates means five times the instantaneous inference demand; rate limits become a real failure mode rather than a theoretical one.
• Errors stop being sequential. One debate failing mid-flight has to be aggregated and handled at the join instead of simply stopping the chain.
• Partial results need a policy: does the join wait, degrade, or fail? Serial execution never had to answer that.
• Streaming output to the UI loses its natural ordering, because results no longer arrive in the order a reader expects.

Performance often improves when you stop staring at individual functions and look at the execution graph.

The change itself was small. The useful part was being able to read an unfamiliar orchestration fast enough to see the shape of it, and being confident enough about independence to change the execution model before a demo.