Technical Blog - Tuesday 28 July

A/B testing a plenary debate in the Dutch Parliament with multi-agent AI

By Jeroen Nelen

The Netherlands is facing several major challenges, including climate change, the housing crisis, and grid congestion. Addressing them requires long-term decisions, but the Dutch political system often struggles to take effective actions – contributing to historically low levels of trust in the Dutch parliament.

Independent think-tank Denkwerk investigated why decision-making falls short, drawing on interviews with domain experts. Its final report, called “Democracy in Revision”, proposes a set of systemic reforms to help parliament address complex, long-term challenges more effectively. These reforms range from introducing an electoral threshold to removing the Senate altogether

A significant difficulty is that the effects of such reforms cannot easily be tested in advance. This is why KickstartAI built a multi-agent digital twin of the House of Representatives (the Dutch Parliament). The model makes it possible to simulate parliamentary debates under different reforms and assess how they could affect the quality and efficiency of plenary debate.

Question, goal & approach

The primary question was: Can we simulate debates using multi-agent LLMs to test the impact of the reforms on the efficiency of the House of Representatives? 

Our objective was threefold:

  1. Understand how the reforms impact debate quality and policy outcomes.

  2. Observe the differences between human debates and AI debates. 

  3. Showcase the possibilities using AI for simulating solutions with multi-agent LLMs

By running these simulations, the aim is to provide an additional layer to the report with proof-points on which types of reforms have the most beneficial results for the debate.

The final simulation environment contains 15 LLM-backed party agents, alongside a chairperson and a minister. These agents can execute distinct tasks, such as holding speeches, interrupting, filing motions, and voting on bills. 

The four-step approach to get results

Let's break down how we architected this pipeline. Firstly, we split the project into four distinct phases of development:

  1. Making the debate functional (orchestrating turns and state)

  2. Making the pipeline traceable (observability and debugging)

  3. Making the simulation realistic (context injection and RAG)

  4. Making it useful (A/B testing policy reforms)

Step 1: Making the debate functional using LangGraph

Our first focus was making the baseline functional. Plenary debates follow a very clear structure, with fixed rounds and speaking orders. This enabled us to model the debate as a complex, deterministic state machine. Real-world debate structures vary based on content, but we scoped this digital clone to specifically handle draft laws and final bill voting.

We used LangGraph to orchestrate the multi-agent environment, structuring the pipeline via nodes and edges of a graph. Each node is an agent and each edge acts as a conditional transition between nodes, making it possible to have turns within a debate. 

While this handles the basic flow of a debate, it does not enable dynamic speaker selection. For this, we needed custom logic, which we called the "bidding phase." During this phase, we ask each agent the question: “Do you want to respond to this statement and how badly do you want to speak? You have X/Y turns left.". This gives the agent the possibility to speak, but only for a limited number of turns within a debate.

We engineered the following core nodes:

  • orchestrator: Serving as the initial entry point from the start, this node maintains the global state. Based on the current debate phase, it routes the execution flow either to the chair for debate turns or directly to the voting node.

  • chair: an LLM router that weighs bids and grants the floor to the next speaker.

  • chair_order: This node functions as an aggregation and compliance checkpoint by checking it against the rules of procedure.

  • party_spokesperson: Generating positional speeches, interrupting others and votes in the final bill vote phase.

  • summariser: To prevent context window explosion and manage inference costs, this node maintains a rolling summary of the transcript.

  • minister: Agent that judges each motion and responds based on the summary.

  • voting: Triggered only during the final bill phase, this node resolves the legislative outcome before safely routing the graph to the end.

LangGraph was also used to track global state variables like max turns, active parties, and current rounds. This made the final flow possible between all agents. 

The final graph layout looks like this: 

AI debate simulation using LangGraph with nodes and edges
Figure 1: LangGraph layout of all nodes and edges.

Step 2: Making the pipeline traceable using LangSmith

The second step centered on making the pipeline traceable. Debugging the flow would be very difficult without the use of LangSmith. This framework makes it possible to trace all steps of the debate in great detail and integrates seamlessly together with LangGraph.

To achieve end-to-end observability is just a matter of wrapping the Gemini client in a LangSmith observer. LangSmith will trace prompts, tool calls, retries, and token costs. We could visit them later and see for each state what the agent did.

This was specifically useful for fine-tuning the prompts and checking if the state management and transition logic was implemented correctly. Below is an example of our tracing implementation: 

Example of a trace of a positional statement. The flow can be read from top to bottom, where each step the generation is shown: : Bidding -> orchestrator -> chairperson -> party statement including tool calls -> position snapshot -> Update summary

Step 3: Making it realistic by adding sufficient context

With LangGraph and LangSmith implemented, we now have a functional debate flow which we can observe, test, and debug. Next, it was time to add more context to each agent. For this, we gave the agent as much information about its party and role as possible. We injected this additional information for three reasons:

  1. Mitigating training bias: We observed that a basic prompt (e.g., "you are from party X ") steered the LLM toward extreme, polarized representations of that party.

  2. Addressing knowledge gaps: The LLM might know little to nothing about the smaller and younger parties.

  3. Anchoring outputs: We want them to not rely on over-exaggerated representations.


The injected context was split into three core components. The first prompt defined the agent’s role, including the party’s number of seats, speaking style, and whether it belonged to the governing coalition. The second provided the broader debate context, such as information about the bill, the rolling summary, and each party’s position. The third one contained the instruction for that specific LLM call.

Because prompt structure had a significant impact on performance, we sequenced these components as “role, context, task.” Placing the instruction at the end helped the agent stay focused on the immediate task, while the overall structure reduced context drift and produced more consistent results.

In addition to the default context the party agents were given, we implemented RAG (Retrieval Augmented Generation) using Google Cloud Agents Search. The retrieval corpus included party programmes, congress declarations, and the coalition agreement of the current cabinet. Metadata attached to each document allowed us to control access and make sure that each document was exposed to only the right agent.

Because bills can be quite lengthy, we included a summary in the default prompt and gave each agent the option to consult the full PDF when needed. This made the knowledge of the agent realistic while keeping its context manageable.

For the voting phase, we also gave the agents a tool that retrieves structured historical voting records on related bills. With these components integrated, we were able to deploy a fully functional, contextually grounded simulation!

Step 4: Making it useful by doing A/B testing

Using LangGraph, LangSmith, and a sufficient amount of context, we made a realistic digital twin of the House of Representatives and their debates. The next step was establishing an A/B testing framework to evaluate the policy reforms proposed in the DenkWerk report.

The report lists five reforms that can have an impact on how a plenary debate would go in the House of Representatives. These are:

  1. Electoral Threshold (Kiesdrempel): Introducing a minimum vote threshold to reduce political fragmentation in parliament.

  2. Extended Term of Office (Zittingsduur): Extending parliamentary terms from four to six years to encourage longer-term policy focus.

  3. Repealing the Senate (Eerste Kamer): Moving to a unicameral system to streamline legislative approvals.

  4. No Parliamentary Dissolution after No-Confidence: Preventing immediate snap elections when a cabinet falls, maintaining parliamentary continuity.

  5. Removing Media from the Chamber: Banning live broadcasting and cameras during debate rounds to decrease grandstanding and encourage pragmatic compromise.

To test the proposed reforms, we selected five bills and simulated each under different scenarios. The final experiment produced 238 debates. Although each individual debate took around 15 minutes to generate, running the simulations in parallel across 10 concurrent workers allowed us to complete the full experiment in only one night. We also parallelized the bidding phases to further reduce the total runtime.

To assess the impact of the reforms on the debates, we defined two objective quality measures:

  1. Debate quality: Measuring procedural throughput and multi-agent cross-turn semantic relevance.

  2. Concrete outcomes: Tracking the acceptance rate of downstream tasks, specifically motions, bills, and amendments.

We structured the final experiment into the following steps:

  • We established a quantitative baseline by simulating current parliamentary mechanics.

  • We simulated the five different reforms on several of the selected bills.

  • We evaluated how the metrics change between each reform.

Findings & Nuances

This experiment allowed us to measure the differences between the baseline and the reforms. Our analysis revealed two primary conclusions: first, while the AI debate quality drops slightly with the suggested reforms, the decision-making outcomes improve significantly. Secondly, the best reform is extending the parliamentary term from four to six years. The full methodology and results can be found in the report and online tool, find the link below.

We must note, however, that these results serve as indicative data points rather than conclusive proofs. Although we tried to make it as realistic as possible, fully replicating a parliamentary debate remains difficult. This is because LLMs are non-deterministic and inherently agreeable, which can affect how naturally disagreement and debate unfold. To mitigate this as much as possible, we validated our generated transcripts with a member of the current parliament.

Bonus: the engineering setup 

We’d briefly like to share some parts of the engineering setup that made it possible to build this in three months. Naturally, we leveraged Claude Code for development, augmented with several skills and MCPs. Among them, three sources were particularly helpful: 

  • Mattpocock (for architectural decisions)

  • Ponytail (for keep code simple and short)

  • Vercel (mostly UI-related)

Lastly, we created a custom skill.md file called the “Parliament Reality Assessor.” It contained procedural documentation on parliamentary debates and was used to automatically evaluate code changes for realism and procedural accuracy. This helped us stay consistent and keep each step of the implementation as realistic as possible.

Conclusion

Building a digital twin of the Dutch House of Representatives required a robust multi-agent architecture. In this blog, we detail how we built a functional AI simulation where agents debate legislative policies autonomously. 

We used LangGraph to structure the flow of the debate and integrated LangSmith to make the system easier to trace and debug. The realism of the simulation depended largely on giving each agent sufficient context and allowing it to retrieve additional information through RAG. This made it possible to A/B test different reforms and compare their effects in a cost-effective, sandboxed environment.

The results are not empirically conclusive. LLMs are non-deterministic, and agents can display sycophantic behaviour, both of which make it difficult to reproduce parliamentary debate with complete accuracy. Despite these limitations, the simulations made a significant contribution to DenkWerk’s final report.

Rather than relying solely on theoretical discussion, the report could draw on simulated, data-backed insights into how structural reforms might affect parliamentary debate. For example, the simulations indicated that changes such as extending parliamentary terms to six years could improve certain legislative outcomes.

You can find the full report here: https://denkwerk.online/rapporten/democratie-in-revisie-juni-2026/

Our tool is open to explore here: https://democratie-in-revisie.denkwerk-kickstartai.nl/

💡 Want to learn more about the KickstartAI community and our mission to accelerate AI adoption in the Netherlands? Check out our website or follow us on LinkedIn!