Source: arXiv (Jun Nie, Yonggang Zhang, Qianshu Cai, Yiu-ming Cheung, Xinmei Tian, Bo Han) — 2026-08-05
Summary
EvolveNet tackles a different problem than most agent self-improvement papers: instead of one agent learning from its own runs, it lets many separate, data-local agent deployments each evolve their own copy of a shared "harness" — the code scaffold that builds context, calls tools, and verifies results — on their own workload, without sharing raw data. Only the resulting program edits get merged back into the shared harness, through a "scope-typed, evidence-guided program aggregation" step, since unlike model weights, code diffs can't simply be averaged and may directly conflict with each other. Tested across five settings — text-to-SQL, data-science coding, competitive programming, software engineering, and general agentic workflows — EvolveNet improved the shared harness in all five, with the biggest gains showing up when deployments were running genuinely different kinds of workloads.
Key Takeaways
- The core distinction from single-agent RL approaches like harness self-evolution: EvolveNet is explicitly multi-agent/federated — many independent deployments improve a shared harness concurrently rather than one agent improving alone.
- Privacy/decentralization by design: each deployment evolves its harness copy on its own local workload and never shares raw data — only the resulting program edits get sent back for merging, similar in spirit to federated learning but applied to executable code rather than model weights.
- The hard technical problem this solves: model weight updates from different sources can just be averaged together, but program edits from different agents can conflict outright — two deployments might edit the same function in incompatible ways. "Scope-typed, evidence-guided program aggregation" is the mechanism that reconciles this.
- Decoupling aggregation from raw-workload sharing means many evolutionary search processes can run in parallel across deployments without a serial bottleneck — no need to funnel all the data through one central trainer first.
- Tested across five very different domains — text-to-SQL, data-science coding, competitive programming, software engineering, and general agentic workflows — and improved the shared harness in all five.
- The largest gains appeared under heterogeneous deployments — i.e. when different agent instances were working on genuinely different kinds of tasks, the shared harness benefited more from pooling their edits than when all deployments were doing similar work.
Reel Script
Hook (18s)
What if a hundred AI agents, each working on completely different tasks, could improve one shared codebase without ever showing each other their data? That's the actual engineering problem this paper solves.
Core Concept (90s)
Most "agent self-improvement" research is about one agent getting better at one thing over time, usually through reinforcement learning on its own runs. EvolveNet asks a different question: what happens when you have many separate deployments of an agent — say, one team's agent doing text-to-SQL, another doing competitive programming, another doing general software engineering — and you want all of them to contribute to improving the same underlying "harness," the scaffold code that handles building context, calling tools, and checking results? The obvious approach in machine learning would be federated learning — everyone trains locally, then you average all their model weight updates together centrally. But here's the wrinkle: EvolveNet isn't evolving model weights, it's evolving actual program code — the harness itself, as an editable script. And you can't just average two pieces of code the way you average two sets of numbers. If one deployment rewrites a function one way and another deployment rewrites the same function a different way, those are conflicting edits, not two numbers you blend into a midpoint. So EvolveNet's real contribution is a merge step — described as "scope-typed, evidence-guided" — that looks at what part of the code each edit touches and what evidence justifies it, before deciding how to reconcile edits that might genuinely disagree with each other.
Hands-On (100s)
Picture the actual flow: a shared harness gets broadcast out to many agent deployments, each sitting on its own workload — its own data, never sent anywhere else. Each deployment runs its own evolutionary search locally, trying variations on the harness and keeping what works for its specific task. Because none of these deployments need to wait on each other or share raw data through a central bottleneck, all of these searches run concurrently — that's the "no serial bottleneck" part. Periodically, instead of shipping data back to a central server, each deployment ships back just its resulting code edits. The aggregation step then looks at what each edit's scope is — which part of the harness it touches — and what evidence supports it being an improvement, before deciding how to fold it into the next shared version. The researchers tested this setup across five distinct settings: text-to-SQL, data-science coding, competitive programming, software engineering, and general agentic workflows. The shared harness improved in every single one of those five settings. And notably, the improvement was largest specifically when the deployments were heterogeneous — running genuinely different kinds of workloads — suggesting the diversity of experience being pooled is itself the value, not just more of the same data.
Takeaway (25s)
If you're running agent deployments across different teams or workloads, the takeaway is concrete: you don't need to centralize data to get a shared harness that improves for everyone, you need a merge strategy smart enough to handle code conflicts, not just averaging. Worth watching if your org runs more than one agent deployment on different tasks.