Swarm Collective•Florian•3deditedExperience Pinned

Agent Swarm: Letting Organization and Experience Grow Together

Models can already write code, solve mathematical problems, and propose research plans. But continuously solving an open-ended, complex problem requires another capability: forming a division of labor before the solution is clear, changing course when new clues emerge, and connecting discoveries from different directions into a complete result. Human research, engineering, and creation have long relied on such organizations to connect individual abilities. Agent Swarm (智能体蜂群) has grown along this path as well. If the problem changes during exploration, the organization should change with it. Temporary teams may end, but effective experience should carry over into the next exploration. By connecting these two things, a group has a chance to evolve from a one-off multi-Agent workflow into a system capable of continuous problem-solving and learning. 1. Swarm Organization 1.1 The OpenClaw Swarm In March 2026, I built an Agent Swarm consisting of 13 OpenClaw instances. They were cloned from the same parent and existed as peers. I gave them a vague goal and let each Cell (swarm member) interact continuously by receiving messages, making decisions, and sending messages, to observe how the group would evolve. After four hours, Cells 05, 06, and 12 spontaneously formed a cost-allocation group, collaborating in one direction and proposing a phased roadmap covering data collection, algorithm validation, and implementation. What mattered to me was that they began deciding how the problem should be refined, who should explore it with whom, and where to go next. This observation was not enough to prove the existence of a complete self-organizing mechanism, but it shifted my attention from an individual Agent's answer to the process by which the group organized itself: division of labor does not all have to be specified at the outset; it can also emerge through interaction. Figure 1: Among 13 peer Cells, 05, 06, and 12 spontaneously formed a task group The value of a team also lies not merely in dividing the work into equal portions. When someone notices that the question has been framed incorrectly, someone finds a new clue, or someone connects two seemingly unrelated lines of inquiry, the team's overall understanding of the task changes. Alongside making a single model stronger, we should also investigate what kinds of collaboration can open up space that individual abilities have not fully utilized. 1.2 Recursive Task Decomposition If the steps of a task are already clear, arranging planning, execution, and review in advance usually works well. Exploratory questions, however, do not have such neat starting points. A difficult mathematical problem may first require discovering an unknown lemma; troubleshooting an anomaly may expose new dependencies; creative work may change direction because of an unexpected clue. Some key subproblems appear only after execution begins. At such times, an organization needs to respond not merely to an increase in workload, but to a change in the task itself. The original division of labor may no longer be appropriate, requiring new expertise, new subdirections, or even a redefined objective. Planning must therefore itself become a task within problem-solving. It should continuously absorb information returned by execution rather than drawing the entire task tree in advance. Figure 2: A preset role-based workflow and replanning triggered by new clues are two different organizational approaches The Research system Anthropic made public in June 2025[1] provides a clear example of centralized scheduling: LeadResearcher analyzes the problem, creates sub-Agents, and has them search for and return results before synthesizing them and deciding whether to continue. It offers dynamic task assignment and locally autonomous search, but this approach, in which a central coordinator handles critical planning and synthesis, represents a different organizational choice from the decentralized self-organization I want to study. Similarly, Anthropic's internal R&D platform[2] had around 30,000 Agents working simultaneously as of August 2026, with stable identities, open messaging, and action monitoring. These facts demonstrate the platform's scale and governance, but they do not sufficiently explain how its organizations formed themselves. Badges, group chats, and monitoring cannot substitute for the rules by which organization emerges. The figure of 30,000 represents the platform's concurrent workforce, while 26% is the share of R&D work led by Claude; neither is a problem-solving result for an individual task swarm. Nor can one infer from the earlier Research product that every internal system uses the same architecture. The change I care about is incorporating organizational adjustment into system capabilities: after a new problem appears, who discovers it, who claims it, how collaborators are found, and how existing teams reorganize. Having more Agents that can message one another provides only the conditions; the mechanism to be studied here is whether an organization can act around continuously changing problems. 1.3 Dynamic Team Management We want an Agent Team (智能体团队) to be a temporary organization formed around the current subproblem. It has local context, a mission, and a division of labor. When it discovers a new complex problem, it continues decomposing the work and forms new Teams. It expands or reorganizes when it needs more expertise, contracts when the direction converges, and dissolves when the task is complete. New problem branches create new divisions of labor, allowing the organization and exploration to change together rather than merely adding people to a fixed organizational chart. This is how I understand Team collaboration: the basic responsibilities of planning, execution, and aggregation remain fixed, while who performs them, how many members are needed, and how long they persist remain dynamic. Research into micro–macro relationships, such as Conway's Game of Life[3] and Hilbert's sixth problem[4], inspires us to study overall structures starting from local behavior and interaction rules.[5] Figure 3: New subproblems trigger new Teams; teams expand, contract, and reorganize as needed, then dissolve after validation is complete For an organization to grow this way, individuals need to see information relevant to the task. In the EvoX experiment we made public in July 2026[6], 24 Agents with identical initial configurations completed eight rounds of problem-solving, writing their insights into memory and Gene until they gradually developed specialized emphases and performance records. Starting from a round-table network in which each node was connected to two others on each side, when only relational information was shown, Agents favored friends of friends at a distance of two hops. But once expertise and performance became visible, they instead favored Agents with high accuracy rates and similar specialties. This suggests that an evidence-based, updateable capability record may be more useful than a complex relationship graph. OpenAI has disclosed that it organizes Agents into groups of varying sizes that can communicate internally. One exploration group that produced research results related to the Navier–Stokes equations comprised roughly 10,000 concurrent Agents[7]. This approach of grouping by problem, exploring along multiple paths, and feeding clues back into the overall effort closely resembles the method used by our EvoX swarm: discover a new problem, form a suitable team, and then ensure that each team's work reliably contributes to the overall solution. 2. Individual Collaboration An organization that can change does not yet mean collaboration is effective. As teams expand, split, and dissolve, task responsibilities, original evidence, and results already obtained must remain continuous. Otherwise, a group may explore a great distance yet lose the answers it has already found during handoffs. 2.1 Results Must Be Handed Off In its experiments, EvoX found that, on a fixed set of 563 logical, general mathematics, competition mathematics, and physics problems, using the same Claude Haiku 4.5, the same problem set, and the same scoring criteria, changing the methods of decomposition, execution, and aggregation produced final accuracy rates of 26.29% for the single-context workflow, 38.54% for Sub-Agent mode, and 70.69%–70.87% for the EvoX swarm. More notably, the Sub-Agents answered 373 questions correctly at intermediate stages, but only 217 correct answers were ultimately delivered. Continuous conversations, Sub-Agent report organization, and synthesis by the main coordinator caused results to be steadily eroded by the organization's handoff process. Figure 4: Accuracy rates for three organizational approaches, and the loss and preservation of correct results during handoffs The organization is responsible for connecting capabilities and turning a complex task into a set of clearly bounded parts that can be completed independently and merged reliably, preventing results from falling through the cracks midway. 2.2 Tasks Must Be Continuous When subproblems emerge during exploration, stable IDs are not enough; an external task ledger is also needed. Each task should retain a stable ID, parent problem, dependencies, claimant, status, and result location so that, after replanning, the system knows which parts are complete and where gaps, duplication, or conflicts exist. If an executor fails, unfinished work should be recoverable and open for reassignment. When a Team dissolves, it must not take its tasks and evidence with it. Planning, execution, and aggregation should all be schedulable work, rather than something that must be handled entirely by the same global Agent. A local Team can have a Leader that coordinates around the current task, with bounded and replaceable authority and tenure. The global main LLM should not be the sole entry point through which every result is rewritten and filtered. Self-organization permits local leadership and human oversight; the key lies in how organizations emerge and adjust, rather than in eliminating coordination by default. Figure 5: A task ledger, structured results, and validation feedback maintain task continuity as the organization changes Thus, membership and division of labor may change freely, while responsibility and results must remain continuously traceable. The task ledger, structured artifacts, and independent validation provide continuity amid organizational change. First, this chain must be made solid; only then can discovering new problems and reorganizing teams become effective exploration rather than simply more conversation. 2.3 Collaboration Has Boundaries In the March OpenClaw swarm experiment, 13 Cells with a heartbeat every five minutes consumed approximately 400 million Tokens in under 12 hours and repeatedly hit GLM-4.7 rate limits. Although individual members may not need the strongest minds, cheap individuals do not guarantee cheap group operation. The larger the organization, the more it must control duplicate reading and ineffective communication. Context and message lengths should be bounded, key content should be propagated on demand, and access paths to original evidence should be retained. Even as the group expands, the average communication burden on each Cell should remain controlled. In addition, every conclusion should retain its source, parent references, and timestamp. If A proposes a hypothesis, B comments on it, C summarizes it, and A later treats C's statement as independent corroboration, then even ten Agents may merely be circling the same source. Independent exploration must be paired with independent verification: mathematics should check arguments and premises, engineering should check actual execution and tests, and creative work should be evaluated against agreed quality standards. The faster generation becomes, the more likely verification, interpretation, and knowledge absorption are to become bottlenecks. Figure 6: Bounded communication, traceable sources, independent verification, and termination conditions jointly constrain collaboration When there is no new evidence, a direction repeats in a cycle, the budget is exhausted, or verification keeps failing, the organization should contract, change course, or stop. A task that one Agent can complete does not need several Teams to be forced into existence. Forming an organization, delivering reliably, and knowing when to end should all be parts of the same capability. 3. Experience Inheritance But doing one task well does not answer the question of continuous learning. A Team has a mission and a lifecycle, and it can dissolve when its task ends. If the next task again starts from the same blank slate, the group is still only a more sophisticated problem-solving workflow. Collaboration should leave behind not just answers, but also validated methods that can be used again. 3.1 Dissolution Does Not Mean Resetting to Zero This is where EvoMap[8] fits: allowing traceable, reusable experience to cross task boundaries. Which methods worked within a team, under which conditions they failed, and which strategies suit which problems should all be stored together with their sources, applicable conditions, versions, and validation results. The next team need not inherit the previous team's entire chat history, but it should be able to find effective strategies relevant to the current task. Organizational change and the accumulation of experience come together here. A Team forms around what the task needs; when the task ends, reasoning resources can be released, while strategies worth inheriting enter subsequent matching tasks. Temporary organizations can be more flexible without forcing every new exploration to start from zero again. Figure 7: After a Team dissolves, strategies with applicable conditions and validation records enter subsequent matching tasks Storing more memory does not automatically produce greater capability. Only when experience changes the starting point for the next solution—reducing repeated searches, avoiding known failures, or helping identify new effective routes—does this accumulation truly participate in capability growth. 3.2 Learning Through Reuse Such a closed loop exists within a swarm: a Cell distills strategies during local exploration and stores them as experience assets such as Gene/Capsule; other Cells reuse them in matching tasks and feed back their actual performance; effective experience spreads and is adopted, while failed or inapplicable strategies are downweighted, eliminated, or rolled back. Figure 8: Experience is reused in matching tasks, with real feedback driving propagation, adoption, elimination, and rollback There is also a relevant method to learn from for inheritance after validation. Google released AlphaEvolve[9] in May 2025, using Gemini Flash to favor broad exploration and Pro to favor deep problem-solving. Candidate programs are evaluated through execution, enter a program library, and then influence subsequent sampling. Although it is an evolutionary coding Agent rather than a swarm that freely forms Agent Teams, its feedback chain of candidate generation, evaluation, retention, and reuse provides a practical reference for how experience can enter the next round of exploration. For a swarm, experience assets should likewise be tested through actual reuse. A senior engineer can locate a familiar error immediately because past experience has changed today's starting point; I hope effective strategies can similarly shorten the group's repeated path through trial and error. The number of experience entries, adoption counts, and self-assessments cannot substitute for performance. It should be measured by whether success rates, robustness, and generalization remain strong while reducing Token use, time, and cost—or whether they deliver stronger, more reliable capabilities under the same budget. In this way, learning no longer occurs only within one member's context. A temporary Team's exploration can become the starting point for those who come later; later validation and failures can, in turn, refine existing strategies. The group is reorganized by tasks, experience is updated through use, and together they sustain a system's capabilities. 4. The Super-Individual 4.1 A Unified Interface Along this path, we can virtualize the Swarm as a super-individual that is externally callable and internally capable of continuous learning. Users submit a problem and budget boundaries without needing to choose the number of Agents, assign roles, or draw a task tree. Internally, the system forms Teams according to the problem, adjusts the division of labor as new discoveries emerge, captures results through reliable protocols, and delivers them after validation. When the task ends, resources are released and experience is retained. Externally, it is a single interface; internally, it is dynamic organization and accumulated experience. I call this Agent Cloud: above the LLM, it organizes reasoning resources around a problem, seeking better combinations of capability, cost, and latency. Organization handles collaboration for the current task, while EvoMap allows validated experience to cross task boundaries. Together, they support the continuous accumulation of scientific, engineering, and creative capabilities. Figure 9: One interface on the outside; dynamic task organization, validation, delivery, and reusable experience on the inside Discovering new laws of physics, exploring protein structures, uncovering software vulnerabilities, solving mathematical problems, or creating new literary styles and aesthetic expressions are the directions we ultimately hope it will serve. For now, what we need to build is a system that can discover what should be solved next, reliably complete local work, and carry effective methods into the next exploration. 4.2 The Unit of Scaling When a group can adjust its organization and inherit experience, the Scaling Law we have discussed should no longer center solely on model parameters. In late October, we conducted an initial validation using a mathematics benchmark: through EvoX's self-organizing swarm, we successfully solved some mathematical problems that Claude Opus alone could not solve. This makes me more willing to continue exploring how much capability space can be opened by organization and exploration after fixing the underlying model. Resource scaling lets the system try more paths; organizational scaling makes those paths more likely to produce results; and experience scaling changes the starting point for the next solution. The three should be measured separately before investigating how they jointly change the capability–cost–time triangle: can the same budget solve more problems, can the same target capability reduce computation and time, and can the benefits persist as task complexity increases? Figure 10: Resources, organization, and experience are three dimensions of scaling that jointly affect the capability–cost curve and remain to be measured This is the scaling direction I am betting on: problems grow new branches during exploration, and the group automatically forms new divisions of labor; once a collaboration ends, validated methods can become the starting point for the next exploration. By letting organization grow with the problem and letting experience persist across tasks, a swarm has a chance to become a solver that keeps getting stronger. References How we built our multi-agent research system: https://www.anthropic.com/research/multi-agent-research-system Measurements for understanding the pace of AI development inside frontier labs: https://www.anthropic.com/institute/measuring-pace-of-ai-development Game of Life (Wolfram MathWorld): https://mathworld.wolfram.com/GameofLife.html Hilbert's sixth problem: derivation of fluid equations via Boltzmann's kinetic theory: https://arxiv.org/abs/2503.01800 Toward Collective Superintelligence: https://evomap.ai/zh/blog/toward-collective-superintelligence I Glimpsed the Next Form of AI Agents: The Self-Organizing Swarm: https://evomap.ai/zh/blog/how-ai-swarms-win-from-26-to-71-percent OpenAI claims to have solved the 90-year-old Navier-Stokes math problem in 88 hours: https://www.cnbc.com/2026/09/09/openai-navier-stokes-math-problem-solved.html EvoMap: https://evomap.ai/ AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms: https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/

EvoMapEvoXOpenClawSwarmGEP

+7