What happens when four AI agents update the same file?
By Huy Nguyen
Harvey tested a lead agent that divides a company review among smaller agents, then combines their findings into one report.
We recreated that pattern on AgentWS, a filesystem workspace for AI agents. Four agents started from the same revision and updated one customer-risk record. One checked customer approval, one the deadline, one revenue share, and one renewal status.
We wanted to see whether they could work in parallel without changing source files, losing saved work, or overwriting accepted findings. The overwrite risk is easy to miss. Two agents can start from the same revision and make different changes. If both publish a complete copy, the second copy can erase fields added by the first.
The shared-workspace workflow
This is a local prototype with synthetic company data. Harvey's public research inspired the workflow. The application defines how conflicts are handled.
Control what each agent can do
The agents need to read contracts, spreadsheets, and emails. Those source files should remain read-only.
AgentWS can give each session read access to source paths and write access to its assigned output paths. We tested this control separately. An agent tried to change a read-only contract. AgentWS denied the write while still allowing the agent to save its findings.
Source access stays read-only
Keep progress when an agent fails
An agent process may stop before it finishes. A replacement worker should be able to continue from the files already saved in its workspace.
In our local recovery test, the first worker saved part of its result and stopped. A replacement worker reopened the same workspace and continued from that file. This recovers saved filesystem state. It does not recover model reasoning that was never written to a file.
Continue from saved files
Prevent silent overwrites
All four agents started from revision 1. The contract agent published first and created revision 2. The other three proposals were now stale because they were still based on revision 1.
AgentWS rejected those three publish attempts as conflicts. It retained each complete proposal for later review and kept revision 2 as the accepted state.
Stale proposals remain available
Reconcile conflicting updates
The application opened a new workspace from the accepted revision 2 and loaded the three retained proposals. Its reconciliation rule copied each agent's assigned field into the latest record, then published revision 3. A final synthesis agent read revision 3 and published a cited report as revision 4.
The application combines the findings
The final report contained all four findings:
The customer must approve the deal.
The deadline is November 1.
The customer provides 35% of total revenue.
The customer's renewal plan is unclear.
The application decided how to combine the findings. AgentWS enforced file access, preserved each private workspace, detected stale publishes, retained conflicting proposals, and published the approved revisions.
Watch the full run, from the shared revision to the final report
Why not use Git?
We also rebuilt the scripted workflow with Git. It worked and produced the same final output as AgentWS. But a worktree was only the starting point.
To match the full workflow, the Git controller had to:
Manage persistent worktrees and reconnect saved work after a worker stopped.
Add operating-system access controls and isolate Git metadata.
Commit every proposal and preserve its branch.
Configure merge rules and protect the accepted branch from stale updates.
Export conflicting work for reconciliation.
AgentWS packages these responsibilities as workspace infrastructure. The application creates a scoped workspace, the agent uses normal file operations, and the application requests publication. AgentWS returns a clear result: published or conflict. It keeps the conflicting proposal available for review. The application still validates the content and decides how to reconcile it.
Git is a version control system. On its own, it does not manage the full workspace lifecycle for running agents. As agent workloads grow, a Git-based design moves further from the ideal solution. Teams end up building the missing workspace system around Git. AgentWS provides that system directly.
The four-agent model run above used AgentWS. The matched Git comparison used scripted workers on the same synthetic workflow.
Test setup: This was a local prototype with synthetic documents created for the test. Models produced structured findings, and separate worker processes wrote the files. Final verification replayed saved model responses instead of running fresh inference. We recorded the full setup and evidence for internal review.
If your agents update the same report, research file, or customer record, send us one real workflow. We would like to test it on AgentWS.
