Decentralized Multi-Agent Coordination and Communication in Shared Codebases

Mediratta, Rishabh; Xiao, Lingyun; Stone, Peter; Biswas, Joydeep; Stengel-Eskin, Elias

ParallACT Decentralized Multi-Agent Coordination and Communication in Shared Codebases

Rishabh Mediratta^1*, Lingyun Xiao^1*, Peter Stone¹, Joydeep Biswas^1,2, Elias Stengel-Eskin¹

¹The University of Texas at Austin ²NVIDIA

^*Equal contribution

Paper Code & Data Dataset Explorer

Two agents, two requests, one codebase:
each change works alone, and together they fail, even when they talk.

Left: a single principal asks for case-insensitive sorting with a descending option, and a central planner splits it into two subtasks for agents A and B on a shared edit plan. Right: principal A asks for a case-invariant sort and principal B for descending order; each agent sees only its own request, and their standalone edits to the same sorted() call conflict.

Left: a central planner sees both requirements and coordinates edits to one sorting call.
Right: separate principals assign the requirements independently, each agent initially sees only its own request, and individually valid edits to the same call conflict when combined.

Abstract

Coding agents working in shared repositories may receive separate, independently-motivated requests from human developers, creating a setting that is multi-agent by necessity. When this scenario happens, their individual implementations may work separately but conflict when combined. To study this setting, we introduce ParallACT, a benchmark of orchestrator-free multi-agent coding tasks. ParallACT contains both complementary and contradictory tasks. In complementary tasks, each agent's task is separately useful and implementations must share an interface to be productively combined. In contradictory pairs, both agents' tasks require editing the same code in incompatible ways, and naively combining independent solutions fails to produce a useful implementation. We compare a single-agent oracle given the combined set of tasks against multi-agent settings that vary execution order, visibility, awareness of other agents, and access to a communication channel. We find that the oracle solves most tasks while parallel agents perform substantially worse. Their performance drop is notable for complementary tasks, but sharp (e.g., 62% → 16% for Claude Code with Claude Opus 4.8) for contradictory tasks where merged code typically satisfies only one specification, and the same gap appears in all six further configurations pairing two agent harnesses with three open-weight models. Simply telling an agent that a peer exists does not help significantly, and giving agents access to a communication channel recovers only a small part of the performance, at an additional token cost. ParallACT thus identifies and isolates a core challenge that will become more common as multi-agent coding by independent principals becomes standard, and provides a controlled test of which coordination strategies help, and at what cost.

Two requests, one codebase

Each instance consists of an initial repository state, two natural-language requirements, a reference implementation for each, and an evaluation test suite. Each requirement is assigned to its own coding agent and, by default, is disclosed only to that agent. Through code changes and, in some settings, communication, the agents must produce a single final repository state that satisfies both requirements. The reference implementations and tests are withheld from the agents, except in settings that explicitly grant test access.

Two requirements can interact in three ways within the initial repository:

Non-interacting: separate implementations can be combined correctly with only surface-level reconciliation.
Complementary: each task is useful on its own, but the two must agree on a shared interface or contract to pass an integration test; either implementation alone fails.
Contradictory: both tasks implement or modify the same code region in ways that fail when mechanically combined, but that can be reconciled to satisfy both.

ParallACT focuses on the last two families, because they require non-trivial coordination between agents.

Top: an instance's initial repository state and requirements A and B go to agents A and B, whose edits pass through a reconciler into the final repository state. Bottom: non-interacting edits to separate modules combine; complementary edits merge cleanly but B expects a dictionary where A returns a list; contradictory edits both rewrite the same argument slot of getObjects.

Top: each agent receives its own requirement and the initial repository; a reconciler (patch concatenation, Git merge, or a model-based resolver) combines their edits before the result is evaluated for joint correctness.
Bottom: (a) non-interacting, (b) complementary, and (c) contradictory requirements. Green text shows possible joint solutions.

The benchmark

155 instances

85 contradictory

70 complementary

27 hand-built seeds

11 repositories

ParallACT builds on SWE-Bench Pro. In every instance, requirement A is an original SWE-Bench Pro task and requirement B is a separately motivated counterpart that a different developer could be given, which merely happens to touch the same code. The 27 seed instances were built by hand; the other 128 were generated with GPT 5.6 Sol in Codex, using the seeds as in-context examples. Instances come from both the original (v1) and the revised (v2) SWE-Bench Pro release, on disjoint sets of source tasks, and span 11 open-source repositories in Go, Python, and JavaScript/TypeScript.

Every instance must pass a family-specific set of soundness checks, run against the reference patches and the tests. An instance that fails a check is revised and rechecked, or discarded.

Soundness checks. Contradictory instances: the initial state must fail both sides' tests, each patch alone must pass its own tests, the concatenated patches and the Git merge must fail the combined tests, and the joint solution must pass them. Complementary instances: each patch alone must fail the integration test, and both together must pass it.

Soundness checks: Contradictory instances must pass all five checks in the upper row; complementary instances must pass both checks in the lower row.

Coordination scenarios

Every instance is run under 19 scenarios (18 for complementary instances) that vary the schedule (when each agent acts), the observation model (what it sees of the repository and the other's work), and the communication model.

Single-agent references. The oracle gives one agent both requirements; the orchestrator gives it both but asks it to delegate each to a subagent.
Serial hand-offs. Agents edit the same workspace in turn: sequential (A→B or B→A) or reentrant (ABAB or BABA), seeing either only the current files (repo) or also the earlier agent's edit history (hist).
Parallel. Agents work at the same time from the same base, either unaware of each other, aware of a peer, or connected by a channel framed as free-form messaging or as explicit synchronization points, over a shared file or Redis. The communication oracle also shows each agent its partner's requirement.
Gold-test access. The oracle, or the parallel-unaware agents (contradictory only), may debug against the gold tests.

Parallel edits are combined by concatenation, Git merge, or a model-based reconciler, and a scenario passes if any of them yields passing code. Cost is measured in effective tokens (input + cache-write + 0.1 × cache-read + 5 × output) and reported relative to the same configuration's oracle.

Coordination strategies: a single agent implements A and B, optionally with tests; sequential A then B; reentrant A, B, A, B; and parallel agents with an optional communication channel whose edits go through a reconciler.

Coordination scenarios: Single-agent oracle with optional test access, sequential hand-off, reentrant turns, and parallel execution with optional communication and reconciliation.

Harnesses and models

We run seven configurations of agent harness and model. Claude Code with Claude Opus 4.8 is evaluated on the 85 instances built on SWE-Bench Pro v1. The other six pair each of two harnesses, Claude Code and Codex, with each of three open-weight models, Qwen3.8 Flash Next, DeepSeek V4 Flash, and GLM 5.3 Flash, served with vLLM and evaluated on all 155 instances. Every configuration is run under the full set of scenarios.

Key findings

Performance drops sharply in parallel. For Claude Code with Claude Opus 4.8, joint success falls from 62% (oracle) to 16% (parallel unaware) on contradictory instances and from 86% to 57% on complementary ones. The open-weight configurations fall from 60% to 19% and from 72% to 53% on average.
Gold tests alone do not close the gap. With gold tests the oracle reaches 98% on contradictory instances, but parallel agents with their own tests reach only 38% (96% vs. 32% for the open-weight configurations).
A single hand-off recovers most of the gap, but does not scale. Sequential A→B reaches 54% contradictory success for Opus at a similar cost; reentrant turns cost significantly more without raising joint success.
Awareness and communication help only marginally. Telling agents a peer exists does not significantly help, and messaging or synchronization recover only part of the gap at a higher token cost.
Post-hoc reconciliation recovers only a small part of the gap. The best parallel scenario with a model-based reconciler stays well below a single hand-off.
Agents discuss the right things but act on them poorly. They send early but read late, about a third of messages are never read, and even agreed designs fail on mismatched text, mutual delegation, or avoided edits.

Results

Joint pass rate (%) and cost (mean effective tokens relative to the same configuration's oracle, in the same family), as reported in the paper. Shading follows the paper: darker red is worse, darker blue is better. Among the deployable strategies, the top two pass rates per column are in bold. Column headings link to those runs in the explorer.

Claude Code with Claude Opus 4.8 (85 instances, SWE-Bench Pro v1)

	Contradictory		Complementary
Scenario	Pass	Cost	Pass	Cost
Upper bounds
Oracle	62	1.00	86	1.00
Orchestrator	58	1.58	77	1.18
Comm-Oracle	56	2.74	83	1.31
Oracle + Gold Tests	98	0.74	100	0.54
Parallel + Gold Tests	38	0.77	n/a	n/a
Deployable
Sequential A→B	54	1.18	77	1.12
Reentrant ABAB	50	1.88	80	1.49
Parallel Unaware	16	1.17	57	1.14
Parallel Aware	26	1.14	60	1.21
Parallel Message	20	1.42	63	1.43
Parallel Sync	22	1.63	71	1.43

Open-weight models served with vLLM (all 155 instances; Mean averages the six configurations)

	Claude Code						Codex
	Qwen		DeepSeek		GLM		Qwen		DeepSeek		GLM		Mean
Scenario	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost
Upper bounds
Oracle	48	1.00	46	1.00	71	1.00	66	1.00	68	1.00	60	1.00	60	1.00
Orchestrator	34	1.36	36	0.77	53	0.73	49	0.42	60	0.44	44	0.26	46	0.66
Comm-Oracle	35	1.53	46	1.70	54	1.32	60	1.72	61	1.94	33	1.32	48	1.59
Oracle + Gold Tests	94	0.64	95	0.58	98	0.65	98	0.71	99	0.57	94	0.53	96	0.61
Parallel + Gold Tests	33	0.77	28	0.67	29	0.61	29	0.80	33	0.60	39	0.70	32	0.69
Deployable
Sequential A→B	42	1.14	52	1.11	66	0.92	76	1.08	66	1.02	55	1.07	60	1.06
Reentrant ABAB	38	2.03	46	2.10	59	1.40	66	2.37	53	2.09	53	1.72	52	1.95
Parallel Unaware	15	1.07	12	1.07	16	0.94	20	1.04	26	0.92	25	1.05	19	1.02
Parallel Aware	14	1.07	15	0.96	18	0.91	20	1.05	25	0.90	20	1.04	19	0.99
Parallel Message	14	1.40	20	1.40	29	1.11	22	1.48	29	1.32	29	1.11	24	1.30
Parallel Sync	15	1.57	22	1.67	34	1.28	27	1.64	39	1.74	27	1.22	27	1.52

	Claude Code						Codex
	Qwen		DeepSeek		GLM		Qwen		DeepSeek		GLM		Mean
Scenario	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost	Pass	Cost
Upper bounds
Oracle	61	1.00	70	1.00	74	1.00	84	1.00	74	1.00	66	1.00	72	1.00
Orchestrator	51	0.94	51	0.68	64	0.62	66	0.40	60	0.37	60	0.26	59	0.55
Comm-Oracle	71	1.12	69	1.25	71	1.07	80	1.41	77	1.31	60	1.29	71	1.24
Oracle + Gold Tests	94	0.74	96	0.71	94	0.76	100	0.86	97	0.67	99	0.66	97	0.73
Parallel + Gold Tests	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a
Deployable
Sequential A→B	63	0.98	73	0.89	71	0.82	81	1.18	71	0.92	66	1.00	71	0.96
Reentrant ABAB	66	1.45	67	1.74	66	1.40	79	2.32	70	1.82	71	1.63	70	1.73
Parallel Unaware	49	1.03	57	1.10	56	0.94	56	1.17	50	1.00	50	1.07	53	1.05
Parallel Aware	46	0.97	59	0.96	66	0.87	69	1.16	63	1.01	47	1.24	58	1.04
Parallel Message	59	1.21	70	1.26	69	0.98	70	1.38	73	1.19	54	1.08	66	1.18
Parallel Sync	57	1.37	71	1.29	71	0.94	69	1.44	69	1.29	47	1.48	64	1.30

Results for all 19 scenarios, per-split numbers and significance tests are in the paper's appendix.

Explore the dataset

Browse all 155 instances, read both requirements side by side, and open any run from the seven configurations to see the agents' trajectories, the messages they exchanged, their code changes and the test results.

Dataset Explorer

BibTeX

@article{mediratta2026decentralized,
  title={Decentralized Multi-Agent Coordination and Communication in Shared Codebases},
  author={Mediratta, Rishabh and Xiao, Lingyun and Stone, Peter and Biswas, Joydeep and Stengel-Eskin, Elias},
  journal={arXiv preprint arXiv:2611.00314},
  year={2026}
}