FedRSI: Collective Self-Improvement through Harness Evolution

Language-model agents increasingly improve themselves by rewriting their own harness, the program that manages the context, memory, tools, and calls of a frozen base model. However, because each agent evolves within a private deployment, its improvements remain unavailable to other agents that could benefit from them. Existing agent federations do not close this gap. Almost all of them share a single kind of harness component, such as prompts, knowledge, or skills; the only one that shares the entire harness requires its server to read client code and to use labelled validation data; and all of them aggregate once or in synchronous rounds, which proceed at the pace of the slowest client. Therefore, we introduce FedRSI, to our knowledge the first protocol that converts private improvements to any part of the harness into shared executable modules while every client retains its data, its code, and its own pace. Clients export only prose mechanism cards. The server writes a work order for each proposed mechanism, reviews it for task-specific assumptions, and re-implements the mechanism from scratch within a shared harness. Each client adopts the shared modules for its own task only if they raise accuracy on local validation data, and a task-aware priority gives the reviewed shared modules precedence on all other tasks. Because a card refers to no particular version of the shared harness, the server aggregates as soon as a fixed number of new cards have arrived, so that clients whose items take from seconds to an hour never wait for one another. In a federation of three text clients whose tasks differ in domain, language, and output space, FedRSI exceeds independent evolution for every client on its own task and raises the macro accuracy by 4.9 points on the clients' own tasks and by 6.7 points on the tasks of the other clients; in a federation of three coding clients, it also exceeds independent evolution on the tasks of the other clients. Moreover, FedRSI achieves these gains without exposing client data or making any client wait: none of the exchanged cards or shared modules contains such data, whereas synchronous rounds would have kept the faster clients idle for up to 59% of a run.