concepts

The MARC Problem

Understanding the Multi-Agent Race Condition

When multiple AI agents operate on the same codebase, they create race conditions. Unlike normal software where race conditions crash programs, agents can produce syntactically valid but semantically broken code.

We call this the Multi-Agent Race Condition (MARC).

The Silent Overwrite

Imagine two autonomous agents working in the same repository:

  • Agent A (Senior) is tasked with refactoring the auth.ts file to improve performance.
  • Agent B (Junior) is tasked with adding a new 2FA feature to the same auth.ts file.

Because they are autonomous, they execute their tasks simultaneously.

Time T0: Agent A reads auth.ts
Time T1: Agent B reads auth.ts
Time T2: Agent A finishes refactoring and writes auth.ts
Time T3: Agent B finishes adding 2FA and writes auth.ts

The Result

Agent A's entire refactor is silently gone. Agent B, unaware of Agent A's work in memory, overwrote the file with the old code + the new 2FA feature.

No crash. No compiler error. The git diff looks fine to Agent B. The refactoring just vanished.

Why traditional locking fails

Traditional file locks (like flock or .lock files) fail in multi-agent systems for two reasons:

  1. Deadlocks: Agent A locks auth.ts and wants db.ts. Agent B locks db.ts and wants auth.ts. They both freeze forever, burning through your LLM tokens.
  2. Livelocks (Retry Storms): If an agent is told "File is locked, try again", it will spam the LLM API with repeated retry attempts, costing you money and stalling progress.

This is why Klock does not use standard optimistic locking or simple sleep-retries. Klock uses Wait-Die scheduling, a technique from distributed databases, to mathematically guarantee forward progress without deadlocks or token-burning loops.