Paper deep dive
Multi-agent Collaboration with State Management
Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 7/8/2026, 6:04:29 PM
Summary
This paper introduces STORM (STate-ORiented Management), a framework for multi-agent collaboration that addresses concurrent editing conflicts by enforcing local state consistency at write time. Unlike existing systems that rely on workspace isolation and post-hoc merging, STORM mediates agent interactions with a shared workspace, rejecting stale writes and providing conflict details for immediate retry. Evaluated on Commit0-Lite and PaperBench across multiple LLMs, STORM significantly outperforms single-agent and git-worktree baselines in both performance and cost efficiency, demonstrating that explicit state management is a more effective foundation for parallel agent collaboration.
Entities (19)
Relation Signals (12)
Taozhi Chen → affiliatedwith → Emory University
confidence 95% · Taozhi Chen 3 ... 3 Emory University
Mengyang Liu → affiliatedwith → Shanghai Jiaotong University
confidence 95% · Mengyang Liu 1,2 ... 1 Shanghai Jiaotong University
Yihong Dong → affiliatedwith → Peking University
confidence 95% · Yihong Dong 4 ... 4 Peking University
Xue Jiang → affiliatedwith → Peking University
confidence 95% · Xue Jiang 4 ... 4 Peking University
Zhenhua Xu → affiliatedwith → Peking University
confidence 95% · Zhenhua Xu 4 ... 4 Peking University
STORM → evaluateson → Commit0-Lite
confidence 95% · We evaluate STORM on Commit0-Lite and PaperBench across multiple LLMs.
STORM → evaluateson → PaperBench
confidence 95% · We evaluate STORM on Commit0-Lite and PaperBench across multiple LLMs.
STORM → enforces → Local State Consistency
confidence 90% · STORM manages agent states by mediating their interactions with the shared workspace, ensuring that each agent operates on a consistent view... We call this property local state consistency
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Recent advances in multi-agent systems have shown great potential for solving complex tasks. However, when multiple agents edit a shared codebase concurrently, their changes can silently conflict and inconsistent views lead to integration failures. Existing multi-agent systems address this through workspace isolation (e.g., one git worktree per agent), but this defers conflict resolution to a post-hoc merge step where recovery is expensive. In this paper, we propose STORM, i.e., STate-ORiented Management for multi-agent collaboration. Specifically, STORM manages agent states by mediating their interactions with the shared workspace, ensuring that each agent operates on a consistent view of the codebase and that conflicting edits are detected and resolved at write time. We evaluate STORM on Commit0 and PaperBench across multiple LLMs. STORM outperforms the git-worktree-based multi-agent baseline by +18.7 on Commit0-Lite and +1.4 on PaperBench, while achieving comparable or better cost efficiency. Combined with single-agent runs, STORM reaches highest scores of 87.6 and 78.2 on the two benchmarks respectively, suggesting that explicit state management is a more effective foundation for multi-agent collaboration than workspace isolation. STORM can also be plugged into any multi-agent system seamlessly.
Tags
Links
- Source: https://arxiv.org/abs/2605.20563v1
- Canonical: https://arxiv.org/abs/2605.20563v1
Trouble viewing inline? Open PDF directly →
Full Text
61,675 characters extracted from source content.
Expand or collapse full text
Preprint, May 2026 Multi-agent Collaboration with State Management Mengyang Liu 1,2 , Taozhi Chen 3 , Zhenhua Xu 4 , Xue Jiang 4 , Yihong Dong 4 1 Shanghai Jiaotong University 2 Cortices AI 3 Emory University 4 Peking University mengyangliu912, chentaozhi313, EthanDongyh@gmail.com Abstract Recent advances in multi-agent systems have shown great potential for solving complex tasks. However, when multiple agents edit a shared codebase concur- rently, their changes can silently conflict and inconsistent views lead to integration failures. Existing multi-agent systems address this through workspace isolation (e.g., one git worktree per agent), but this defers conflict resolution to a post-hoc merge step where recovery is expensive. In this paper, we propose STORM, i.e., STate-ORiented Management for multi-agent collaboration. Specifically, STORM manages agent states by mediating their interactions with the shared workspace, ensuring that each agent operates on a consistent view of the codebase and that conflicting edits are detected and resolved at write time. We evaluate STORM on Commit0 and PaperBench across multiple LLMs. STORM outperforms the git-worktree-based multi-agent baseline by +18.7 on Commit0-Lite and +1.4 on PaperBench, while achieving comparable or better cost efficiency. Combined with single-agent runs, STORM reaches highest scores of 87.6 and 78.2 on the two benchmarks respectively, suggesting that explicit state management is a more ef- fective foundation for multi-agent collaboration than workspace isolation. STORM can also be plugged into any multi-agent system seamlessly. 1 . 1 Introduction Multiple LLM agents working in parallel can solve tasks that are too large for any single agent to finish within its iteration budget (Dong et al., 2024; Qian et al., 2024; Hong et al., 2024; Geng and Neubig, 2026; Qu et al., 2026). In software engineering, agents can implement different modules concurrently; in scientific research, they parallelize experimental setups. But running agents in parallel on a shared workspace raises a question: when one agent edits a file, how do we know that its assumptions about the rest of the codebase are still valid? We treat this as a state management problem. An agent interacts with its workspace through file reads and writes. When it modifies a file, its reasoning depends not just on that file but on context from other files it has read (dependencies, interfaces, specifications). The edit is only safe when those context files have not changed since the agent last read them. This is a local consistency requirement: the agent does not need a frozen snapshot of the entire workspace, just assurance that the specific files informing its current edit are up to date. Existing multi-agent systems mostly avoid this problem by giving each agent its own workspace (e.g., a git worktree) and merging afterward (Geng and Neubig, 2026; Qu et al., 2026; Qin and Xu, 2026). Isolation prevents interference during editing but pushes all conflict resolution to the merge step, after agents have already committed to potentially incompatible designs. Textual merge conflicts are easy to spot; semantic conflicts, where both sides compile individually but break when combined, are harder, and current tooling cannot resolve them automatically. In this paper, we propose STORM (STate-ORiented Management), a state management framework for multi-agent collaboration. STORM mediates each agent’s file reads and writes. Before accepting a write, it checks whether the agent’s view of the target file and its context dependencies is still 1 Our code is available at https://github.com/dreamyang-liu/STORM 1 arXiv:2605.20563v1 [cs.MA] 19 May 2026 Preprint, May 2026 current. If another agent has modified any of those files in the interim, the write is rejected and the agent receives the updated content so it can retry from a correct baseline. Our main contributions can be attributed as: 1.A formulation of multi-agent state management as file-level context consistency: an agent’s write is valid only if the target file and its read dependencies have not been modified since the agent last observed them. 2.STORM, an architecture-agnostic state management framework for multi-agent collabora- tion that enforces local state consistency at write time, detecting conflicts immediately and enabling agents to retry from a correct baseline without workspace isolation. 3.Empirical validation on Commit0-Lite(Zhao et al., 2025) and PaperBench(Starace et al., 2025) with Sonnet 4.6. On Commit0-Lite, STORM achieves 82.5% macro pass rate and 46.2% weighted pass rate, outperforming single-agent (66.4% / 20.7%) and GitWorktree (63.8% / 24.6%) and we observe similar gain on Deepseek and Qwen model. On PaperBench, STORM scores 74.1 vs. 72.7 (GitWorktree) and 68.7 (single-agent). 2 STORM Mainstream multi-agent systems give each agent its own git worktree (Geng and Neubig, 2026; Qu et al., 2026; Qin and Xu, 2026) so that agents cannot interfere with each other while working. The cost is paid later: once agents finish their individual task, their branches must be merged back together. If two agents edit the same file, or made incompatible design choices about a shared interface, the merge fails. Worse, because each agent worked in isolation without seeing what others were doing, these conflicts tend to compound. Agent A writes a helper assuming a certain signature; Agent B changes that signature in its own branch; code that depends on both is now broken in a way that neither branch exhibits alone. We avoid this by putting all agents in the same workspace. The key insight is that an agent does not need a globally consistent view of the entire repository to produce a correct edit. It only needs the files it has actually read to remain unchanged while it reasons. We call this property local state consistency and formalize it in Section 2.1. In practice, even with disjoint task assignments, agents sometimes need to edit the same file (e.g., two agents each implementing different functions in a shared module). Most of their edits do not interact, but at the boundaries where they do, agents need a way to exchange information. STORM addresses this with two mechanisms: write-time conflict control (Section 2.2), which rejects a write whenever the agent’s local view has gone stale and lets it retry with fresh context, and intent annotations (Section 2.3), structured comments that agents leave in the code so that when another agent reads the same file, it can see not just the raw code but the intent behind it, enabling coordination at these shared boundaries without explicit messaging. 2.1 Local State Consistency An LLM agent does not need a frozen snapshot of the entire workspace to produce a correct edit. It only needs the files it has actually read to remain unchanged while it reasons. We formalize this as local state consistency. Workspace and agents. Let the workspace be a set of versioned filesW = (f,v f ) | f ∈ F, wherev f ∈Nis the current version of filef. A manager agentMdecomposes a taskTinto sub-tasks τ 1 ,...,τ k and assigns each to an engineer agent a i together with a primary file set F i ⊆F : M : T −→ (τ i ,F i ,a i ) k i=1 ,where F i ∩ F j =∅ for i̸= j.(1) The disjoint assignment reduces but does not eliminate conflicts: agents may still read or edit files outside their primary set (e.g., a shared utility or a common import). Agent local state.As agenta i works onτ i , it accumulates a read snapshotS i recording every file it has observed and the version at observation time: S i =(g,v obs g )| a i has read g.(2) 2 Preprint, May 2026 Whena i issues a write to filefproducing new contentc ′ , its generation depends only onS i , the local context the LLM has seen, not on the full workspace state. This is the key asymmetry we exploit: correctness requires consistency of S i , not ofW . In practice, each taskτ i requires accessing (reading or modifying) a set of filesA i ⊆ Fthat may extend beyond the assignedF i . When two agents’ access sets overlap (A i ∩ A j ̸=∅), the shared files form a boundary where conflicts may arise. STORM only needs to coordinate at these boundaries, leaving the non-overlapping majority of work fully parallel. Write validity.A write(a i ,f,c ′ )is valid if and only if the agent’s local state is still consistent with the current workspace: ∀ (g,v obs g )∈ S i : v obs g = v cur g .(3) That is, no file thata i has read has been modified since its observation. A valid write is applied atomically: v f ← v f + 1 and the content of f is updated to c ′ . Conflict. A write is conflicting when Eq. 3 is violated. Two cases arise: •Direct conflict: the target file itself was updated (v obs f < v cur f ), meaning another agent wrote to f concurrently. •Stale dependency: a dependency fileg ̸= fwas updated (v obs g < v cur g ), meaninga i ’s reasoning may rest on outdated context. In both cases, STORM rejects the write and returns the current state, enablinga i to refreshS i and retry from a correct baseline. Section 2.2 details the mechanism. Figure 1 shows the architecture. A single manager agent reads the repository, partitions work into sub-tasks scoped to disjoint file sets, assigns each to an engineer, reviews diffs after engineers finish, runs tests, and commits accepted changes. Only the manager commits. Each engineer receives a scoped task (e.g., “implement all functions intensor_ops.py”) and accesses the workspace only through the STORM-mediatedfile_editor. Engineers do not communicate directly; coordination happens through the shared codebase and intent annotations (Section 2.3). 2.2 Write-time Conflict Control STORM enforces the validity condition in Eq. 3 via a mechanism inspired by optimistic concurrency control (Kung and Robinson, 1981). The key observation is that in a well-decomposed task, most concurrent edits touch different files; the system lets all operations proceed without blocking and only intervenes when a conflict actually occurs. Implementation. Each file maintains a monotonically increasing version counter (v f , starting at 1). Everyfile_editorread returns the content together withv f ; every write must declare the expected version. The STORM layer validates the write against Eq. 3 by comparing the agent’s full read snapshotS i to the current workspace state. If validation passes, the write is applied atomically (v f ← v f + 1). If it fails, the write is rejected. Rejection payload. On rejection, STORM returns: (1) the current content of the target file, (2) a unified diff showing what changed since the agent’s last read (for direct conflicts), and (3) a list of stale dependencies with their version deltas. This gives the LLM enough context to re-plan from the current baseline without needing to re-read every file. Reservation.After a rejection, a short reservation is granted to the rejected agent on the target file. This prevents repeated alternating conflicts where two agents each invalidate the other in a tight loop. 2.3 Intent annotations Version tracking catches file-level conflicts but not semantic ones. Two agents might implement the same helper with different signatures, or make incompatible assumptions about a shared data structure. To reduce this, engineers annotate their code with structured intent comments: 3 Preprint, May 2026 ManagerAgentManagerAgent Results Parallel Engineer Agents ... STORMManager SharedWorkspace (Same for All Agents) Implement Task Engineer 1 Engineer 2Engineer N ... Versioning Validation (Write) On SuccessOn Failure Read / Write Request Read / Write Request Response Read / Write Request Response Response Task Delegation Read / WriteRequest (file, expected_version, snapshot) Response (content, version, diff or latest content) File / Version Info lScan repository lCreate plan lAssign tasks lReview & commit lReview changes lIntegrate lCommit Work on the same shared workspace concurrently Each file has a monotonic version (v1, v2, v3, ...) ReservationCheckVersionCheck(Direct)Snapshot Validation (Transitive) Check if the file is reserved by another agent (up to 30s) Reservation = exclusive lock to prevent concurrent writes. Compare expected_version (with agent) with current_version (on disk). Mismatch = CONFLICT. Write to workspace, bump version (v+1). Return success. expected current Check all files in the agent’s snapshot (dependencies). If any version changed by others →STALEDEPENDENCY Agent’sSnapshot (atreadtime) CurrentVersions (atwritetime) Agentresolvesandretrieswiththelatestinfo. Return to agent: •Target file current content + diff •Stale dependency list (path, version, last modifier) utils.py def add(a, b): return a + b ... v12 core.py class Engine: def run(self): ... ... v8 models.py class Model: def predict(self): ... ... v6 Read / Write via STORM Implement Task Read / Write via STORM Implement Task Read / Write via STORM Figure 1: System architecture. The manager analyzes the repository, delegates tasks to parallel engineers, and commits their work. All engineers share one workspace; the STORM manager mediates file operations to detect and resolve conflicts. # engineer_1: validate numeric inputs before summing def add(a, b): if not isinstance(a, (int, float)): raise TypeError("a must be numeric") return a + b Each comment identifies the author and describes what the block accomplishes. Engineers preserve annotations left by other agents unless their task requires changing the annotated block. When another agent reads the file, these comments provide a lightweight channel for semantic coordination: agents can see what others have done and avoid duplicate or conflicting work. The convention is injected into each engineer’s system prompt automatically. 3 Experiments We evaluate on two agent benchmarks: Commit0-Lite(Zhao et al., 2025), and PaperBench(Starace et al., 2025). We compare five configurations across three LLMs (Claude Sonnet 4.6, Qwen 3.6 Plus, DeepSeek V4 Pro): (1)Single-agent with 100 iterations; (2)GitWorktree(Geng and Neubig, 2026), engineers in isolated worktrees merged after completion; (3)STORM, a manager with engineers sharing one workspace; and Combined variants that take the per-task best of single-agent and multi- agent runs. Commit0-Lite uses 4 engineers; PaperBench uses 2 engineers with 2 rounds of delegation each. Evaluation. For Commit0-Lite, we runpyteston the final workspace and report Score w (total tests passed / total tests) and Score (mean per-repository pass rate). For PaperBench, we use the Code-Dev subset following Geng and Neubig (2026) due to cost constraints: the LLM judge (Sonnet 4.6) grades only “Code Development” nodes in the rubric tree, evaluating whether the submitted source code correctly implements each criterion without requiring experiment execution. We report Score (mean per-paper judge score×100). For both benchmarks, we report Cost eff (total cost / Score, lower is better) and Time eff (total wall-clock minutes across all tasks / Score, lower is better). 4 Preprint, May 2026 Table 1: Aggregated results across Commit0-Lite and PaperBench Code-Dev. Best per model in bold, second best underlined. Commit0-LitePaperBench Score w ↑Score↑Cost eff ↓Time eff ↓Score↑Cost eff ↓Time eff ↓ Claude Sonnet 4.6 Single-Agent20.766.43.218.8 68.712.511.6 GitWorktree24.663.88.620.972.717.222.5 GitWorktree-Combined31.478.68.125.776.622.730.8 STORM46.2 82.56.316.874.112.624.1 STORM-Combined49.287.66.321.178.217.331.4 Qwen 3.6 Plus Single-Agent34.075.31.313.047.74.916.1 GitWorktree16.757.46.956.051.613.436.0 GitWorktree-Combined36.383.03.731.155.412.143.1 STORM61.4 70.52.512.555.08.221.0 STORM-Combined76.288.22.113.257.010.729.6 DeepSeek V4 Pro Single-Agent26.865.21.831.362.94.116.5 GitWorktree18.544.03.845.155.88.835.7 GitWorktree-Combined30.975.2 3.853.960.89.141.3 STORM32.3 63.23.039.066.59.735.5 STORM-Combined41.377.73.449.068.310.941.7 Implementation. All agents run on OpenHands (Wang et al., 2025). Multi-agent runs follow a two-round protocol: in the first round the manager decomposes the task and dispatches engineers in parallel (each with 80 iterations); in the second round it reviews outputs, runs tests, and may reassign failed sub-tasks for one retry. The manager gets 50 iterations total. Detailed setup is in Appendix A. 3.1 Main results Table 1 reports results on both Commit0-Lite (4 engineers) and PaperBench Code-Dev (2 engineers) across all three models. STORM achieves the highest weighted score on Commit0-Lite across all models (46.2, 61.4, 32.3 for Sonnet, Qwen, DeepSeek), with gains concentrated on large repositories with cross-file dependencies where shared-workspace coordination matters most. GitWorktree performs worst across the board, dropping up to 18 points below single-agent on Commit0-Lite. On PaperBench, STORM consistently outperforms both single-agent and GitWorktree for all three models: 74.1 vs. 68.7 single-agent (Sonnet), 55.0 vs. 47.7 (Qwen), and 66.5 vs. 62.9 (DeepSeek), demonstrating that the manager’s task decomposition and priority-driven delegation effectively covers more rubric criteria than a single agent working alone. The single agent wins on cost-efficiency across all models due to zero coordination overhead, but STORM closes this gap while achieving substantially higher scores. STORM-Combined (per- paper best of single-agent and STORM) is the top-scoring configuration for every model on both benchmarks, reaching 78.2 on PaperBench (Sonnet), 57.0 (Qwen), and 68.3 (DeepSeek), confirming that the two approaches are complementary: single-agent excels on papers where one focused agent can cover most criteria, while STORM’s parallel delegation captures broader coverage on complex multi-component papers. STORM also achieves better time-efficiency than GitWorktree on all models (e.g., 16.8 vs. 20.9 on Sonnet Commit0; 21.0 vs. 36.0 on Qwen PaperBench) because conflicts are resolved incrementally rather than in a costly merge step. Per-paper results are in Appendix C. 3.2 Scaling to More Engineers A common finding in prior multi-agent systems is that performance degrades as more agents are added (Geng and Neubig, 2026; Lin, 2026). The reason is straightforward: for a fixed-size task, splitting work among more agents means each agent’s sub-task becomes smaller, but the file coupling between sub-tasks increases. More agents need to touch shared interfaces, read overlapping files, and make mutually consistent design choices. Under worktree isolation, this coupling manifests as merge conflicts that grow combinatorially with the number of branches. STORM inherenetly avoid it 5 Preprint, May 2026 Figure 2: Scaling engineers with Sonnet 4.6 on Commit0-Lite. (a) Both test-based and repo-based scores improve monotonically from 2 to 8 max engineers, and the line shows the average number actually deployed. (b) Cost scales linearly with engineer count. (c) Wall-clock time remains roughly constant due to parallel execution. given conflicts are detected and resolved at write time, higher coupling leads to more frequent but individually cheap rejections rather than a catastrophic merge failure at the end. Each conflict is resolved in isolation while the agent’s reasoning context is still fresh, so scaling up agents does not increase the difficulty of final integration. Figure 2 shows the effect of increasing the maximum number of engineers from 2 to 8 on Sonnet 4.6 with STORM. Both the test-based score (overall pass rate) and the repo-based score (macro-average per-repository pass rate) improve: from 38.2% to 69.7% (+31.5) and 71.3% to 87.1% (+15.8), respectively. The gains are not uniform across the two transitions. Moving from 2 to 4 engineers yields +12.0 macro points but only +8.2 overall points, because the improvement concentrates on medium-sized repositories (cookiecutter40.9→98.6,imapclient16.5→89.1,jinja 0.0→47.7). Moving from 4 to 8 engineers yields a smaller macro gain (+3.8) but a much larger overall gain (+23.3), driven almost entirely bybabel(20.2→57.5) andjinja(47.7→66.5), repositories with thousands of tests and deep cross-file dependencies that benefit from aggressive parallelization. Notably, the manager does not always use all available engineers. The average number of engineers actually deployed is 2.0, 3.6, and 6.4 for max settings of 2, 4, and 8 respectively. Simple repositories (cachetools,deprecated,wcwidth) consistently receive only 2 engineers regardless of the maximum, avoiding unnecessary coordination overhead. The number of repositories solved at≥99% pass rate grows from 7 (max=2) to 8 (max=4) to 10 (max=8) out of 16. Cost scales approximately linearly with the number of engineers ($199→$292→$429), while wall- clock time remains roughly constant (∼13 hours total across all 16 repositories) because engineer tasks execute in parallel. The cost-efficiency ratio (dollars per percentage point of overall score) is stable at $5–6 per point across all configurations, indicating that additional engineers provide proportional value rather than diminishing returns at this scale. 3.3 Isolation Strategy Table 2: Effect of isolation strategy on Commit0-Lite with Claude Sonnet 4.6. MethodScore w ↑Score↑Cost eff ↓Time eff ↓ Single-Agent20.766.43.218.8 Soft Isolation24.065.47.729.1 GitWorktree24.663.88.620.9 STORM46.282.56.316.8 In Table 2, we compare isolation strategies on Commit0-Lite with Claude Sonnet 4.6 using 4 engineers. Prompt based soft isolation and git worktree isolation achieve similar results (Score w 24.0 vs. 24.6, Score 65.4 vs. 63.8), both improving over the single-agent baseline in weighted score (20.7) while 6 Preprint, May 2026 remaining comparable in unweighted score. This suggests that delegation alone provides gains on larger repositories where multiple agents can cover more test cases in parallel, but the choice between instruction-level constraints and physical branch separation has limited impact on final pass rate. STORM outperforms both isolation strategies (Score w 46.2, Score 82.5) despite using the same number of engineers. First, STORM detects conflicts at write time rather than deferring them: when an edit violates local state consistency (Eq. 3), it is rejected immediately, letting the agent re-plan while its reasoning context is still fresh. Soft isolation instead relies on instruction-level constraints that are frequently violated, causing silent overwrites, while worktree isolation defers conflicts to a merge step where multi-file resolution often fails. Second, because all engineers share a single workspace, any read returns the latest committed state, including other engineers’ recent changes. Agents working on adjacent modules naturally observe each other’s implementations and can adapt interfaces accordingly, whereas worktree isolation keeps engineers blind to concurrent progress until merge time, by which point incompatible decisions may have already propagated. GitWorktreeSTORMSTORM (k=8) 0 1 2 3 4 Conflict events / run 0.12 0.94 2.94 (a) Late-caught conflicts discard STORM runs Pre-commit conflicts Post-commit conflicts Pass rate LowMediumHigh Repo coupling stratum 20 30 40 50 60 70 80 90 100 Pass rate (%) 77.7 81.6 59.5 82.1 89.0 36.3 97.7 94.4 70.9 (b) Pass rate by coupling stratum Single-agentGitWorktreeSTORM 2 agents4 agents8 agents Number of parallel agents 0 10 20 30 40 50 60 70 Share of tasks affected (%) (c) Coupling grows with parallelism Overlap Dependency 0 20 40 60 80 100 Pass rate (%) 64.8 82.2 83.4 Figure 3: Analysis summary on Sonnet 4.6. (a) STORM surfaces conflicts pre-commit, while GitWorktree leaves most conflicts for late (post-commit/merge) resolution; late-caught conflicts are associated with lower final pass rates (blue overlay). (b) STORM’s pass-rate advantage over the single-agent and GitWorktree baselines grows with cross-file coupling. (c) Narrow task scopes are not always independent scopes: first-round overlap and dependency signals remain common, and rise withk. Quantities in (a) and (c) are proxy measurements derived from manager-review events and declared task scopes. 3.4 Further Analysis STORM helps by exposing invalid parallel work early. STORM’s benefit is converting hidden integration errors into explicit write-time feedback. As Figure 3(a) shows, on Sonnet 4.6 GitWorktree leaves most conflict events until post-commit merge while STORM surfaces them pre-commit at both k=4andk=8, and the configurations that catch conflicts early also achieve higher final pass rates. The effect is not that STORM eliminates conflicts, but that it relocates them from a fragile post-hoc merge to a cheap write-time check. GitWorktree produces 3.81 reviewed write attempts per run at 91.8% acceptance, versus 6.00 at 81.2% for STORM (k=4) and 10.25 at 67.1% for STORM (k=8); the lower acceptance reflects a stricter consistency filter rather than weaker engineering, and STORM still outperforms GitWorktree in final repository quality. STORM remains robust on high-coupling repositories where alternatives collapse.STORM’s advantage is sharpest where parallel coordination matters most. Stratifying repositories by a proxy coupling score (from task overlap, dependency signals, multi-file scope, and rejection evidence), STORM’s lead over GitWorktree widens from +15.6 points on low-coupling and +5.4 on medium- coupling subsets to+34.6points on the high-coupling stratum (Figure 3(b)), because GitWorktree collapses outright there (36.3%vs. STORM70.9%). STORM’s margin over the single-agent baseline remains positive across all strata (+20.0,+12.8, and+11.4points from low to high); it narrows in the high-coupling regime only because the absolute ceiling falls for every method, not because STORM loses its edge. Concretely, as coupling scales from low to high, STORM degrades gracefully (97.7% → 94.4% → 70.9%), whereas single-agent falls from77.7%to59.5%and GitWorktree plummets from82.1%and89.0%to36.3%: STORM is the only method that does not break down under coupling. The repository-level pattern agrees:marshmallowrises0.0% → 82.3%and imapclient 9.7%→ 89.1%(Table 3), precisely where branch-level isolation is most brittle. As a 7 Preprint, May 2026 result, STORM more than doubles the Sonnet weighted score of the single agent (46.2vs.20.7) and nearly doubles that of GitWorktree (46.2 vs. 24.6). Scaling is limited more by decomposition quality than by STORM itself. The diminishing returns of additional engineers come from decomposition, not STORM. As Figure 3(c) illustrates, STORM already produces narrow scopes: 91.4% ofk=4tasks are single-file, yet 50.0% still carry dependency signals and 21.7% of first-round tasks overlap another’s file scope. Atk=8, single-file share stays high (85.1%) while first-round overlap rises to 35.1%. First-round overlap correlates with rejected-review rate (r = 0.28overall,r = 0.78withink=8): once the manager can no longer partition the repository into disjoint units, additional engineers create contention faster than useful parallel work. Case study: pre-hoc coordination versus post-hoc recovery. A paired run onjinjamakes the aggregate pattern in Figure 3(a) concrete at the level of a single repository. Under GitWorktree (Figure 4a), four engineers work on isolated branches and the coupling aroundutils.pystays invisible until merge: the manager rejects the focus diff with an explicit merge conflict reason (red diamond) and the same engineer reworks the task in a second round inside the shaded recovery window before acceptance. Under STORM (Figure 4b, restricted to the coupling task set), the manager reasons about the same coupling at decomposition and instruction time: it packsutils.py andasync_utils.pyinto a single assignment and explicitly sequences downstream consumers against it (gold-outlined bars carry this interdependence reasoning); the focus task then passes on the first review and no rejection appears in the coupled task set. The two timelines describe the same mechanism from opposite sides, GitWorktree lets coupling surface post hoc at the merge boundary, while STORM converts the identical signal into a pre hoc coordination decision baked into how tasks are defined and ordered. In summary, the analysis suggests a clear interpretation of STORM. Its main contribution is not cheaper computation or perfect recovery from every rejected edit. Its contribution is to replace delayed, fragile integration with immediate consistency checks that make parallel collaboration substantially more reliable on the repositories where parallelism is most useful. The residual failure modes of STORM are further analyzed in Appendix D. 4 Related Work Multi-Agent CollaborationMulti-agent collaboration decomposes complex tasks into specialized roles (Dong et al., 2024; Qian et al., 2024; Hong et al., 2024; Wu et al., 2023). Compared with a single- agent workflow, a multi-agent system can separate planning, implementation, testing, debugging, and review (Tao et al., 2024; Li et al., 2025; Kumar et al., 2026). Existing work mainly studies role-based software development, repository-level issue resolution, and workspace-isolated parallel development. Self-Collaboration (Dong et al., 2024) first introduced the multi-agent framework for code generation (?). Subsequently, ChatDev and MetaGPT model software development as a structured workflow among specialized agents (Qian et al., 2024; Hong et al., 2024). MAGIS and SWE-Debate study multi-agent issue resolution on SWE-style benchmarks (Tao et al., 2024; Li et al., 2025). AgentForge adds execution feedback through Docker-based validation (Kumar et al., 2026). Git worktree is a common mechanism for workspace-isolated parallel agents. Systems such as Git Worktree, CORAL, and StatsClaw use git worktree to separate agent workspaces (Geng and Neubig, 2026; Qu et al., 2026; Qin and Xu, 2026). Each agent works in a separate branch or worktree, while shared memory or a central coordinator supports information exchange. Workspace isolation enables parallel exploration and reduces direct interference between agents’ code changes. However, git worktree only provides low-level workspace isolation. It does not solve task decomposition, dependency tracking, semantic conflicts, or merge selection. Different agents may edit related files under incompatible assumptions. Some errors may only appear after integration. Industry systems also report that optimistic concurrency control improves over lock-based shared-state coordination (Lin, 2026), but remains insufficient without hierarchical task decomposition. Therefore, worktree-based systems still require higher-level coordination, shared memory, review, and execution-based verification. State Management in Agentic SystemsAgentic systems require persistent state across multi-step interaction. The state may include conversation history, plans, tool outputs, execution feedback, 8 Preprint, May 2026 0510152025303540 Minutes Since First Relevant Event Manager E1 E2 E3 E4 R1 R1 Focus R1 R2 R2 R1 AssignmentCoupling-aware assignmentEngineer workFocus taskRejected reviewAccepted review (a) GitWorktree: post-hoc detection. 05101520 Minutes Since First Relevant Event Manager E2 E1 E3 E4 R1 R1 Focus R1 R1 (b) STORM: pre-hoc coordination. Figure 4: Paired run timelines onjinja; the legend in (a) applies to both panels. (a) GitWorktree exposes theutils.pycoupling only at merge review: the red diamond marks the rejected review, the shaded band the rework window, and Focus R2 the retry that is eventually accepted. (b) STORM detects the same coupling at decomposition time and co-assigns or sequences the dependent tasks (gold-outlined manager instructions carry explicit interdependence reasoning); the focus task passes on its first review and no rejection remains within the coupled task set. repository changes, and intermediate artifacts. Existing work manages agent state through reflection, memory, skill libraries, and execution traces (Shinn et al., 2023; Park et al., 2023; Packer et al., 2023; Wang et al., 2024; Hu et al., 2025). Reflexion and Generative Agents use reflection and episodic memory to improve later decisions (Shinn et al., 2023; Park et al., 2023). MemGPT manages long-term context through memory tiers (Packer et al., 2023). Voyager stores reusable skills as executable code, while HiAgent manages working memory with subgoals (Wang et al., 2024; Hu et al., 2025). However, state management remains difficult in multi-agent software development. Most existing methods focus on a single agent or a single memory store. Multi-agent systems must also manage local states, shared states, workspace states, and execution states. Git Worktree uses isolated workspaces and branch-and-merge coordination for asynchronous software engineering agents (Geng and Neubig, 2026). CORAL and StatsClaw use shared memory and isolated worktrees to support parallel execution (Qu et al., 2026; Qin and Xu, 2026). CodeCRDT instead coordinates agents through observable shared state with deterministic convergence (Pugachev, 2025). However, workspace isolation and shared memory do not guarantee state consistency, dependency tracking, or safe integration. Reliable multi-agent software development still requires explicit control over what state is stored, shared, updated, and used. 5 Conclusion We presented STORM, a state management framework that replaces workspace isolation with local state consistency for multi-agent collaboration. All agents share one workspace; writes are accepted only if the agent’s observed files remain unchanged, and intent annotations coordinate semantics 9 Preprint, May 2026 at shared boundaries. On Commit0-Lite, STORM achieves 82.5% macro / 46.2% weighted pass rate with Sonnet 4.6 (vs. 66.4% / 20.7% single-agent, 63.8% / 24.6% GitWorktree). On PaperBench Code-Dev, STORM scores 74.1 vs. 72.7 and 68.7. Results generalize across Qwen and DeepSeek, with STORM-Combined reaching 88.2 / 76.2 on Qwen. Scaling to 8 engineers improves score monotonically with constant wall-clock time. These results suggest that explicit state management is a more effective foundation for multi-agent collaboration than workspace isolation. References Cortices. Mission control for ai agents. https://cortices.io/. Yihong Dong, Xue Jiang, Zhi Jin, and Ge Li. Self-collaboration code generation via chatgpt. ACM Trans. Softw. Eng. Methodol., 33(7):189:1–189:38, 2024. Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. Chatdev: Communicative agents for software development. In ACL (1), pages 15174–15186. Association for Computational Linguistics, 2024. Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. Metagpt: Meta programming for A multi-agent collaborative framework. In ICLR. OpenReview.net, 2024. Jiayi Geng and Graham Neubig. Effective strategies for asynchronous software engineering agents, 2026. URL https://arxiv.org/abs/2603.21489. Ao Qu, Han Zheng, Zijian Zhou, Yihao Yan, Yihong Tang, Shao Yong Ong, Fenglu Hong, Kaichen Zhou, Chonghe Jiang, Minwei Kong, Jiacheng Zhu, Xuan Jiang, Sirui Li, Cathy Wu, Bryan Kian Hsiang Low, Jinhua Zhao, and Paul Pu Liang. Coral: Towards autonomous multi-agent evolution for open-ended discovery, 2026. URL https://arxiv.org/abs/2604.01658. Tianzhu Qin and Yiqing Xu. Statsclaw: An ai-collaborative workflow for statistical software development, 2026. URL https://arxiv.org/abs/2604.04871. Wenting Zhao, Nan Jiang, Celine Lee, Justin T. Chiu, Claire Cardie, Matthias Gallé, and Alexander M. Rush. Commit0: Library generation from scratch. In ICLR. OpenReview.net, 2025. Giulio Starace, Oliver Jaffe, Dane Sherburn, James Aung, Jun Shern Chan, Leon Maksin, Rachel Dias, Evan Mays, Benjamin Kinsella, Wyatt Thompson, Johannes Heidecke, Amelia Glaese, and Tejal Patwardhan. Paperbench: Evaluating ai’s ability to replicate AI research. In ICML, Proceedings of Machine Learning Research. PMLR / OpenReview.net, 2025. H. T. Kung and John T. Robinson. On optimistic methods for concurrency control. ACM Trans. Database Syst., 6(2):213–226, 1981. Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, and et al. Openhands: An open platform for AI software developers as generalist agents. In ICLR. OpenReview.net, 2025. Wilson Lin. Scaling long-running autonomous coding. Cursor Blog, January 2026. URLhttps: //cursor.com/blog/scaling-agents. Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Shaokun Zhang, Erkang Zhu, Beibin Li, Li Jiang, Xiaoyun Zhang, and Chi Wang. Autogen: Enabling next-gen LLM applications via multi-agent conversation framework. CoRR, abs/2308.08155, 2023. Wei Tao, Yucheng Zhou, Yanlin Wang, Wenqiang Zhang, Hongyu Zhang, and Yu Cheng. MAGIS: llm-based multi-agent framework for github issue resolution. In NeurIPS, 2024. 10 Preprint, May 2026 Han Li, Yuling Shi, Shaoxin Lin, Xiaodong Gu, Heng Lian, Xin Wang, Yantao Jia, Tao Huang, and Qianxiang Wang. Swe-debate: Competitive multi-agent debate for software issue resolution. CoRR, abs/2507.23348, 2025. Rajesh Kumar, Waqar Ali, Junaid Ahmed, Najma Imtiaz Ali, and Shaban Usman. Agentforge: Execution-grounded multi-agent llm framework for autonomous software engineering, 2026. URL https://arxiv.org/abs/2604.13120. Yihong Dong, Jiaru Qian, Haoran Zhang, Peixu Wang, Binhua Li, Zhi Jin, Yongbin Li, Ge Li, Xiaokang Yang, and Xue Jiang. From i/o to code with discovery agent, 2026. URLhttps: //arxiv.org/abs/2605.15334. Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: language agents with verbal reinforcement learning. In NeurIPS, 2023. Joon Sung Park, Joseph C. O’Brien, Carrie Jun Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. Generative agents: Interactive simulacra of human behavior. In UIST, pages 2:1–2:22. ACM, 2023. Charles Packer, Vivian Fang, Shishir G. Patil, Kevin Lin, Sarah Wooders, and Joseph E. Gonzalez. Memgpt: Towards llms as operating systems. CoRR, abs/2310.08560, 2023. Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models. Trans. Mach. Learn. Res., 2024, 2024. Mengkang Hu, Tianxing Chen, Qiguang Chen, Yao Mu, Wenqi Shao, and Ping Luo. Hiagent: Hier- archical working memory management for solving long-horizon agent tasks with large language model. In ACL (1), pages 32779–32798. Association for Computational Linguistics, 2025. Sergey Pugachev. Codecrdt: Observation-driven coordination for multi-agent llm code generation, 2025. URL https://arxiv.org/abs/2510.18893. Xue Jiang, Yihong Dong, Lecheng Wang, Zheng Fang, Qiwei Shang, Ge Li, Zhi Jin, and Wenpin Jiao. Self-planning code generation with large language models. ACM Trans. Softw. Eng. Methodol., 33 (7):182:1–182:30, 2024. Xue Jiang, Yihong Dong, Yongding Tao, Huanyu Liu, Zhi Jin, and Ge Li. ROCODE: integrating backtracking mechanism and program analysis in large language models for code generation. In ICSE, pages 334–346. IEEE, 2025. Yingwei Ma, Yongbin Li, Yihong Dong, Xue Jiang, Yanhao Li, Yue Liu, Rongyu Cao, Jue Chen, Fei Huang, and Binhua Li. Thinking longer, not larger: Enhancing software engineering agents via scaling test-time compute. In ASE, pages 3730–3741. IEEE, 2025. Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. Repocoder: Repository-level code completion through iterative retrieval and generation. In EMNLP, pages 2471–2484. Association for Computational Linguistics, 2023. Disha Shrivastava, Denis Kocetkov, Harm de Vries, Dzmitry Bahdanau, and Torsten Scholak. Repo- fusion: Training code models to understand your repository. CoRR, abs/2306.10998, 2023. Yangruibo Ding, Zijian Wang, Wasi Uddin Ahmad, Hantian Ding, Ming Tan, Nihal Jain, Mu- rali Krishna Ramanathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, and Bing Xiang. Crosscodeeval: A diverse and multilingual benchmark for cross-file code completion. In NeurIPS, 2023. Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, Jiazheng Ding, Xuanming Zhang, Yuqi Zhu, Yihong Dong, Zhi Jin, Binhua Li, Fei Huang, Yongbin Li, Bin Gu, and Mengfei Yang. Deveval: A manually-annotated code generation benchmark aligned with real-world code repositories. In ACL (Findings), Findings of ACL, pages 3603–3614. Association for Computational Linguistics, 2024. 11 Preprint, May 2026 Xue Jiang, Tianyu Zhang, Ge Li, Mengyang Liu, Taozhi Chen, Zhenhua Xu, Binhua Li, Wenpin Jiao, Zhi Jin, Yongbin Li, and Yihong Dong. Think anywhere in code generation. CoRR, abs/2603.29957, 2026. Mofei Li, Taozhi Chen, Guowei Yang, and Jia Li. Memcoder: Multi-dimensional evolving memory for private-library-oriented code generation, 2026. URLhttps://arxiv.org/abs/2604. 24222. Yihong Dong, Jiazheng Ding, Xue Jiang, Ge Li, Zhuo Li, and Zhi Jin. Codescore: Evaluating code generation by learning code execution. ACM Trans. Softw. Eng. Methodol., 34(3):77:1–77:22, 2025. 12 Preprint, May 2026 A Detailed Experiment Setup We evaluate on Commit0 (Zhao et al., 2025), a repository-level code implementation benchmark. Each instance is a real Python repository with its test suite intact but source implementations removed (replaced with stubs orpassstatements). The task is to implement the missing code so that the tests pass. We use the Commit0 Lite subset: 16 repositories spanning a range of domains and sizes. Several repositories require cross-file reasoning, making them difficult for a single agent and a natural fit for studying multi-agent collaboration. We also evaluate on PaperBench (Starace et al., 2025), a benchmark for evaluating AI agents on end-to-end research replication. Each instance is based on an ICML 2024 Spotlight or Oral paper. The task is to understand the paper, implement the required codebase from scratch, run experiments, and reproduce the key results. PaperBench uses hierarchical rubrics to evaluate fine-grained replication progress rather than only final execution success. These tasks require long-horizon planning, cross-file implementation, experiment execution, and result verification, making them a natural fit for studying multi-agent collaboration. Configurations.We compare five configurations across three LLMs (Claude Sonnet 4.6, Qwen 3.6 Plus, DeepSeek V4 Pro): (1) Single-agent with 100 LLM iterations; (2) GitWorktree (Geng and Neubig, 2026) with 4 engineers in isolated worktrees, merged after completion; (3) STORM with a manager and 4 engineers sharing one workspace; (4) GitWorktree-Combined; and (5) STORM- Combined. The Combined variants run both single-agent and multi-agent, keeping the per-test union of passed tests, but only invoking multi-agent on repositories where single-agent did not already achieve 100%. Implementation. All agents run on the OpenHands SDK (Wang et al., 2025) inside Docker containers. The manager gets up to 50 LLM iterations; each engineer gets up to 80 per task and can be reassigned once. During analysis, the manager recommends how many engineers to use based on repository complexity; for simple repositories it may use as few as 2. Evaluation usespytestwith --json-report; if the JSON report is unavailable we fall back to parsing terminal output. The total number of tests per repository is taken from the ground-truth counts in the Commit0 paper (Zhao et al., 2025). Metrics. We report Score w (weighted pass rate: total tests passed / total tests, dominated by large repositories) and Score (macro: mean of per-repository pass rates). For efficiency we report Cost eff (total dollars / Score w ) and Time eff (total minutes / Score w ), both lower-is-better. PaperBench. We use the PaperBench Code-Dev subset, which evaluates code development only and skips the reproduction execution step. The judge grades only “Code Development” nodes in the rubric. We use Sonnet 4.6 as the LLM judge. Due to the high per-run cost (20 papers per configuration), we report PaperBench results on Sonnet 4.6 agents. B Prompt templates We summarize the key prompts used in the manager-engineer protocol. The full prompt text is available in the released code. Manager scan instruction (excerpt): Start by exploring the repository structure to understand what your team needs to work on and identify which functions have top priority to be implemented (i.e., those withpassstatements). To explore the repository structure and dependencies: 1. Check the imports and the actual functions used in the files withpassstatements and review the relevant tests to understand the EXPECTED BEHAVIOR of the functions and the dependencies between the files. 2. Runpytest -collect-only -continue-on-collection-errorsto have a better understanding of the scope and the dependencies of this codebase. Collect all the undefined functions from the test collection errors and add them with clear docstrings and passstatements into the files and make a local commit. DO NOT make any changes to the functions with pass statements since those need to be implemented by the engineers. 13 Preprint, May 2026 Manager delegation. Manager delegation instruction (excerpt): Split the overall implementation work into up tokmajor tasks, balancing complexity and estimated effort as evenly as possible. Make sure the high dependent files are in the same major task. Try to split the major tasks at file level first; if a single file contains a disproportionately large amount of functions withpassstatements, you can delegate at the function level and assign non-overlapping sets of functions to multiple engineers. For each engineer, assign the first task that has the highest priority within their major task. When you provide instruction to each engineer, briefly summarize the relevant repository structure and the dependencies so they don’t need to re-explore the repository. Then clearly specify which file/functions to implement and explain the purpose of this task. If the assigned functions depend on other stub functions, include a brief description of what each dependency does. Engineer task prompt.Each engineer receives the repository structure summary, its assigned func- tions, dependency descriptions, the test command, and shared-workspace rules. The key constraint is shown below: Engineer task prompt (excerpt): You are a software engineer working on implementing a python code repository in a group. You are responsible for implementing the functions instructed by your manager (i.e., the functions with pass statements) and passing the unit tests. Shared Workspace: Your workspace isworktree_path. ALL engineers on your team share this SAME directory. DO NOT modify files that belong to other engineers. Only edit the specific files and functions assigned to you. Check before modifying any file to make sure another engineer hasn’t already changed it. Scope Discipline: You are ONLY responsible for implementing the functions listed below. If you see test failures caused by functions in OTHER files or functions NOT assigned to you, DO NOT attempt to fix them. Report the failure to your manager and move on. Multi-agent coordination: Every edit you make MUST include a one-line comment in the form# engineer_id: <short intent> IMMEDIATELY above the block you added or changed. If you see# <other-engineer-id>: ...comments, preserve both the comment and the block below it unless your task explicitly requires changing them. You are assigned to implement the following functions in the file:file_path:functions. After you finished the implementation, make sure it will not cause any hanging issues. Do NOT commit; the manager will review your changes and commit on your behalf. Manager review and reassignment. After each round, the manager checks commit status. For successful commits, it assigns the next task. For failed commits, it reassigns the same task. In the final review, the manager merges all engineers’ work, resolves integration issues (import mismatches, naming inconsistencies), and checks for hanging code (infinite loops, input() calls). Manager delegation output format (excerpt): "engineer_id": "engineer_1", "file_path": "path/to/file.py", "functions_to_implement": ["func1", "func2"], "instruction": "Implement the tensor storage layout. The TensorData class uses ..." C Full experimental results Tables 3–6 report per-instance results for all models. We highlight several patterns. 14 Preprint, May 2026 Table 3: Per-repository pass rate, cost, and time (seconds) for Claude Sonnet 4.6. Best pass rate per row in bold. Single-AgentGitWorktree (4 Eng)STORM (4 Eng) RepositoryRateCostTimeRateCostTimeRateCostTime babel0.64.39341.330.8330120.27.91678 cachetools100.00.7249100.02.6657100.01.5400 chardet99.77.07680.33.281722.118.72932 cookiecutter74.97.2195894.324.2254898.624.85234 deprecated100.01.169894.71.4528100.03.4898 imapclient9.72.6314137.86.3169889.124.93736 jinja0.04.76655.829.2333247.139.33733 marshmallow0.05.9115060.931.7316282.332.83896 minitorch70.46.8209353.016.1233770.435.94439 parsel100.06.3156893.24.31202100.011.01974 portalocker100.07.22273100.08.81741100.011.11727 pyjwt100.03.57165.82.2639100.018.61783 simpy58.60.5210978.66.21627100.021.92655 tinydb99.52.594099.510.3135399.511.11474 voluptuous49.74.2362196.032.3492890.625.99181 wcwidth100.01.5442100.02.4956100.02.9869 Table 4: Per-repository pass rate, cost, and time (seconds) for Qwen 3.6 Plus. Best pass rate per row in bold. Single-AgentGitWorktree (4 Eng)STORM (4 Eng) RepositoryRateCostTimeRateCostTimeRateCostTime babel3.63.717090.22.055774.230.15502 cachetools100.00.6487100.03.2966100.02.2927 chardet99.73.0115999.73.296638.812.12350 cookiecutter38.73.0148536.58.6423456.49.23733 deprecated100.01.01135100.03.82369100.02.11124 imapclient100.02.311930.012.1480144.619.24441 jinja98.80.63660.02.67440.02.6744 marshmallow28.53.927140.015.1310623.77.72386 minitorch33.94.3166452.28.0246330.45.41551 parsel100.01.45916.31.154682.010.73239 portalocker83.30.73623100.04.08099100.05.94074 pyjwt97.34.3186689.214.86453100.013.93814 simpy76.43.8313251.412.8892681.48.73528 tinydb88.13.0136599.59.4294096.07.03550 voluptuous55.74.5134683.210.92491100.012.22685 wcwidth100.03.92599100.04.56393100.04.02544 STORM excels on cross-file repositories. The largest gains over both baselines come from repositories with heavy inter-file dependencies. On Sonnet,marshmallowjumps from 0.0% (single) and 60.9% (GitWorktree) to 82.3% under STORM;imapclientfrom 9.7% / 37.8% to 89.1%; andjinjafrom 0.0% / 5.8% to 47.1%. On Qwen,babelshows the most dramatic improvement: 3.6% (single) and 0.2% (GitWorktree) to 74.2% under STORM, demonstrating that shared-workspace coordination is critical for large, tightly coupled codebases. Single-agent strengths. The single agent remains competitive on small, self-contained reposito- ries (chardet,deprecated,parsel) where decomposition overhead outweighs parallelism benefits. On Sonnet,chardetscores 99.7% single vs. 22.1% STORM, showing that STORM’s decomposition can occasionally hurt when the repository is better solved monolithically. PaperBench patterns. On PaperBench Code-Dev (Table 6), STORM leads on 11 of 20 papers, GitWorktree on 6, and single-agent on 3. STORM’s largest wins come on papers requiring substantial 15 Preprint, May 2026 Table 5: Per-repository pass rate, cost, and time (seconds) for DeepSeek V4 Pro. Best pass rate per row in bold. Single-AgentGitWorktree (4 Eng)STORM (4 Eng) RepositoryRateCostTimeRateCostTimeRateCostTime babel1.23.930780.77.3615319.34.96344 cachetools71.20.11275100.01.12016100.01.31561 chardet99.72.620440.30.99871.33.93824 cookiecutter69.54.3362734.34.1292735.13.02569 deprecated100.00.533089.90.3399100.01.62148 imapclient16.93.536229.73.2433749.16.46320 jinja29.35.033473.313.665315.811.76778 marshmallow38.65.2328249.012.8474547.99.35402 minitorch36.13.4363651.73.9261344.34.43018 parsel97.63.32861100.04.73434100.012.58645 portalocker36.10.1362197.22.5589497.23.13708 pyjwt88.84.4362591.94.2221481.16.36668 simpy73.63.2362552.96.6450766.46.94990 tinydb99.52.42188100.04.5308696.54.24873 voluptuous85.94.336210.0--67.815.26271 wcwidth100.00.735132.60.3277100.02.12487 code organization (what-will-my-model-forget: 99.8 vs. 82.9 single,lbcs: 95.6 vs. 84.1 single). GitWorktree wins on papers where independent sub-tasks map cleanly to separate files (sample-specific-masks: 98.2 vs. 72.8 STORM), suggesting that when task boundaries align perfectly with file boundaries, isolation incurs no penalty. Table 6: Per-paper scores, cost, and wall-clock time for Claude Sonnet 4.6 on PaperBench Code-Dev. Best score per row in bold. Single-Agent (100 iter)GitWorktree (2 Eng)STORM (2 Eng) PaperScoreCostTimeScoreCostTimeScoreCostTime sample-specific-masks93.928.40272198.238.81555572.822.646156 bam97.45.34183297.7110.97706797.914.273806 what-will-my-model-forget82.9207.31360194.7215.28314999.8315.793937 pinn81.042.22360091.120.61645969.610.585328 sequential-neural-score-estimation92.628.33206088.735.29441291.039.916699 mechanistic-understanding94.415.69255881.917.66440461.90.006246 test-time-model-adaptation58.55.75208481.436.87369480.840.424666 robust-clip51.121.03184378.434.59367782.645.454029 fre72.568.11143878.079.55297178.420.495448 stochastic-interpolants78.413.66190276.418.47242379.322.634888 adaptive-pruning43.634.99286372.745.88672472.826.605688 all-in-one87.327.88299172.046.90589472.620.666389 stay-on-topic-with-classifier-free-guidance67.522.92265170.429.61560469.238.314933 bbox43.834.22206168.046.35343850.512.445443 lca-on-the-line72.062.13179166.6147.78573075.725.934899 ftrl53.537.82196563.451.09550666.126.625302 rice41.044.08193459.776.31712261.970.256730 bridging-data-gaps42.15.37171952.935.81595867.943.244865 lbcs84.1137.75336946.7145.55672995.619.756491 sapg35.716.09271014.615.48156734.828.806434 D Failure analysis details The failure analysis clarifies the boundary of what file-level state management can and cannot guarantee, restricted to STORM runs atk=4andk=8. Failed tests are categorized from pytest traceback symptoms into coarse buckets: assertion or semantic failures, missing API or symbol failures, type or contract errors, not-implemented errors, and other runtime failures (Figure 5, left). These categories are directly derived from tracebacks, but they remain symptom labels rather than manually adjudicated root causes. 16 Preprint, May 2026 Table 7: Per-paper scores, cost, and wall-clock time for Qwen3.6-Plus on PaperBench Code-Dev. Best score per row in bold. Single-Agent (100 iter)GitWorktree (2 Eng)STORM (2 Eng) PaperScoreCostTimeScoreCostTimeScoreCostTime pinn72.51.64186077.45.99467181.24.926043 lbcs43.32.66213877.217.72656488.52.904631 sample-specific-masks78.72.35249975.94.89484768.73.204604 stochastic-interpolants74.71.63155371.74.79331376.82.472525 what-will-my-model-forget27.41.84278569.24.17545655.23.392079 mechanistic-understanding70.62.36253665.06.39637784.43.866889 bridging-data-gaps30.01.88236662.97.84607050.25.963078 lca-on-the-line52.12.90271259.217.85814042.95.083180 sequential-neural-score-estimation67.83.26334556.62.82854271.63.422344 stay-on-topic-with-classifier-free-guidance58.82.05300750.66.43474652.93.133420 bam76.72.72156550.55.40481976.99.876708 fre31.21.59132650.45.27362453.06.733556 ftrl25.22.31249148.711.43681343.77.183204 adaptive-pruning23.43.21191243.15.85556331.64.283885 test-time-model-adaptation54.42.66360040.64.15419164.77.113368 rice33.42.29170836.75.17409422.43.962147 robust-clip13.52.03126630.55.04420229.74.152035 all-in-one59.52.84261428.15.33607347.12.601480 bbox21.41.96171520.15.65625442.42.411248 sapg39.32.60322018.35.63700015.23.422967 Table 8: Per-paper scores, cost, and wall-clock time for DeepSeek-V4-Pro on PaperBench Code-Dev. Best score per row in bold. Single-Agent (100 iter)GitWorktree (2 Eng)STORM (2 Eng) PaperScoreCostTimeScoreCostTimeScoreCostTime sample-specific-masks82.81.79360090.87.22820082.87.717715 pinn87.42.07353688.46.79473088.94.663745 what-will-my-model-forget73.12.69360082.32.65553379.76.378477 lbcs72.52.01360178.03.73459695.85.646477 stochastic-interpolants81.31.22251369.03.57481360.24.515717 sequential-neural-score-estimation82.52.48187368.74.30597384.25.528880 bbox39.22.42360065.64.33413653.34.716289 bam91.94.37360065.35.57739979.16.487407 fre65.02.58211264.48.38805855.88.778355 all-in-one87.81.87357063.89.28680497.68.638035 test-time-model-adaptation60.22.34187562.92.86453357.23.615615 adaptive-pruning37.63.28360047.16.79818253.54.985644 bridging-data-gaps45.73.54360045.76.15603458.15.806667 ftrl41.52.80360045.14.81537743.68.776679 mechanistic-understanding76.12.42322642.82.53520488.38.056821 lca-on-the-line47.12.80340836.54.44641875.88.536330 robust-clip37.02.13263333.65.40613565.111.688752 stay-on-topic-with-classifier-free-guidance62.73.31257929.73.25739372.24.626227 rice51.83.30295428.12.82569620.36.457823 sapg34.12.1832258.63.24447419.23.519851 Run-level cause tags are likewise heuristic proxies (Figure 5, right). Incomplete API is inferred from missing-symbol or not-implemented failures. Scope drift is inferred when accepted writes modify files outside the task’s declared scope. Budget/runtime is inferred from explicit agent errors such as max-iteration or timeout failures. Accepted same-file overlap is inferred when multiple task ids have accepted writes to the same file in a failed run. Failed tests themselves are dominated by assertion mismatches, missing APIs, and type or contract errors, indicating that unsuccessful runs still produce substantial but behaviorally incorrect implementations. Among failed STORM runs, cross-module scope drift and accepted same-file overlap appear in nearly all failed cases, and budget or runtime failures remain common at bothk=4andk=8. These proxies explain why STORM is not sufficient by itself: many remaining failures arise after writes have already been accepted as file-version consistent. STORM can ensure that accepted writes are based on a current workspace state, but 17 Preprint, May 2026 it cannot guarantee that the chosen task boundaries are semantically correct, that independently accepted edits compose cleanly, or that agents complete within budget. STORM (k=4) STORM (k=8) 0 20 40 Average Failed Tests per Run 41.8 43.3 Failed-Test Symptom Mix Assertion/semantic Missing API/symbol Type/contract error Not implemented Other runtime 020406080100 Share of Failed Runs (%) Incomplete API Scope drift Budget/runtime Accepted same-file overlap Failed-Run Cause Proxies STORM-4STORM-8 Figure 5: Failure analysis for STORM runs atk=4andk=8. Left: average failed-test symptom mix per run, decomposed into assertion/semantic, missing API/symbol, type/contract, not-implemented, and other runtime failures. Right: share of failed runs in which each run-level cause proxy fires, covering incomplete API, scope drift, budget/runtime, and accepted same-file overlap. Table 9: Effect of intent annotation on Commit0-Lite with Claude Sonnet 4.6 (STORM, 4 engineers). MethodScore w ↑Score↑Cost eff ↓Time eff ↓ STORM (with annotation)46.282.56.316.8 STORM (no annotation)26.670.98.024.3 E Limitations Terminal bypass. STORM mediates thefile_editortool but not direct filesystem writes through bash (sed,echo >, Python scripts). A post-hoc diff mechanism detects these but cannot reject them preventively. No command coordination. Concurrent shell commands (e.g., two agents running formatters on overlapping files) are not serialized. Extending concurrency control to arbitrary terminal side effects remains open. File-level granularity.Two agents editing different functions in the same file trigger a false-positive rejection. Heavily shared files (e.g.,__init__.py) become serialization bottlenecks. Line-level or hunk-level tracking would reduce this at the cost of managing shifting offsets after each edit. F Extended Related Work Code Generation for Software Development LLM-based code generation has moved from function-level synthesis to broader software development tasks. Recent code generation agents can decompose tasks, write code, use tools, run tests, and debug failures (Jiang et al., 2024; 2025; Ma et al., 2025). Repository-level methods further retrieve and use cross-file context from existing projects, including APIs, dependencies, tests, and coding conventions (Zhang et al., 2023; Shrivastava et al., 2023). Benchmarks such as CrossCodeEval and DevEval show that realistic code generation requires cross-file reasoning and repository-level dependency understanding (Ding et al., 2023; Li et al., 2024). However, code generation alone is not enough for reliable software development. Real tasks often require long-horizon interaction, repeated testing, debugging, and revision. Existing methods mainly improve planning, retrieval, or generation quality (Jiang et al., 2026; Li et al., 2026). They provide limited support for multi-step collaboration, state control, and conflict management across agents. 18 Preprint, May 2026 Execution-grounded agents add test feedback to the generation loop (Kumar et al., 2026; Dong et al., 2025), but reliable coordination across long software development workflows remains an open problem. 19