What Happens When Four AI Agents Edit the Same File at Once? Is Git Really Enough?

When Multiple Agents Fight Over the Same File

In multi-agent system design, one question keeps coming up: if you want agents to share persistent state, why not just use Git? After all, Git excels at version management, branching, and conflict resolution — it seems like a natural fit.

A developer shared their hands-on experiment on Reddit. Their earlier argument was that the file system provides agents with a familiar interface for persistent state. But an interface is just the starting point — a real multi-agent system also needs complete infrastructure around access control, failure recovery, and concurrent modifications. So they designed a concrete experiment to test whether Git is actually sufficient.

The Experiment: Four Agents Rewriting the Same Risk Record

The experiment was inspired by a workflow from Harvey, a legal AI company — a small company acquisition review. Four agents read the same deal documents and each updated different fields within the same "client risk record."

The author ran this workflow two ways: once using AgentWS, a workspace system they built themselves, and once using protected Git worktrees to replicate the same state changes. Both approaches produced identical final records, but the engineering overhead required to get there was dramatically different.

The test covered three typical real-world scenarios:

• Unauthorized writes are blocked: Each agent is constrained by an access control list (ACL), and any file modifications outside its defined responsibilities are rejected outright.
• Mid-process failures are recoverable: When a worker crashes halfway through, the file changes it already made are preserved in the workspace. A replacement agent picks up from the saved progress rather than starting over.
• Concurrent updates aren't silently lost: Agents finish their tasks at different times, so stale updates can't quietly overwrite already-accepted work. All conflicting updates are retained for human review.

Git worktree is a built-in Git feature that allows the same repository to have multiple independent working directories on the file system simultaneously, each checked out to a different branch. In a multi-agent context, you can theoretically assign each agent its own worktree so they operate on isolated file copies without interfering with each other, then merge back into the main branch when done. This is the core mechanism behind the idea of "using Git for agent state sharing." However, worktrees only solve file isolation — they don't natively provide permission control (who can write which file), process-level failure detection and recovery, or fine-grained conflict arbitration across worktrees. All of that needs to be built on top of Git.

The Real Gap: How Much Do You Have to Build Yourself?

The core finding of the experiment isn't about which approach produced the correct final result — it's about "what I had to build additionally to achieve the same behavior."

The author points out that a Git worktree is just the starting point. To make it exhibit the three capabilities described above, they had to add: OS-level permissions, persistent worktrees, isolated Git metadata, proposal branches, protected update mechanisms, and conflict export functionality.

In other words, Git can track file versions, but it doesn't manage the complete workspace lifecycle of running agents. When you layer in all those missing capabilities one by one, you're effectively rebuilding a workspace system on top of Git.

The Access Control List (ACL) mentioned in the article is a fine-grained permission management mechanism: it maintains a list of "who can do what" for each resource (file, directory, or field), as opposed to the coarse-grained permissions in traditional Unix file systems that define access via owner/group/others triplets. In multi-agent scenarios, ACLs allow permissions to be bound to specific agent roles — for example, "the legal agent can only modify compliance fields, and the financial agent can only modify valuation fields" — automatically blocking unauthorized writes at runtime without relying on prompt-level constraints within the agents themselves. Git's permission model typically relies on the OS layer or hosting platforms (such as GitHub's branch protection rules) and does not provide field-level or operation-level fine-grained ACLs. This is a structural gap when using Git as an agent workspace.

Why Git Struggles More as Agent Workloads Grow

The underlying logic here is worth unpacking. Git was designed around the assumption that human developers commit code at relatively infrequent, explicit intervals — its branching, merging, and conflict resolution all presuppose human intervention. Multi-agent workflows are the exact opposite: high concurrency, asynchronous completion, potential interruption at any moment, and a need for programmatic permission boundaries.

As the number of agents and task frequency increase, Git-based designs drift further from the ideal. Teams eventually find themselves spending enormous effort "building the missing workspace system around Git" — permissions, recovery, concurrency governance — responsibilities that should belong to infrastructure end up being re-implemented repeatedly at the application layer.

The AgentWS the author is promoting packages these responsibilities into a unified workspace interface. It's worth noting that this perspective comes from a single source with a product to sell, and AgentWS's actual maturity and applicability still await broader validation. But even setting the specific product aside, the question this experiment raises is genuinely valuable.

This touches on a classic software engineering concept — impedance mismatch: when a tool's design assumptions fundamentally differ from the characteristics of its actual use case, forcing a fit produces large amounts of "glue code" and hidden complexity. Git's core design is optimized around the assumption of "humans committing at infrequent, explicit intervals": conflict resolution relies on human judgment, branch merging requires deliberate intent, and the permission model operates at the repository level. Multi-agent workflows are high-frequency, asynchronous, and programmatic — agents don't "think before committing," they write at any moment, can crash at any time, and need millisecond-level permission checks. The greater the impedance mismatch, the more additional code is needed to fill the gaps. The application layer ends up shouldering responsibilities that should belong to infrastructure, creating the "hidden engineering debt" the article describes.

Takeaways for Multi-Agent Engineers

For teams actively deploying multi-agent workflows, this experiment offers at least a few things to consider:

First, shared state isn't a simple matter of "reading and writing files" — it's a systems engineering problem involving access control, failure recovery, and concurrent conflict resolution. Second, making do with familiar tools like Git often creates hidden engineering debt that compounds as scale increases. Third, at the design stage, teams should explicitly decide where three categories of logic "live": permission boundaries, checkpoint-resume, and conflict arbitration — are they scattered across individual agents' prompts and code, or consolidated into a dedicated workspace layer?

The question the author closes with is precisely the key one: if you're running multi-agent workflows, where exactly does this logic live in your system today? It's a question everyone building agent infrastructure needs to answer seriously.