Case study 09 / 10Internal

ATLAS

Running many AI coding sessions without collisions. I run several AI coding sessions at once, across products, design jobs, supervision and research, on one laptop. Without coordination they edit the same files, redo each other's work, and decisions get lost between sessions.

At a glance

12+work streams coordinated in parallel
409the answer to a conflicting claim from a live session
1list of everything waiting on my decision
Period
June 2026 – present
Role
Designed it and built it with AI coding agents; every coding session on the machine is instructed to report to it
Status
Internal, in daily use
Links
Not public
The coordination tab: live agent sessions, agents holding a claimed area, and work left hanging. Rendered from a copy of the board with a mock API and fictional projects; interface in Indonesian.

01Problem

I run several AI coding sessions at once, across products, design jobs, supervision and research, on one laptop. Without coordination they edit the same files, redo each other's work, and decisions get lost between sessions.

02What I built

A coordination board plus a simple, strict way of keeping every work stream's state on disk.

03How it works

  1. Check in, claim, release. Sessions check in, claim an area (a repository or path) before a large change, and release it when done. A conflicting claim from a live session is refused (HTTP 409). Shared notes per project carry context between sessions.
  2. Tiny and local. A zero-dependency Node.js server bound to localhost; viewable remotely through Cloudflare Tunnel behind Cloudflare Access.
  3. One status file per work stream. Rewritten — not appended — in a fixed five-part format: current position, decisions waiting for me, next steps, hard rules, references. Decisions go to a log, evidence to task reports. A script assembles one dashboard every hour.
  4. House rules. Nothing is deleted (quarantine plus ledger), files are snapshotted before being overwritten, credentials are never copied into notes.
Check-in, claim, release protocolSession A checks in and claims an area, the board accepts. Session B claims the same area while A is still live and is refused with HTTP 409, so it picks another area. A releases the area and signs off.Session ACoordination boardSession BPOST /checkin200 okPOST /claim repo/area200 claimedPOST /claim same area409 conflictPOST /claim other area200 claimedPOST /release200 okPOST /bye200 oksession A works on its area
Swipe sideways to see the whole diagram. The protocol every session follows. A second claim on a live area is refused, so the session picks another area.
Simplified mock-up of the same moment: three fictional sessions, one claim refused because a live session already holds the area.

04Results and scale

  • More than a dozen work streams coordinated in parallel; everything waiting on my decision appears in one list.

05Stack

  • Node.js
  • Cloudflare Tunnel + Access
  • Windows Task Scheduler
  • Python
  • Markdown
Next case studyWatercooler“An office that forgets”