Why Git Cannot Coordinate Coding Agents

Executive Summary

Software engineering is undergoing a phase transition. Autonomous coding agents now generate syntactically correct code cheaply and fast. Yet engineering organization velocity has not scaled with them. Engineering throughput remains throttled because software engineering is fundamentally a distributed coordination problem, not a code-generation problem.

The industry's version control foundation — Git and GitHub Pull Requests (PRs) — was designed in 2005 for asynchronous, batch-oriented human turn-taking: human-paced review, text-based diff inspection, and merge-time conflict resolution on single-threaded branch queues. When applied to multi-agent swarms, this model breaks down in three ways:

1. Merge Conflict Explosions: Concurrent agents modifying related files collide at PR integration time.
2. Silent Semantic Divergence: Branch isolation conceals interface drift; agents write code against assumptions that a parallel branch has already invalidated.
3. Custodial Security Breaches: Traditional platforms demand central cloud hosting of proprietary source code and developer prompts, violating enterprise security boundaries.

The relay refuses a claim that overlaps a scope another actor already holds, so two agents do not hold overlapping leases on the same paths. That refusal is a property of the protocol, not a measured outcome: it covers textual collisions on leased paths, and it does not address semantic conflict, which the project records as an open research problem. Section 6 states what the runs on disk actually measured.

1. The Coordination Wall

1.1 The Asymmetry of Modern Software Engineering

In 2026, inference compute has made raw code authoring effectively free. An autonomous agent can analyze a repository, synthesize idiomatic TypeScript, and generate unit tests without a human at the keyboard.

However, the time-to-merge (T_merge) for non-trivial pull requests in production engineering teams remains bounded by:

While T_generation tends to zero, all other terms remain stubbornly human-bound or branch-bound. When multiple agents are deployed concurrently on a traditional repository, T_rebase and T_consensus grow with the number of parallel agents N.

1.2 The Fallacy of Branch-and-PR for Multi-Agent Workflows

Git's branch model was architected around three foundational assumptions:

• Human Latency: Humans write and review code on a human clock. Branch isolation is necessary so incomplete thoughts do not disrupt peers.
• Textual Diffs as the Review Interface: Code reviews are conducted by human eyes scrolling through line-by-line colored diffs.
• Optimistic Concurrency with Deferred Conflict Resolution: Developers branch freely and only resolve collisions during git merge or git rebase.

For AI agents, every one of these assumptions is inverted:

• Agents can inspect and review structured trees without a human reading pass.
• Text diffs without runtime context can lead to agent hallucinations during review.
• Deferred conflict resolution lets agents author extensive implementations on dead branches that can never cleanly merge.

2. The Stitch Collaboration Ontology

Rather than replacing Git's battle-tested object database, Stitch introduces a coordination ontology optimized for machine execution and verifiable human oversight.

2.1 Semantic Scopes and Non-Blocking Leases

Stitch moves collision handling from merge time to claim time through semantic leases. This covers textual collisions on the leased paths and symbols. It does not cover semantic conflict between separately leased scopes, which the project records as an open research problem.

• Scope Definition: A scope is a path pattern (for example path:src/core/) or a symbolic locator (for example symbol:src/api.ts#UserRouter).
• Atomic Leasing: When an agent claims or offers a task, the relay records a lease bound by time T_lease. Any concurrent claim overlapping that scope is rejected with scope_conflict.
• Lease Expiry: Claims expire on task release, on proposal acceptance, or when T_lease runs out, so an orphaned agent does not hold a scope forever.

2.2 Pre-Commit Draft Checkpoints

In traditional Git, sharing work in progress requires staging files, writing a temporary commit, pushing a remote branch, and opening a draft PR. Stitch introduces zero-side-effect checkpointing:

1. An agent captures the scoped working tree contents into a private Git tree object using temporary in-memory index manipulation.
2. The agent publishes only the resulting Git tree object ID and file summaries to the relay.
3. The peer agent resolves the tree locally via Git alternates or ref syncing (refs/jam/*), reviewing the live diff with stable code anchors before a single commit is created.

3. The Zero-Custody Trust Topology

Enterprise adoption of autonomous coding agents is heavily gated by security and compliance. Standard agent platforms require storing repository source code, AST embeddings, and model prompt transcripts in third-party clouds.

Stitch draws a zero-custody boundary. What stays in the local Git plane, and what crosses the relay wire:

Formal Boundary Invariant

Let R_local be the local repository state containing source tree S, commit graph G, and model prompts P. Let E be the set of events transmitted to the Stitch Relay:

The relay operates on cryptographic digests of the tree and on metadata predicates. The source tree and the model prompts are not among the fields it receives, so they are not in the relay's store to be read out of it.

4. The 6-Stage Autonomous Collaboration Lifecycle

Stitch replaces informal, unstructured chat between agents with a typed 6-stage lifecycle:

Stage 1: Semantic Claim & Offer

The host creates a session anchored to an immutable base commit. The host issues a task offer with a bounded scope to a guest actor. Acceptance atomically converts the reservation into an active lease.

Stage 2: Causal Async Q&A

When an agent encounters an interface ambiguity, it publishes a structured question referencing specific symbolic locators. The recipient provides a binding answer, which becomes a permanent causal parent in the session DAG.

Stage 3: Pre-Commit Draft Checkpoint

The guest captures an immutable tree OID of uncommitted work. The local index and working directory remain clean.

Stage 4: Local Anchor Review

The reviewer renders the diff locally using stitch_workspace and attaches anchored review comments targeting exact code blocks or proposal fields without uploading code.

Stage 5: Proof-Carrying Attestation

The author commits the changes and issues a change.proposed event. The reviewer independently pulls the commit, executes the test suite in its local isolated environment, hashes the output, and submits an immutable proposal.attested receipt.

Stage 6: Fast-Forward Integration

The host evaluates the decision gate. Once all required predicates (tests-passed, dependency consensus) are met, the host fast-forwards main directly to the verified commit.

5. Reactive Protocol: The SSE Stream Daemon

Early multi-agent prototypes relied on polling loops (stitch status inside a sleep loop), resulting in token waste, shell process pollution, and deadlocked turns. Stitch Jam implements a reactive Server-Sent Events (SSE) daemon:

• Universal Agent MCP Tool (stitch_wait_next): When an agent is waiting for peer actions, it executes a single non-polling tool call.
• Actor-Scoped Wake Routing: The relay monitors the event DAG and delivers wake notifications only when an event directly changes the calling actor's required next step.
• Turnaround Latency: The reactivity test asserts that a live SSE wakeup reaches a waiting agent in under 3 s (test/stitch-agent-reactivity.test.ts). That assertion is the only measured wake bound on record; no tighter figure has been recorded.

6. Comparative Analysis & Benchmarks

Measured: the 2026-08-08 A/B run

The table above compares designs, not stopwatch readings. One controlled A/B run exists on disk. Both arms ran the same task (exclusive-cursor) with two Claude Opus sessions each on 2026-08-08, and both arms passed the same acceptance test.

Measured: the 2026-08-23 hands-off run

A later run measured the protocol 0.2 client end to end with no human in the loop: two Claude Code sessions, one prompt each, and the full claim, question, answer, propose, review, attest, decide, integrate, verify loop driven entirely by the agents.

This is not a matched comparison with the table above, and three deviations keep it honest: it ran a different task than the 2026-08-08 pair; its agents ran under auto permission mode with the task's shell pre-allowed, while the 2026-08-08 arms paid every permission prompt as wall clock; and it used the newer protocol 0.2 client. Its pre-registered bar was the 2026-08-08 control arm's 19 min 44 s of wall clock, and it finished under that bar.

7. Conclusion & Roadmap

Git was built to liberate human developers from centralized version control. But in an era where software is authored collaboratively by fleets of autonomous agents, Git's human-centric assumptions create an insurmountable coordination bottleneck.

Stitch Jam is a candidate for that missing layer:

• Anchored to standard Git repositories.
• Zero custody of proprietary code and prompts.
• Proof-carrying review, and scope refusal at claim time instead of conflict resolution at merge time.

The future of software is not single-agent autocompletion. It is multiplayer, proof-carrying agent coordination.

Availability & Getting Started

Stitch Jam is live on npm and open for developer alpha testing:

# Start a session as host (any Git repository)
npx stitch-jam

# Join a session as collaborator
npx --yes stitch-jam join "https://jam.stitchrepo.com/#..."

• Documentation & Architecture: jam.stitchrepo.com
• npm Package & Client Bundle: npmjs.com/package/stitch-jam
• Support & Enterprise Inquiries: support@stitchrepo.com