A Lost Correct Answer
Imagine you design an AI team. A master agent decomposes tasks, 30 sub-agents each solve problems and write reports. Checking the logs: of 563 problems, sub-agents actually solved 373 correctly. Then you see the final deliverable: only 217 correct.
166 once-correct answers vanished in transmission. Process-level answer retention was only 55.5%.
This is not a model capability issue. Sub-agents could solve the problems; the master agent could read the reports. But the master agent's context is finite—30 reports had to be compressed and triaged, discarding what it "deemed unimportant." These 166 losses are not "couldn't solve" but information loss from organizational structure.
This is internal experiment data recently published by the EvoMap team, collected to answer a bigger question: after training, model parameters are frozen—how do you achieve continual learning? Their answer is a "bee-swarm self-evolving agent cluster"—a collective intelligence with no central brain. But the experiments reveal a structural fork that is more interesting than the "swarm vs. master-slave" comparison itself.
Three Organizations, Three Accuracy Tiers
Same model, same 563 problems (100 logic, 250 general math, 63 competition math, 150 physics), three organizational modes:
- Monolithic (Agent Loop): all problems in one context, one agent end-to-end. 26.3%.
- Master-slave (Agent Team): master decomposes, sub-agents solve in continuous sessions and write reports, master merges 30 reports—simulating Claude Code / Codex-style orchestration. 38.5%.
- Swarm (Agent Swarm): decompose into atomic tasks, one independent agent per problem writing answers to agreed locations, a program collects them by problem number. 70.7%.
- LoRA: low-rank adapters updated to learn new things—changing the model's "instincts," like editing DNA.
- AI4AI: AI running its own research loop.
- EvoMap: experience sedimented into Genes (structured experience records) in
genes.json, accumulated and reused via group collaboration—changing the model's "experience," like RNA editing. - Seeing only social information (who collaborated with whom), agents preferred "friends of friends," maintaining cliques.
- Seeing task information (expertise, accuracy), selection shifted from familiarity to "who gets things done"; high-scoring agents became hubs.
- EvoMap/EvoX: gitee.com/EvoMap
- AgentNet: arXiv:2504.00587
- OpenAI Swarm (archived): github.com/openai/swarm
- Kimi K3 Agent Swarm: moonshot.ai
The gap is wide, but there is an engineering caveat: stuffing 563 unrelated problems into one context causes mutual interference, and one-agent-per-problem naturally avoids this. So these numbers demonstrate "parallelize when you should, and let programs—not models—do the aggregation" rather than proving swarm architecture is inherently superior.
The truly interesting data is the middle layer: sub-agents got 373 correct; after the master merged reports, only 217 remained.
Channel Capacity: Where 166 Answers Went
These answers were lost not on "capability" but on channel bandwidth. The master agent's context is a finite-bandwidth semantic channel; reports passing through are compressed, triaged, discarded. This is lossy transmission in the information-theoretic sense—the sub-agents didn't explain poorly; the master couldn't hear fully.
The swarm replaces the aggregation from a semantic channel to a symbolic channel: answers written to fixed locations, collected by a program by problem number—lossless. This is the same principle as Euclid-MCP's "let the LLM be the poet, let Prolog be the accountant":
> Division of labor beats unification. Parallelize where possible; don't have the model paraphrase what a program can aggregate.
The master-slave failure isn't archaic architecture—it's forcing the model to do two things it's bad at simultaneously: solving subtasks and compressively retelling others' subtasks.
Continual Learning: Update Parameters or Update Memory?
EvoMap's real target is continual learning. Current routes:
These aren't mutually exclusive; they are granularity-isomorphic instances of continual learning:
| Level | Mechanism | Analogy | Granularity | |-------|-----------|---------|-------------| | Parameter | LoRA | DNA editing | Parameter-level | | Memory | Gene/Memory | RNA editing | Behavior-level | | Architecture | Agent organization | Population structure | System-level |
EvoMap chose level two not because it is the only answer, but because under the "no retraining" constraint, it is the most cost-effective layer.
Gene vs. SKILL.md: Executable vs. Readable Knowledge
EvoMap's GEP protocol runs a six-step loop: Scan (watch logs for errors/stalls), Signal (standardize logs), Intent (plan evolution), Mutate (generate code/prompt strategies), Validate (sandbox tests), Solidify (write validated capabilities into genes.json).
The key distinction from SKILL.md: SKILL.md is documentation written for humans that models happen to read; Gene keeps only what changes agent behavior.
My reservation: an optimization list without a reflection log tends toward local optima. Human experts' tacit knowledge includes "what not to do" and "why this works." If Genes keep only "what changes behavior," agents may accumulate a list of "what works" without knowing "what almost worked" or "why the old approach failed." Long-term, agents dig deeper in one direction but cannot cross paradigms—paradigm shifts require re-understanding why, not more optimization. This mirrors the finding in *Looping Is Not Reliability*: once-correct does not mean still-correct. When environmental change turns effective strategies into traps, agents have no reflection log to trace back.
The Real Fork in Collective Intelligence
The second experiment is the one relevant to continual learning. 24 identically-configured agents each solved problems, sedimenting a Gene per problem; more accumulated experience of a type increased the probability of picking similar problems next round. Each agent developed its own track record.
Then the experiment randomly broke some of the 24 agents' relationship network and let them re-pick teammates:
Organization is not ex nihilo: whatever information the system exposes, that is the connection pattern agents grow. Academic work AgentNet (arXiv:2504.00587) does nearly the same thing—agents spontaneously specialize as networks evolve, connection weights reflecting collaboration strength. So this is not an isolated case.
But a structural fork is hiding here, which the paper does not spell out: will result-oriented collaboration networks self-reinforce into an oligopoly? High-scoring hubs attract more tasks, accumulate more experience, and score higher; low-scoring agents get no tasks and never improve—standard Matthew effect. Real bee swarms don't have high-scoring individuals monopolizing tasks, because allocation is based on "who is nearby" and "who found it first," not historical accuracy.
Strictly speaking, this is not "collective intelligence with no central brain" but "collective intelligence where protocol precedes emergence"—even teammate selection is prescribed by the protocol. This is not a criticism: bee protocols are also hardcoded in genes. The open question:
> If result-oriented networks self-reinforce into oligopolies, does EvoMap need an anti-Matthew mechanism—or is oligopoly the correct end-state of continual learning, with a few expert agents specializing while others degrade into routers?
One possibility: oligopoly is right, mirroring worker/forager bee differentiation. Another: it is a trap requiring anti-Matthew mechanisms (random perturbation, forced rotation, experience decay) to preserve diversity—echoing ecology's "disturbance maintains diversity."
Protocol Before Emergence
A deeper question: can the protocol itself learn continually? GEP is a fixed six steps. If agents someday need a "Reflect" step or to drop "Signal," who approves the change? If the protocol cannot evolve, continual learning only happens within the protocol's frame—capabilities outside it are never learned. A true "self-evolving agent cluster" may need to turn the protocol itself into a Gene—letting agents modify their own learning protocol. But this loops back to an old question: who writes the protocol for writing protocols? Doesn't that require a central brain again?
My Take
Collective intelligence is not "no central brain"—it is moving the central brain from runtime to design time. The GEP protocol is the central brain; it prescribes all runtime possibility boundaries at design time. There is genuinely no central coordinator at runtime, but there is one at design time. This echoes Gubernaut: moving regulation out of model weights parallels moving coordination out of runtime—both "solve the problem by changing layers."
The true end-state of continual learning may not be "agents evolving their own protocols," but three layers each learning continually at their own granularity: design-time protocol + runtime experience + architectural organization. LoRA edits parameters, Genes edit experience, swarms edit organization, protocols edit… what?
That question may be the most worth chasing next in the continual learning route.
---
Papers & Projects:
*When the central brain moves from runtime to design time, swarm intelligence emerges. But the brain at design time is the one that truly needs to keep learning.*