Relic: From Multi-Agent Collaboration to Persistent Organizational Capability

Relic. From Multi-Agent Collaboration to Persistent Organizational Capability. By Hongyi Du and eleven others, from the University of Illinois Urbana-Champaign, Harvey Mudd College, and six other institutions. Published on the twenty-sixth of September. Its code repository is worked out: about two thousand source files, with a readme and a licence.

Agents working together in an organisation often collide. The abstract's example: one coding agent changes an interface in a repository, while another keeps building against the old version, and the existing tests quietly go stale. A conversation between them can settle that one episode. But the members of a team change. When they do, what keeps the lesson in force? The agents who argued it out are gone, and the ones who arrive have no reason to know the argument ever happened. Without somewhere for the lesson to live, the same collision can simply happen again.

Relic turns collaboration failures that keep recurring into protocols that the organisation owns and that can be executed. The lesson stops living in someone's memory of a past conversation and becomes part of how the team runs.

Members reflect on the work they can see, propose rules, and govern whether those rules are adopted. An adopted protocol binds four things to the runtime: its triggers, who is responsible, what evidence is required, and what happens on execution. Protocols stay open to revision, and to retirement. In one traced case, repeated friction at integration produces an interface-review rule. That rule then governs later pull requests, and is revised as the work goes on. The whole lifecycle is visible in that one trace: a recurring problem, a rule proposed in answer, adoption, enforcement on later work, and revision once the rule meets practice.

The controlled evaluation spans three hundred and sixty runs, over ten software workloads and three models. Against a matched structured team that lacks the protocol lifecycle, Relic lifts complete-contract delivery from fourteen point zero six percent to nineteen point seven six percent, a gain of five point seven one percentage points. All four verified production endpoints improve, in every model stratum.

Transfer to fresh members is tested next, which is the situation the opening question was about. Three conditions are compared, differing only in what the newcomers inherit. Behavioural correctness is twenty-five point four percent with no inherited protocol. With the same rules handed over as readable text it is thirty-four point six percent. With executable bindings it reaches forty-one point two percent, six point five points above text alone.

On the full CooperBench benchmark, after broken benchmark pairs are excluded, Relic solves three hundred and sixty-seven of four hundred and seventy-seven, or seventy-six point nine percent. The authors call this the best reported result among peer-structured systems. On the fixed subset of forty-eight same-model pairs, Relic also beats Solo, twenty-nine against twenty-six, reversing the coordination loss shown by the official peer baseline.

The fresh-member numbers carry the argument. Writing a rule down helps a newcomer. Binding it to the runtime, so that it triggers and demands evidence by itself, helps more. That is the sense in which collaboration experience becomes organisational state: something that keeps working after the members who produced it have gone.