EvoTeam: Multi-Agent Collaboration via Evolving Teams

EvoTeam. Multi-Agent Collaboration via Evolving Teams. By Qinuo Cao and nine others, from Jilin University, the Nanjing University of Science and Technology, and one other institution. Published on the thirtieth of October.

LLM-based multi-agent systems solve complex tasks through collaboration among specialised agents. Existing methods improve these systems by refining each agent's prompts, skills and execution strategies based on task feedback. But better individual agents do not necessarily make a better team. Recent studies have therefore taken evolution up to the level of collaboration, using collective execution experience to adjust how the team is organised and how its agents interact. Across heterogeneous tasks, that is still hard. Existing approaches tend to confine team reorganisation within one shared structure, and they reuse interaction rules across team contexts that are not compatible.

EvoTeam is a collaboration-centric evolution framework. From execution experience, it evolves three things jointly: how the team is organised, the rules that govern interaction, and the skills of individual agents. The emphasis falls on the team. Collaboration is what the framework is centred on, and individual skills evolve alongside it rather than in its place.

It maintains a library of reusable teams. For a given task it either selects a team from that library or creates a new one, and it guides collaboration with interaction rules specific to that team. The two kinds of experience are kept apart. Collaboration experience accumulates only within compatible team contexts, so rules learned for one kind of team are not forced onto another. Individual skills, by contrast, remain reusable across teams.

Experiments across four benchmarks demonstrate the framework's effectiveness. The abstract does not name the benchmarks or report the figures, so the strength of that result cannot be judged from here.

The change is in what gets improved. Earlier work evolved the agents, then the collaboration inside a fixed structure. Instead of one structure stretched over every task, EvoTeam keeps many teams, each with its own way of working together, while what individual agents learn can still travel freely between them.

EvoTeam. Multi-Agent Collaboration via Evolving Teams. By Qinuo Cao and nine others, from Jilin University, the Nanjing University of Science and Technology, and one other institution. Published on the thirtieth of October. This is the long version: the whole paper rather than the abstract.

A multi-agent system splits a task among specialists: a planner, a searcher, a coder, a verifier. The obvious way to improve one over time is to let each agent learn from its own executions. The authors argue that this does not produce a better team. A wrong assignment of responsibility, an incomplete handoff or a missing verification step can undermine correct individual work. Newer methods do evolve the collaboration itself, but they tend to keep one shared team and carry its interaction rules everywhere. The question here is what happens when that one team meets tasks that need different kinds of collaboration.

The paper starts with a preliminary study. It takes Meta-Team, an existing collaborative evolution method, and compares evolving only on the target tasks against inheriting a team evolved elsewhere and continuing on the target. The source is either another benchmark, with an unsuitable team template, or another category in the same benchmark, with a compatible one. Both underperform target-only evolution on all three metrics. Prior experience did not help even when the template fit.

The trajectories show why. A team built for GAIA coordinates web retrieval and answer synthesis. Handed a LoCoBench task that asks for a privacy anonymization stage, its file agent gets stuck in a search loop and the run times out. The subtler failure is a rule. Learned on a diagnosis task, it tells the file agent to report its findings to the planner and then finalize. Inherited by an implementation task, that same rule ends the run before any code is written or tested. A handoff rule is not neutral knowledge. It encodes a stopping condition that is right for one kind of work and wrong for another.

EvoTeam keeps a global agent pool and a library of reusable teams. A team is not a fixed crew. It is a description of the collaboration requirements it supports, plus a candidate roster drawn from the pool. For each task, an LLM Team Selector checks whether some team covers the task's division of work and has the needed roles. Its prompt says outright that topic similarity alone does not justify reuse. If nothing fits, a Composer builds a provisional team, admitted to the library only after the task is done.

Within the chosen team, a Chairman recruits the smallest sufficient subset of the roster, assigns subtasks, and reassigns them when progress is blocked. The team's rules are injected into the agents' contexts as soft guidance. Each rule is scoped to one sender and one recipient, with a trigger, and works as an information contract: what evidence, uncertainty and verification a handoff must carry. If no rule applies, the agent communicates directly.

After execution, three reflectors read the traces. The Team Reflector reads the whole composite trace and decides whether the roster supports the division of work, revising membership and description together. The Rule Reflector reads the handoff trace and creates, refines, retains or retires rules, but only inside the selected team. The Agent Reflector reads each agent's own trace and adds or revises prompt patches and skills, which travel with that agent to every team. The prompts repeatedly warn against generalizing from a single failure. When the evolution split is finished, everything is frozen, and the model's parameters never change at all.

The main backbone is GPT five point six Luna, with each score averaging three rollouts, across GAIA, two LoCoBench categories, LOCA-Bench and two BeyondSWE tracks. Evolving on each benchmark separately, EvoTeam averages fifty-eight point eight five, against fifty-eight point three for Meta-Team. That margin is narrow, and Meta-Team wins outright on LOCA-Bench, with sixty-nine point five eight against sixty-three point seven five.

The comparison that actually tests the thesis is the mixed stream: one hundred and sixteen evolution tasks from all four benchmarks, shuffled into one fixed order, with a single system evolving through them. Meta-Team's average falls, to fifty-five point five five. EvoTeam's rises, to fifty-nine point five eight, and it leads on all six metrics. Mixing task types hurt the shared-team method and did not hurt the scoped one.

A case study shows what that difference looks like. On a LOCA-Bench course task, Meta-Team's reflection replaced its accumulated notes, forty-five for the context analyst, forty-three for the implementer, thirty-one for the verifier, with a single note each. EvoTeam added one verification rule to the selected team, and all one hundred and ninety-eight rules in the other six families stayed unchanged.

The paper has a limitations section, with two items. It does not examine multimodal interactive environments. And because experience is stored as explicit guidance while model parameters stay fixed, its usefulness depends on the base model correctly applying that guidance. The evidence has boundaries of its own. Evolution splits are small: twenty tasks per track, sixteen for LOCA-Bench. No error bars are reported, and several margins are a point or less. The authors also caution that in the overwrite case, reflection came after evaluation, so the overwrite does not establish the cause of the score difference. And the hardest GAIA level stays low for every method, at best thirty-eight point four six percent.

The idea to carry away is that collaboration knowledge has a scope. A skill belongs to an agent and goes wherever the agent goes. A handoff rule belongs to a particular division of labour, and applied outside it can tell a team to stop before the work is done. Index the rules by team, choose teams by the shape of the collaboration rather than the topic, and a system can keep learning on a mixed stream of tasks without one task's lesson overwriting another's.