Coordinating agents
MEMORYFIELD
Project memory for AI tools
When eight AI agents edit the same workspace at once, they overwrite each other like eight people typing into a file without saving turns. I put a POSIX kernel advisory lock (fcntl.flock) at the write boundary, dropping parallel write loss from 186 of 200 updates to 0 of 200.
順番
同じ場所を書き換えるなら、順番を守って、前の人の変更を消さないようにしたい。
One Room Key for 8 Workers.
Competing unlocked writers (93% write loss) vs. POSIX kernel flock coordination (0% write loss)
Competing writers (unlocked · 186 / 200 lost)
Both workers read old state at once.
Overlapping writes race to disk.
186 of 200 updates silently disappear.
Coordinated writers (POSIX flock · 0 / 200 lost)
Workers line up for .bamboo.lock.
Acquire → read latest → write.
Release key so the next worker enters.
STEP 1 / 3 · Race ConditionELI5: Typing Over Each OtherML / Systems: Without a lock, 8 parallel workers read stale state simultaneously and overwrite each other on flush (186 of 200 updates lost).Plain English (ELI5): Eight people edit the same document without saving turns, so the last person to hit save erases everyone else's work.
Coordination schematic. The recorded test used eight workers with 25 updates each. Unprotected: 186/200 updates lost. Protected: 0/200 lost.
Coordinated-write benchmark, receipt 126a5298. Advisory locking requires cooperating writers.The race condition: 8 workers and 93% silent write loss
In a multi-agent workflow, Worker B can read stale workspace state while Worker A is halfway through an edit. When both agents flush their updates back to disk, the last writer silently erases the earlier agent's work.
Before picking a fix, I built a reproducible 8-worker stress harness (25 updates per worker, 200 total writes) to measure how badly unlocked agents collide on shared project memory.
Without a lock, competing writers lost 186 of 200 updates (93% write loss) to race conditions. With cooperating processes acquiring a shared POSIX kernel lock before each read-modify-write cycle, lost updates dropped to 0 of 200.
- UNPROTECTED UPDATES LOST
- 186 / 200
Eight workers, 25 operations each; one recorded stress test.
- PROTECTED UPDATES LOST
- 0 / 200
Same recorded test with cooperating processes acquiring the shared advisory lock.
One room key at the OS kernel boundary
Think of the lock like a single physical key to a shared project room: a worker must grab the key at the operating-system boundary (fcntl.flock on .bamboo.lock), read the latest state, write its update, and hang the key back up.
Because POSIX advisory locking requires cooperating processes, every registered agent wrapper enforces this acquire-read-write-release sequence. Uncooperative processes that bypass the wrapper remain outside its protection, and verifying the semantic quality of an edit still requires CPE and rubric gates.
Prompt instructions cannot stop two parallel processes from overwriting the same file. Concurrency belongs in the operating-system kernel, not the system prompt.
Trading a 19.73ms queue wait for zero lost updates
Serializing writes adds a tiny line at the door so agents take turns cleanly. In the 8-worker stress test, waiting for the shared lock added a 19.73ms median wait (21.25ms p95), a practically invisible pause compared to losing 93% of parallel work.
I report kernel lock wait time separately from incremental graph compilation (2.88ms p50) and model inference latency so systems bottlenecks never get muddied. Synchronizing live multi-cursor Figma variables or cloud storage requires its own distributed transport evidence.
- MEDIAN LOCK WAIT
- 19.73ms
Recorded eight-worker run; p95 wait 21.25ms.
- WORKERS IN THIS RUN
- 8
25 operations per worker. Larger runs need their own evidence.
ABOUT
I’m Matt Stenquist, a Product Design Engineer and former professional snowboarder. I started coding at nine, shipped modded hardware and games by 16, and turned pro by 22. A few broken bones and a gold tooth later, I design and code consumer apps, Figma component systems, and AI developer tools from scratch.
LEARN MORE