What happened
In an October 29, 2026 blog post, Raindrop describes an experiment with eight agents working together to resolve four outages in a simulated online store. The agents came from Claude Sonnet 5.5, GPT-6.1 Sol, Gemini 3.1 Pro and Kimi K3. Each received a name, from Ada through Hana; the researchers rotated names across models in different experiments. All agents had equal permissions and access to a shared communication channel, and none was assigned a leadership role.
Across 2,160 teams, at least one agent proposed a plan assigning work to two or more teammates in 86% of experiments. But Raindrop did not count a plan, or a teammate’s apparent compliance, as proof of leadership. The researchers replayed decisions with and without the relevant instruction to see whether it changed what the teammate did. A leader had to influence at least two teammates, meet the study’s influence-score criteria and have a higher total influence score than every other agent. By that definition, 105 teams—about 5%—had a leader. Seventy-three leaders issued a plan in round one; the other 32 showed leadership later.
The model affected leadership rates. Claude Sonnet 5.5 and GPT-6.1 Sol were approximately 1.7 times as likely to become leaders as Gemini 3.1 Pro. Kimi K3 was a leader in one of the 105 experiments with a leader. The models that issued the most plans were not necessarily the most influential: Gemini and Claude produced the most plans, while GPT had the most instructions followed. All four models were approximately equally likely to follow a leader’s instructions.
Prompt order produced a separate effect. The agent whose name appeared first in the system prompt was three times more likely than the others to issue a plan. The effect was not explained by the underlying model, since names and models were rotated. When the researchers reversed the list of names, the elevated plan-making rate shifted to the new first name. Meanwhile, access to the shared channel reduced duplicated actions from an average of 4.4 to 0.3 per experiment.
The setup was a constrained game: eight agents investigated four outages across ten services, using a shared channel, limited queries and a fixed number of repair attempts. Raindrop says the agents had one query each; an incorrect repair used one of the four available filings. The experiment therefore tested coordination under a specific combination of shared information, turn-taking, permissions and task rules—not open-ended teamwork.
What the archive adds
New Runtime’s earlier coverage includes How to Train a Swarm (November 3, 2026), on using shared rewards and latency pressure to encourage parallel work, and s³: Simple Scaling of Swarms via Cooperative Multi-agent RL (November 10, 2026), on learned coordination at larger swarm sizes. Raindrop adds a new experimental finding about emergent influence and prompt ordering; it is not a restatement of either training method.
Trend signal
This supports harness-architecture-outlives-model-choice: the experiment finds that configuration details, including the name order in a system prompt, can alter swarm behavior even when permissions are equal. It does not establish that harness design matters more than model choice; Raindrop also reports differences in leadership rates across models.
Connections to other events
New Runtime’s earlier coverage of swarm training and scaling describes ways to shape coordination through rewards and learned policies. Raindrop examines a different layer: who proposes plans and whether those instructions change another agent’s choices. Together, the work points to distinct design questions—how to train coordination, how to scale it, and how to measure influence in a running team.
Why it matters
For builders, the study cautions against treating visible planning as evidence of effective delegation. A swarm can produce many plans without any agent consistently changing what others do. If an application depends on a coordinator, teams should measure whether instructions alter downstream actions and whether the resulting work improves task completion—not just count messages or assign a nominal leader.
The prompt-order result also makes configuration review more consequential. A list of peer agents may look like neutral bookkeeping, yet the reported experiment found a threefold difference in plan issuance based on position. That does not prove the same effect will appear in production systems, but it gives builders a concrete variable to test. Reversing agent order, rotating identities, and comparing results across repeated runs are inexpensive ways to check for accidental role assignment before relying on a swarm for operational work.
Limits and uncertainty
Raindrop tested one simulated online-store outage task with four named models and a particular prompt, channel, turn structure and scoring rule. The results do not establish how often informal leadership emerges in other tasks, model versions, agent frameworks or real production environments. The post reports replay-based influence tests, but the findings have not been independently replicated here. The experiment also does not show that a leader improves overall task success; shared-channel access reduced duplicate actions, but that is a narrower outcome than verified resolution quality.
Skill to build now
If you run peer-agent workflows, add a small order-sensitivity test this week: keep the task and permissions fixed, rotate which agent is listed first, and repeat each setup enough times to compare plan issuance and downstream actions. Track whether instructions change decisions, not merely whether messages contain assignments. This turns a hidden prompt detail into an observable configuration variable.
Reader takeaway
A swarm can look organized without having a leader that actually changes teammates’ behavior. Raindrop’s experiment suggests that model identity and prompt ordering both affect coordination, so treat the agent roster and its presentation as part of the system design—and test their effects rather than assuming they are neutral.