Chaos in the Working Tree: How 20 Autonomous AI Agents Squeezed 969 Commits into a Single Git Repository Without a Lock Server

By the Tech & Infrastructure Desk
Published October 2023

Main Facts

In the modern landscape of distributed software engineering, convention dictates that scale requires isolation. Microservices, containerized clusters, isolated branches, and dedicated developer worktrees are the gold standard for preventing systemic collisions. Yet, between September 30 and the morning of October 2, an unorthodox and high-velocity experiment challenged these foundational assumptions.

A single Git repository—residing on one Windows machine, spanning 7,565 tracked files, and backed by a bulky 6.05 GiB pack file—absorbed a staggering 969 commits. At peak intensity, the system registered 107 commits within a single hour.

What makes this volume extraordinary is not just the throughput, but the authorship. These changes were not written by a distributed team of human engineers spread across different time zones. Instead, they were generated by approximately twenty separate automated agent sessions running concurrently. Each agent session owned a discrete operational slice of the digital ecosystem: one drafted content and posts, others maintained a Shopify application, monitored social media channels, or managed a freelance pipeline.

Most remarkably, this multi-agent swarm operated without a centralized lock server, without an asynchronous task queue, and without complex orchestration software. The entire concurrent operation was governed by a primitive, elegant architecture: just three rules written inside a single Markdown file.

While the system successfully processed nearly a thousand commits in less than forty-eight hours, the experiment also exposed the fragility of pushing single-machine version control systems beyond their design parameters. It laid bare the dangers of trusting standard error messages, the hazards of overlapping automated habits, and the fine line between chaotic success and catastrophic data corruption.

Chronology

The timeline of the multi-agent deployment reveals a pressure cooker of rapid scaling, near-misses, and protocol adjustments.

September 27: The First Warning Signs

Days before the heavy commit surge, the system experienced its first close call. An automated agent session, having recently restarted, navigated to a release clone and executed a routine git reset --hard command.

Under normal circumstances in a single-developer environment, this command is benign. However, in a shared working tree populated by asynchronous actors, a hard reset is a loaded weapon. Fortunately, no uncommitted work happened to reside in that specific area at that exact millisecond. Had the timing differed by even a few seconds, the command could have vaporized an afternoon’s worth of progress generated by another automated session. This near-miss prompted the first operational adaptation: a shift from relying on hard tools to establishing strict behavioral habits. Agents were instructed to check git log -1, inspect file modification times, and verify the absence of an index.lock file before touching any clone.

September 30, 10:00 PM: The Collision of Processes

As the system ramped up toward its weekend peak, the inevitable concurrency bottleneck struck. At approximately 10 p.m., an agent session attempted to write to the repository and hit a brick wall. The operation aborted, throwing a familiar fatal error message that has frustrated developers for over a decade.

Rather than failing silently, the system logged the collision and initiated a newly minted protocol: instead of panicking, the session paused for five seconds, retried the operation, and successfully pushed through on the second attempt.

September 30 – October 2: The Peak Surge

Over the next thirty-six hours, the repository entered hyperdrive. Automated agents flooded the system, pushing 969 commits into the exact same working tree on the same Windows machine. At its busiest hour, 107 distinct commits were processed. Path-scoped commits largely kept the agents out of each other’s way, transforming what could have been a chaotic index-shredding disaster into a functional shared-workspace pipeline.

October 1: The Autostash Hazard

Midway through the peak surge, a quieter vulnerability manifested. An agent session executed a routine pull using the command git pull --rebase --autostash.

The danger of --autostash in a multi-agent environment is profound: it does not merely tuck away the local session’s uncommitted changes; it sweeps up every uncommitted change present in the working tree, regardless of which agent or background runner generated them. At that moment, two background files were actively being rewritten. The automated restore failed, leaving behind two orphan autostash entries. While the raw content remained intact within the working tree, the incident forced an immediate protocol revision. Pulls were initially restricted to instances where a push was explicitly rejected, and within twenty-four hours, autostash was banned entirely. Agents were required to commit their own specific paths first, followed by a clean, unstashed git pull --rebase.

October 2: Discovery of the Contradiction

During a routine audit of the protocol documentation on the morning of October 2, an embarrassing architectural flaw came to light. The protocol Markdown file described the critical retry rule in two separate locations—using two different numbers. One section mandated a "wait 5 seconds, 3 tries" protocol, while another section, added later by a separate workflow, specified a "2-second gap, 3 tries" rule.

Because the actual contention windows were brief, both rules worked in practice. Yet, the discovery highlighted a chilling reality: the entire multi-agent swarm rested on the assumption that all actors were reading and obeying the exact same instructions. The document had contradicted itself for two days before being noticed. The error was rectified immediately, standardizing the rule to a 5-second wait across both sections.

Supporting Data

To understand the sheer weight of the experiment, one must examine the quantitative footprint left behind by twenty autonomous agents operating on a single host machine:

• Total Commits (Sept 30 – Oct 2): 969 commits.
• Peak Hourly Velocity: 107 commits in a single hour.
• Duration of Intensive Surge: Approximately 36 hours.
• Repository Scale: 7,565 tracked files.
• Storage Footprint: 6.05 GiB pack file.
• Active Agents: Approximately 20 distinct automated sessions.
• Infrastructure: 1 single Windows machine, 1 shared working tree, 0 lock servers, 0 queues.
• Governance Model: 3 rules written in a Markdown file.

Despite the massive file count and the multi-gigabyte pack size, Git’s internal mechanisms handled the storage load with relative grace. The system’s primary strain was not storage capacity, but temporal contention over the Git index.

Official Responses and Protocol Evolution

The architects of this multi-agent system have remained transparent about the trial-and-error nature of the deployment. Rather than relying on rigid, enterprise-grade orchestration tools, the operational framework evolved organically in response to failure modes.

The core of the system relies on the correction of standard developer assumptions. As demonstrated by Git’s default error messaging, version control software is fundamentally designed around a human-centric mental model: one user, one keyboard. When Git encounters a concurrent write collision, it generates the following advice:

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

In a single-user workflow, deleting the stale index.lock file is standard procedure. However, in a swarm of twenty automated agents, that lock almost never belongs to a crashed process; it belongs to a living agent actively committing work in the current fraction of a second. Following Git’s standard advice in this environment would guarantee data corruption, truncating active commits and wiping out database states.

Consequently, the operational protocol completely subverted native Git advice: Never delete the lock. Instead, agents were programmed to respect the contention, wait out the exponential backoff, and retry.

Furthermore, the discovery of the conflicting protocol numbers ("5 seconds" versus "2 seconds") led to a newfound appreciation for documentation minimalism. The project philosophy shifted toward a strict single-source-of-truth doctrine: One number, one place. Better to have the wrong number written once than the right one written twice.

Implications

What does a 969-commit, 36-hour multi-agent sprint on a single Git repository mean for the future of software development and AI orchestration?

First, it demonstrates that path-scoped autonomy is a powerful workaround for monolithic architectures. Because the twenty agent sessions largely operated on mutually exclusive file paths, the shared working tree effectively functioned as a shared index with segregated payloads. Contention was minimized not by complex distributed locking mechanisms, but by spatial separation of labor.

Second, the experiment highlights the dangerous gap between tool design and agentic execution. Traditional version control systems assume human latency. A human developer takes minutes or hours to make changes, meaning index collisions are rare anomalies. Automated agents operate on machine time, compressing human-scale workflows into millisecond intervals. When twenty agents attempt to interact with a system built for solitary human operators, standard assumptions break down instantly.

Finally, the experiment raises an obvious architectural question: Why not just give every agent its own worktree?

The shared tree survived this stress test purely because the agents respected their boundaries. The moment two independent agent sessions are tasked with modifying the exact same file simultaneously, a simple three-rule Markdown file will no longer suffice. At that threshold, passive coexistence fails, and active coordination becomes mandatory.

As software engineering increasingly shifts toward multi-agent AI swarms operating directly on codebases, infrastructure teams will be forced to choose between building heavy-handed distributed locking layers or accepting the chaotic, white-knuckle resilience of shared-tree concurrency. For now, twenty agents, one Windows machine, and three simple rules have proven that chaos can be managed—provided you never, ever delete the lock file.