Chiosa
AI & Agents

A supervisor helps coding teams rethink GPU kernels

3 min
Updated

In plain words

The paper introduces Evolving Agent Teams, a way to organize coding agents that write GPU programs. A supervisor watches their progress and can change who does which job and how they share information. A shared file system carries lessons and work from one team arrangement to the next.

The authors tested the system on four GPU kernel tasks. With the same token budget, the evolving teams beat a single coding agent on each task, though this does not mean they were faster on every individual workload.

The research

When coding agents work on a difficult GPU kernel, they can settle on an easier design and stop exploring harder alternatives. Can changing the team as the work progresses help it move beyond that plateau? The paper tests this question on four kernel optimization tasks.

Evolving Agent Teams has a supervisor reshape coding-agent roles and coordination as GPU kernel work progresses, using persistent records to guide each new team.

The authors compared Evolving Agent Teams with Claude Code, a single coding agent, on four GPU kernel tasks. Both received the same task description, reference kernel, test harness and token budget; the reported result for each setting was its best of two runs.

The evolving team outperformed Claude Code on all four tasks. On MLA paged decode, an additional-budget run reached a 1.21x geometric mean speedup over production FlashInfer across 47 production workloads.

The measure combines baseline-to-candidate latency ratios, so above 1 indicates faster aggregate performance. This supports a bounded conclusion: the team produced a faster kernel by that measure, not on every workload.

The main settings were run twice, and the paper reports the best result from each pair. Individual workloads can still be slower than their production baseline, and these run counts limit statistical conclusions.

What the evidence shows

  • The problem of settling

    Evolving Agent Teams is a framework for optimizing GPU kernels with coding agents. The paper asks whether a team that can change its organization during a task can address a recurring difficulty: agents may settle on an easier design and stop exploring harder alternatives.

    The authors illustrate this pattern in kernel optimization, so the findings concern these tasks rather than coding agents in general.

  • A team that can adapt

    The framework gives a supervisor responsibility for monitoring a team’s progress and diagnosing apparent plateaus. It can then change roles, how agents coordinate, or how they record and share knowledge.

    A persistent file system carries prior observations and artifacts into later team configurations, connecting these changes to the work already done.

  • The main comparison

    The main evaluation covered four GPU kernel optimization tasks on B200 and H100 GPUs. Under a matched token budget, Evolving Agent Teams outperformed Claude Code, a single coding agent, on each task.

    For each setting the authors report the best of two runs, so this comparison is evidence on the tested tasks, not a guarantee across workloads or repeated trials.

  • A production-kernel result

    On MLA paged decode, an additional-budget run reached a 1.21x geometric mean speedup over production FlashInfer across 47 production workloads. This measure combines baseline-to-candidate latency ratios across workloads; a value above 1 indicates faster aggregate performance.

    The result shows the team’s kernel surpassed the production baseline by that measure, while leaving room for individual workloads to be slower.

  • Evidence has boundaries

    A fixed four-role team reached 0.31x speedup on MLA decode, compared with 0.74x for the evolving team, suggesting adaptation may help. But source passages differ on the model version and do not establish matched token budgets for this ablation.

    Also, 43 of 100 Gated Delta Net workloads were slower than baseline in the best budget-controlled run, and each main setting had only two runs.

Deep

Next paperDynaFlow: Learning free-form multi-agent orchestration