A Lost Correct Answer
Imagine you design an AI team. A main agent splits tasks across 30 sub-agents, each solving problems and writing reports. Afterward, you check the logs: of 563 problems, the sub-agents actually solved 373 correctly. Relief.
Then you look at the final deliverable: only 217 correct.
166 once-correct answers vanished in transmission. Process-level correct-answer retention was just 55.5%.
This isn't a capability problem. The sub-agents could solve; the master agent could read. But the master agent's context is finite—stuffing in 30 reports forces compression and triage, dropping whatever it deems "unimportant." The 166 lost answers weren't "couldn't solve"; they were information loss from organizational structure.
This is internal experimental data recently published by the EvoMap team, run to answer a bigger question: model parameters freeze after training—how do you achieve continual learning? Their answer is a "hive-style self-evolving agent swarm"—collective intelligence with no central brain.
But their experiments reveal a structural fork that's far more interesting than the headline "swarm vs. hierarchy" comparison.
Three Organizational Structures, Three Accuracy Levels
EvoMap's first experiment used the same model on the same 563 problems (100 logic, 250 general math, 63 competition math, 150 physics) under three structures:
- Monolithic (Agent Loop): everything in one context, one agent start to finish. 26.3%.
- Master-slave (Agent Team): a main agent decomposes tasks; sub-agents solve in continuous sessions and write reports; the main agent merges 30 reports into the final answer—simulating Claude Code / Codex-style orchestration. 38.5%.
- Swarm (Agent Swarm): problems are atomized, one independent agent per problem, answers written to agreed locations, and a program collects them by problem number. 70.7%.
- LoRA: bolt on low-rank adapters; update them to learn new things. Changes the model's "instincts"—like editing DNA.
- AI4AI: let AI run its own research loop.
- EvoMap: distill experience into Genes (structured experience records) written into
genes.json, accumulated and reused via swarm collaboration. Changes the model's "experience"—like RNA editing. - Seeing only social information (who collaborated with whom), agents favored "friends of friends"—small cliques.
- Seeing task information (specialties, accuracy), selection shifted from familiarity to "who gets things done"—high scorers became hubs.
- EvoMap/EvoX: gitee.com/EvoMap
- AgentNet: arXiv:2504.00587
- OpenAI Swarm (archived): github.com/openai/swarm
- Kimi K3 Agent Swarm: moonshot.ai
A wide spread—but there's an engineering-basics caveat: stuffing 563 unrelated problems into one context guarantees interference, and the swarm sidesteps this by design. So these numbers mostly show "parallelize when you should, and let a program do the merging instead of having a model paraphrase"—not that swarm architecture is inherently superior.
The genuinely interesting layer is the middle one: in the master-slave setup, 373 correct answers shrank to 217 after aggregation.
Channel Capacity: Where Did 166 Answers Go?
They weren't lost to inability—they were lost to channel bandwidth.
The master agent's context is a finite-bandwidth semantic channel. Pushing 30 reports through it necessarily compresses, truncates, and discards. This is lossy transmission in the information-theoretic sense: the sub-agents didn't fail to explain; the master agent failed to hear it all.
The swarm replaces the semantic channel with a symbolic channel: answers written to agreed locations and collected by program—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 what should be parallel; don't make a model paraphrase what a program can merge.
The swarm isn't "more advanced"—it lets models do what they're good at and programs do what they're good at. The master-slave failure isn't architectural backwardness; it's forcing the model to do two things it's bad at simultaneously: solve subtasks *and* compress others' subtasks.
Continual Learning: Update Parameters, or Update Memory?
EvoMap's real question is continual learning. Current routes:
A common confusion treats these as either/or. The real question is at which level continual learning operates:
| Level | Mechanism | Analogy | Granularity | |-------|-----------|---------|-------------| | Parameters | LoRA | DNA editing | Parameter-level | | Memory | Gene/Memory | RNA editing | Behavior-level | | Architecture | Agent organization | Swarm structure | System-level |
These are not mutually exclusive—they are granularity-isomorphic instances; optimization granularity should match the granularity of what's being optimized. EvoMap chose level two not because it's the only answer, but because under the "no retraining" constraint it offers the best value. That's why the team's trajectory—Evolver (plugin) → EvoMap (platform) → EvoX (swarm)—stays within "memory layer + architecture layer": given the no-parameter constraint, there's nowhere else to go.
Gene vs. SKILL.md: Executable vs. Readable Knowledge
EvoMap's GEP protocol closes a six-step loop: Scan (watch logs for errors and stalls), Signal (convert logs to standardized signals), Intent (plan the evolution direction), Mutate (generate new code or prompt strategies), Validate (sandbox testing), and Solidify (write validated capabilities into genes.json).
The key difference from SKILL.md: SKILL.md is documentation written for humans that models happen to read; Genes keep only what changes agent behavior.
This is "readable knowledge" vs. "executable knowledge." Genes sound leaner and more efficient. But I have a reservation:
An optimization checklist without a reflection log drifts into local optima.
In human expert tacit knowledge, "what not to do" and "why this works" matter as much as what works. If Genes keep only behavior-changing parts, agents may accumulate a "what works" checklist while losing the "reflection log"—knowing what worked, but never what almost worked or why something failed. Long-term, agents can go deeper in one direction but cannot cross paradigms, because paradigm shifts require not "more optimization" but "reunderstanding why."
This mirrors the finding in *Looping Is Not Reliability*: previously correct does not equal currently correct. If Genes only record what works, when the environment turns past winners into traps, agents have no reflection log to trace back why they chose as they did.
The Real Fork in Collective Intelligence
EvoMap's second experiment is the one that actually touches continual learning. 24 identically configured agents solved problems individually, distilling each experience into a Gene. The more a type of experience accumulated, the higher the probability of choosing similar problems next round. Each agent built its own track record.
Then the experiment did something interesting: randomly broke parts of the social network and let agents re-pick teammates.
Organization doesn't appear from nowhere. Whatever information the system exposes, agents grow matching connection patterns. Show them social ties, get cliques; show them capability and feedback, get result-oriented networks.
Academic work does nearly the same thing—AgentNet (arXiv:2504.00587) shows agents spontaneously differentiating specialties in network evolution, with connection weights reflecting collaboration strength. This direction is not EvoMap's alone.
But there's an unstated structural fork.
Will a result-oriented collaboration network self-reinforce into an oligopoly? High-scoring hubs get more tasks, accumulate more experience, score higher. Low scorers get no tasks, no experience, stay low. Standard Matthew effect. Real beehives have no "high-score individuals" monopolizing tasks—assignment depends on proximity and discovery, not historical accuracy.
EvoMap's GEP protocol is itself a centrally designed protocol—even "choosing teammates" is protocol-mandated. Strictly speaking, this isn't collective intelligence without a central brain; it's "protocol-before-emergence" collective intelligence. That's not a criticism—biological hive protocols are also encoded in genes, not emergent. But the question stands:
> 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—a few ever-more-specialist agents, everyone else degrading into routers?
I don't have the answer, but it points at a real fork. One possibility: oligopoly is correct—specialists specialize, routers pass information losslessly (like the worker/forager division in real hives). Another: oligopoly is a trap requiring anti-Matthew mechanisms (random perturbation, forced rotation, experience decay) to preserve diversity—like "disturbance maintains diversity" in ecology.
Protocol Before Emergence
One last observation. GEP is a pre-agreed six-step loop; even teammate selection is protocol-defined. So this is collective intelligence where protocol precedes emergence. Not a criticism—the bees' waggle dance and ants' pheromone trails are gene-hardcoded protocols. Protocol-before-emergence may be a necessary condition for collective intelligence—fully emergent protocols are uncontrollable in engineering and unobserved in biology.
But a deeper question: can the protocol itself continually learn?
GEP is a fixed six steps. If agents someday find six steps insufficient—needing an added "Reflect" or a dropped "Signal"—who decides? If the protocol cannot evolve, then "continual learning" only continues within the protocol's frame; capabilities outside the protocol are forever unlearnable.
This may be the deepest boundary of EvoMap's route. Genes let agents learn continually *within* the protocol, but the protocol is designed by the EvoMap team, not evolved by agents. A truly "self-evolving agent swarm" might need to make the protocol itself a Gene—letting agents modify their own learning protocol.
Which loops back to an old question: who writes the protocol for writing protocols? Doesn't that need a central brain again?
My Take
After reading EvoMap's experiments, my sense is: collective intelligence isn't "no central brain"—it's moving the central brain from runtime to design time. GEP is the central brain; it fixes the boundary of all runtime possibilities at design time. There's no central coordinator at runtime, but there is one at design time.
This parallels Gubernaut, which moves regulation out of model weights into architecture; EvoMap moves coordination out of runtime into design time. Both solve problems by changing levels.
The true end state of continual learning may not be "agents evolve their own protocol" but three layers each learning at their own granularity: design-time protocol + runtime experience + architectural organization. LoRA edits parameters, Genes edit experience, swarms edit organization—and protocols edit... what?
That question may be the most worth chasing on the continual-learning roadmap.
---
Papers & Projects:
*When the central brain moves from runtime to design time, collective intelligence emerges. But the brain at design time is the thing that most needs to keep learning.*