What survives?
Follow contributions through revisions, adoption by peers, and the final selection.
/ 01 — Why I built itThe result is
The result is
only part of
the story.
I want to understand how a group gets to its answer. Which agent introduces an idea? Who develops it? What disappears as the proposals become more alike?
I write the code, run the experiments, and inspect the traces to connect those questions to what actually happened. The aim is to use that evidence to improve the collaboration process and experiment again.
Who changes their mind?
Examine how agents defend, revise, or abandon their positions as they encounter other proposals, how that differs between LLMs, and how their prompts change it.
Is another round worth it?
Measure how much each round improves the answer and up to what point, to know when another round no longer justifies its time and cost.
The test challenges are deliberately difficult. Their purpose is to expose collaboration behavior. Final answers may be useful, wrong, infeasible, or even absurd. Those outcomes are part of the study.
/ 02 — The current starting pointPropose. Share.
Propose. Share.
Revise. Vote.
Today, Slow Thinker implements one collaboration mechanism: independent proposals, shared refinement rounds, and a final vote. Participants, each agent's LLM and prompt, and round counts are configurable; an agent can even be told to sabotage the process. The current experiments use structured action plans as their common format.
- 01
Propose
Each agent tackles the same challenge independently. The first proposals are produced in parallel.
- 02
Share
Every agent receives all the proposals from the previous round.
- 03
Revise
Agents can retain, adopt, correct, or replace ideas. This repeats for the configured refinement rounds.
- 04
Vote
Voters choose among the final proposals with the authoring agents hidden, and explain their choices.
/ 03 — Read the evidenceA way into
A way into
the report.
Every run preserves proposals, prompts, responses, votes, timing, and costs. The interactive report brings them together. Start with a question, then follow it back to the underlying material.
Influence matrix
Who picks up
Who picks up
whose ideas?
The matrix compares proposals across consecutive rounds. “Same titles” reports matches calculated by the program. “Analyst sees” adds an LLM's interpretation of adoption and rejection.
The two can disagree. Looking at that disagreement is part of the work.
Explore the influence matrix ↗
Process evaluation
What improved?
What improved?
What was lost?
An optional LLM analyst examines the finished run: convergence, criticism, regressions, and the loss of alternatives.
This analysis happens after collaboration. It does not feed back into the rounds or change the selected proposal. Its conclusions can be checked against the original responses.
Read the process evaluation ↗
Follow a contribution further. In the Process view, select a proposal to inspect its step lineage. The Contributions view shows estimated origins across rounds and in the selected plan.
Explore contributions per agent ↗/ 04 — An observationAn idea survives.
An idea survives.
Its attribution
disappears.
21 September 2026 · Five-agent run · Executor 0.1.5
In this run, automatic attribution credits the GPT agent with zero steps in the selected plan. Reading the proposals reveals something that the title comparison misses.
- Initial proposal · GPT
“Install immediate minimum controls”
The step includes a provisional seven-day process for dealing with incidents while the full operating model is established.
- Next round · Opus
“Seven-day interim command bridge”
The Opus agent incorporates that approach in its next proposal. The content carries forward under a different title.
- Selected plan · Opus
The idea remains.
The provisional process survives further revisions. The analyst identifies the adoption; automatic lineage does not preserve the connection to the GPT agent.
Current automatic attribution relies on step-title similarity. This example shows why the next planned version will follow the meaning and transformation of ideas, including contributions shared between agents.
Inspect the original proposalsA vote, consensus, or favorable analyst assessment does not establish correctness. A single run also cannot establish that one LLM is generally more influential or useful than another.
/ 05 — Experiment libraryOpen the run.
Open the run.
Follow the ideas.
Explore the full library by run or by prompt, including earlier analyses. Each report includes the full challenge and configuration.
The two featured runs below tackle the same software incident-management challenge. Their data downloads contain the saved JSON records, including the analyst's output.
01
Five agents on five LLMs, four rounds.
Trace how proposals absorb contributions from other agents, and inspect the gap between title-based attribution and the analyst's reading.
Opus 5 · GPT-5.6-sol · Qwen 3.8 Max · Grok 4.6 · DeepSeek V4 Pro
- Agents
- 5
- Total rounds
- 4
- Proposals
- 20
- Executor
- 0.1.5
02
Three agents on three LLMs, three rounds.
A smaller group tackling the same challenge. Follow the initial alternatives, their revisions, and the reasons given in the final vote.
Claude Haiku 4.5 · DeepSeek Flash · Qwen 3.8 Flash
- Agents
- 3
- Total rounds
- 3
- Proposals
- 9
- Executor
- 0.1.2
The LLM names above are the identifiers recorded in these runs. In both runs every agent received the same instructions; only the LLM and its settings changed. The experiments differ in participants, round counts, and executor versions; they are exploratory examples, not a controlled comparison of LLM performance.
REFERENCE LIBRARYUnderstand every view.
Understand every view.
Inspect every method.
The documentation follows the complete experiment: configuration, case definition, agents and rounds, execution, analysis, and report generation. Every reference entry identifies the version it describes.
Run it. Read it.
Follow the workflow and understand every report field, chart and control, with real screenshots and links to the interactive examples.
Open the user reference →Follow the implementation.
Configuration fields, provider adapters, saved records, analysis schemas and the algorithms behind attribution, timing and costs.
Open the technical reference →Keep the context.
Distinguish the current implementation from an older run. Find a report element by name and follow the project’s change history.
Browse all documentation →/ 06 — What comes nextBetter questions.
Better questions.
Better experiments.
The broader aim is to compare collaboration processes, LLM combinations, prompts, and iteration counts, then use the results to improve the next experiment.
Follow the meaning.
Recognize ideas across changes in title and wording. Track how they combine, change, or disappear, and attribute shared contributions more faithfully.
Vary the collaboration.
Define processes in JSON: message exchanges, supervision, critics, devil's advocates, conditional paths, and loops. Today, JSON configures the existing round-based process.
Bring critique into the loop.
Introduce a critical evaluator from a chosen round, then repeat contributions, critique, and revision. Examine whether resolving substantive objections leads to better outcomes.
Sustained improvement could indicate that further iteration may converge toward a correct result. That is a hypothesis to test against the outcome; convergence alone does not demonstrate success.
Built and studied in the open
An experiment worth discussing?
I welcome difficult test cases, alternative interpretations, and ideas for evaluating collaboration. Each new observation is a reason to revisit the process.
Discuss on LinkedIn