💬 NLP

Multi-agent Collaboration with State Management

This paper introduces STORM, a state-oriented management framework that mediates multi-agent interactions to detect and resolve code conflicts at write time, significantly outperforming traditional workspace isolation baselines on coding benchmarks while ensuring consistent views of the shared codebase.

Original authors: Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong

Published 2026-05-21

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Problem: The "Kitchen Nightmare"

Imagine a busy restaurant kitchen where four chefs (AI agents) are trying to cook a massive, complex meal together. They are all working on the same set of ingredients and the same pots.

In the old way of doing things (called GitWorktree), the kitchen manager gives each chef their own separate, private kitchen.

Chef A makes a sauce in Kitchen A.
Chef B makes a soup in Kitchen B.
They never see what the others are doing.

When they are done, the manager tries to combine everything into one giant pot. Disaster! Chef A added salt to the sauce, but Chef B added salt to the soup, and now the combined dish is too salty. Or worse, Chef A changed the shape of the spoon Chef B needed. They have to spend hours trying to fix the mess after the cooking is done. This is called "post-hoc merge," and it's expensive and often fails.

The New Solution: STORM (The "Smart Kitchen Manager")

The authors propose a new system called STORM. Instead of giving chefs private kitchens, they all work in one shared kitchen, but with a very smart manager standing over their shoulders.

Here is how STORM works, using three simple rules:

1. The "Fresh Ingredient" Rule (Local State Consistency)

In the old system, a chef might grab a bag of flour, start mixing, and then realize another chef swapped the flour for sugar while they weren't looking.

STORM's Fix: Before a chef is allowed to pour anything into a pot (write a file), the manager checks: "Did anyone touch the ingredients you are using right now?"
If the answer is No, the chef cooks.
If the answer is Yes (someone else changed the flour), the manager stops the chef immediately. The chef has to look at the new flour and start their mixing again with the correct ingredients. This prevents the "salty soup" disaster before it happens.

2. The "Note on the Counter" System (Intent Annotations)

Sometimes, two chefs need to work on the same pot. In the old system, they might accidentally overwrite each other's notes.

STORM's Fix: Chefs are required to leave a sticky note on the counter (an "intent annotation") that says, "I am adding garlic here because the recipe needs it."
When the next chef looks at the pot, they see the note. They know, "Oh, Chef A is handling the garlic, so I won't touch that part," or "I see Chef A added garlic, so I need to adjust my spices." This lets them coordinate without needing to stop and talk constantly.

3. The "Instant Rejection" (Write-Time Conflict Control)

In the old system, chefs would finish their dishes, and then the manager would realize the soup and sauce didn't mix. Fixing it then was a nightmare.

STORM's Fix: If a chef tries to pour something that conflicts with what's already in the pot, the manager says "STOP!" instantly. The chef doesn't waste time finishing a dish that will be thrown away. They get the updated pot, fix their plan, and try again immediately.

What Happened When They Tested It?

The researchers tested this on two types of "cooking challenges":

Commit0: A challenge to fix broken code in existing software libraries (like fixing a broken recipe book).
PaperBench: A challenge to recreate complex scientific research papers from scratch (like recreating a Michelin-star meal from a description).

The Results:

Better Scores: The STORM team cooked much better meals than the "private kitchen" teams. On the software challenge, they improved their success rate by nearly 19 points. On the research challenge, they also scored higher.
Cheaper & Faster: Because they didn't waste time fixing huge messes at the end, they actually used less money and time per successful dish.
Scaling Up: If you add more chefs (agents) to the "private kitchen" system, it gets chaotic and fails. But with STORM, adding more chefs actually made the kitchen more efficient because the manager caught conflicts instantly, allowing everyone to work in parallel without crashing the system.

The Bottom Line

The paper argues that managing the state (keeping track of who changed what and when) is more important than isolating the workspace (giving everyone their own room).

Think of it like a group project:

Old Way: Everyone works on their own laptop, then tries to merge their files at the last minute. It's a mess.
STORM Way: Everyone works on the same document, but the system automatically pauses you if someone else is editing the paragraph you are looking at, forcing you to refresh and re-read before you type.

The result is a team that works faster, makes fewer mistakes, and produces a much better final product.

Technical Summary: STORM - State-ORiented Management for Multi-Agent Collaboration

Problem Statement

Recent advances in multi-agent systems (MAS) have demonstrated potential for solving complex tasks by distributing work among multiple Large Language Model (LLM) agents. However, a critical bottleneck arises when multiple agents edit a shared codebase concurrently. Existing approaches, such as those utilizing git worktrees (e.g., Geng and Neubig, 2026; Qu et al., 2026), isolate agents into separate workspaces to prevent interference. While this prevents immediate overwrites, it defers conflict resolution to a post-hoc merge step. This delay leads to two primary issues:

Semantic Conflicts: Agents may make incompatible design choices (e.g., changing a function signature) that compile individually but fail when combined. These are difficult to detect and resolve automatically.
Expensive Recovery: By the time conflicts are discovered during the merge, the agents' reasoning contexts are stale, making recovery costly and often resulting in integration failures.

The core challenge is maintaining local consistency: ensuring that an agent's edits are based on a valid view of the specific files it has read, without requiring a frozen snapshot of the entire repository.

Methodology: STORM

The authors propose STORM (STate-ORiented Management), a framework that replaces workspace isolation with local state consistency. Instead of isolating agents, STORM places all agents in a single shared workspace and mediates their file operations to ensure consistency at write time.

Core Mechanisms

Local State Consistency:
- An agent's state is defined by a read snapshot ( $S_i$ ), recording every file observed and its version at the time of observation.
- A write operation is valid only if the current versions of all files in $S_i$ match the versions observed by the agent. If any dependency file has been modified by another agent since the read, the write is considered stale.
Write-Time Conflict Control:
- Optimistic Concurrency Control: Inspired by Kung and Robinson (1981), STORM allows operations to proceed without blocking but validates them before committing.
- Validation: Before accepting a write, the system checks the agent's full read snapshot against the current workspace state.
- Rejection & Retry: If a conflict is detected (either a direct edit to the target file or a stale dependency), the write is rejected. The agent receives the current content, a unified diff, and a list of stale dependencies, allowing it to re-plan from a correct baseline immediately.
- Reservation: To prevent infinite loops of alternating rejections, a short reservation (exclusive lock) is granted to the rejected agent on the target file.
Intent Annotations:
- To address semantic conflicts (e.g., incompatible assumptions about shared interfaces), agents append structured comments (intent annotations) to their code.
- These annotations identify the author and describe the block's purpose. When other agents read the file, they can see these annotations to coordinate semantics and avoid duplicate or conflicting work, effectively creating a lightweight coordination channel without explicit messaging.

System Architecture

Manager Agent: Decomposes tasks, assigns sub-tasks to engineers, reviews diffs, runs tests, and commits changes. Only the manager commits to the repository.
Engineer Agents: Work in parallel on the shared workspace but interact with files only through the STORM-mediated file_editor. They do not communicate directly; coordination happens via the shared codebase and intent annotations.

Key Contributions

Formulation of State Management: The paper defines multi-agent state management as a file-level context consistency problem, where an agent's write is valid only if its observed files and dependencies remain unchanged.
STORM Framework: An architecture-agnostic framework that enforces local state consistency at write time. It detects conflicts immediately and enables agents to retry from a correct baseline without the need for workspace isolation.
Empirical Validation: Extensive evaluation on Commit0-Lite and PaperBench across three LLMs (Claude Sonnet 4.6, Qwen 3.6 Plus, DeepSeek V4 Pro), demonstrating that explicit state management outperforms workspace isolation.

Experimental Results

The authors evaluated STORM against Single-Agent baselines and GitWorktree (isolated) baselines.

Performance on Commit0-Lite (Code Generation)

STORM achieved a weighted pass rate (Scorew) of 46.2% and a macro pass rate (Score) of 82.5% with Claude Sonnet 4.6.
This significantly outperformed GitWorktree (24.6% / 63.8%) and Single-Agent (20.7% / 66.4%).
Scaling: Increasing the number of engineers from 2 to 8 improved scores monotonically (from 38.2% to 69.7% weighted), with wall-clock time remaining constant due to parallel execution.
Cost Efficiency: STORM achieved comparable or better cost-efficiency than GitWorktree, as conflicts were resolved incrementally rather than in a costly merge step.

Performance on PaperBench (Research Replication)

On the Code-Dev subset, STORM scored 74.1 with Sonnet 4.6, outperforming GitWorktree (72.7) and Single-Agent (68.7).
Combined Strategy: Taking the best result between Single-Agent and STORM (STORM-Combined) yielded the highest scores across all models (e.g., 87.6 on Commit0-Lite, 78.2 on PaperBench with Sonnet), suggesting the approaches are complementary.

Analysis of Failure Modes

High Coupling: STORM's advantage is most pronounced in repositories with high cross-file coupling. While GitWorktree performance collapsed on high-coupling tasks (dropping to 36.3%), STORM remained robust (70.9%).
Conflict Timing: STORM surfaces conflicts pre-commit, allowing agents to re-plan while their reasoning context is fresh. GitWorktree leaves conflicts for post-commit merge, leading to lower final pass rates.
Limitations: The paper notes that STORM cannot prevent all failures, such as scope drift (agents editing files outside their assigned scope) or budget/runtime limits. It also acknowledges that file-level granularity can cause false positives (rejecting edits to different functions in the same file).

Significance and Claims

The paper claims that explicit state management is a more effective foundation for multi-agent collaboration than workspace isolation. By shifting conflict resolution from a fragile, post-hoc merge step to an immediate, write-time check, STORM enables reliable parallel collaboration on complex, interdependent codebases.

The authors emphasize that STORM does not require perfect task decomposition or the elimination of all conflicts; rather, it provides a mechanism to handle conflicts gracefully and cheaply as they arise. The framework is designed to be plug-and-play, capable of being integrated into any multi-agent system to mediate file operations.

The results suggest that for software engineering tasks involving significant cross-file dependencies, the overhead of managing local state consistency is outweighed by the benefits of avoiding catastrophic integration failures and enabling scalable parallelism.