Atlas

The challenge

Atlas is local-first. It captures agent sessions on your machine, works offline, and sends nothing until you choose to sync. Team features need a cloud that respects that: one that accepts work pushed late, twice or corrected from flaky laptops, keeps every organisation's data apart, and lets several people and their agents work on the same task at once, without ever becoming something the desktop has to wait for.

My role and timeline

Atlas and its desktop app were created by Adib Mohsin. I joined to build its cloud: I scaffolded the server and wrote its system design on 12 July 2026, and have written 289 of its 297 non-merge commits since (97%, as of 12 October 2026), all 25 architecture decision records and the pipeline that deploys it. Teammates built the desktop's sign-in and sync clients against API contracts that live in the server repository.

1. Jul 2026System design; sign-in for the desktop and the web; organisations and roles; deploys to production from CI.
2. Aug 2026AI access with spend controls; team chat, calls and shared prompt drafts; Spaces, a realtime canvas.
3. Sep 2026Session Artifacts: agent sessions synced to the team, with timelines, comments, sharing and search.
4. Oct 2026Shared Threads (server live for every organisation on 4 October), webhooks, feature flags and billing. The desktop half of Shared Threads, also mine, is in review.

Architecture at a glance

The desktop stays the place where work happens; the cloud is where a team sees it. Everything runs on Cloudflare: Workers for the services, a Durable Object wherever something needs one consistent owner (a workspace's sessions, an organisation's chat, a shared thread), D1 for relational data, R2 for large bodies, and Queues for work that can happen later.

Four engineering decisions

1. Sync that can receive the same work twice

Invariant: a replayed push never duplicates what the team sees.

The desktop never waits for the network to capture a session, so uploads arrive late, out of order, repeated after a retry, or corrected. Instead of asking the client to send each change exactly once, the server makes every replay safe: the desktop mints each row's id and the server upserts by it; a content hash tells a replay (ignored) from a correction (applied); large bodies are stored once, under their hash. Each workspace has one Durable Object that owns its rows and re-checks access on every connection and push.

What it does not guarantee: ordering between corrections. A correction applies in arrival order, so a delayed older revision of a session's title or token totals can overwrite a newer one. Only two rules hold regardless of order: a finished tool call never reopens, and a session's last-activity time only moves forward. The desktop's sequence numbers are per machine, so they cannot order rows across devices; a per-row revision would close this gap.

Result: real data surfaced platform limits that unit tests had not. Importing a real desktop database (33,664 rows) sent a 4 MB push into the queue's 256 KB batch limit, and in production storage's limit of 100 bound parameters made every second session fail. Both were fixed on 21 September 2026. Separately, one batch of 100 tool calls spent 17.5 s waiting against 80 ms of CPU; a bounded pool cut 53 sequential waits to 6.

2. Shared Threads: people and agents on one task

Failure mode: two agents edit the same files and one silently overwrites the other.

A shared thread lets several people, each with their own agent, work on one task. The decision record weighs and rejects four simpler designs: a turn lease (one agent at a time), putting every agent on the shared live document (which risks silent breakage), merging inside the server, and a merge lock.

Three mechanisms, each for one problem: Git worktrees isolate agent execution, a CRDT (a shared data type that merges concurrent edits) keeps people's live typing in sync, and explicit three-way merges reconcile finished agent changes. Each Run, one agent's turn, works in its own Git worktree and merges back with a three-way merge. The server holds the thread's canonical files and accepts a file only if it was based on the version it holds, so overlapping changes become Conflicts for a person to resolve instead of silent overwrites. People typing together still get live co-editing; agents never share that channel.

Status: the server half shipped and was switched on for every organisation on 4 October 2026, with browser views and conflict resolution in the web app. The end-to-end workflow needs the desktop half, so it has not shipped yet: about 25,000 lines in pacifio/atlas#355, is in review. It keeps the shared copy in a separate worktree so your own checkout is never touched, sends history only with consent, holds back files that look like secrets, never commits or overwrites your files when applying a result, and marks content quoted to an agent as data rather than instructions, to reduce prompt-injection risk.

3. Every request proves who it is, every time

Invariant: every request is scoped to an authenticated organisation, with membership checked where the data is read.

The desktop signs in with the OAuth device flow (RFC 8628): you approve a short code in the browser, and the app never handles a password. Access tokens last ten minutes and carry the roles read from membership when they were issued; every service verifies them locally against published keys, so there is no central auth call on each request. Workspace access is checked against membership on every request, and each Durable Object keeps a revocation list that covers the minutes before a removed member's token expires. There is no service or bot identity: every call carries the signed-in person's token, so anything that acts on someone's behalf asks them first.

Smaller choices close gaps: webhook secrets are stored only as hashes, attachment links expire in a minute, and AI provider prompt caches are partitioned per organisation to prevent cross-tenant cache reuse and reduce the risk of leaking information through timing.

Trade-off: short-lived tokens mean the client refreshes often, and a token cached from before someone joined an organisation caused intermittent permission errors (fixed 3 October 2026). In return, a role change reaches every service within one token lifetime, and a removal is enforced at once by the revocation list.

4. Realtime that costs nothing while idle

Constraint: chat, calls and canvases must feel instant, on an infrastructure budget sized for a startup.

Each organisation's chat has its own Durable Object: one coordination point for its conversation state, isolated from other workloads. Message numbers are minted in a single storage statement, and each message and its journal entry commit in one transaction before anything is delivered. A client that reconnects within the 30-day journal receives exactly the messages it missed, in order; if it was away longer, the server says so and the client rebuilds from the current state and paged history. Search runs inside the same object, and there is no administrator back door into conversations. Live co-editing (a shared data type that merges concurrent edits) is used only where people type together, in prompt drafts and Spaces; everything else uses plain versioning.

Connections hibernate while idle, so a quiet team adds almost no running time. Under a modelled workload of 20 organisations and 200 users, the design estimates the whole infrastructure at $25–40 a month, about $10 of it for hibernating Durable Objects. These are design estimates, not measured billing.

Results

My commits to the server's main branch, one column per day, drawn the way the Atlas app draws its own usage charts. The bursts are chat and calls (late August) and the web app rebuild, feature flags, webhooks and Shared Threads (late September into October).

• Seven services deployed from CI on every merge (six carry features today; the seventh is scaffolded for planned team sync), with 45 database migrations applied by the pipeline.
• 25 architecture decision records, most with the options considered and why they lost.
• 213 test files, about 2,800 test cases by static count (a count, not a pass rate or coverage figure).
• The features behind Atlas's team releases: Accounts (0.2.3, 24 July 2026) and Atlas Teams Early (0.3.4, 27 September 2026), on an open-source app at 9.6K GitHub stars.

No user, organisation or revenue numbers are published here. Figures come from the server repository and from GitHub on 17 October 2026.

Trade-offs and lessons

• An error on a write that succeeded is worse than a failure. When the queue limit was hit, the server answered 500 for data it had already stored, and the client retried forever. The fix splits queue sends by size and count, sends large bodies by reference, and answers a queue failure after the rows are stored with a retryable 503; because an identical replay is idempotent, the retry is harmless.
• Platform limits are part of the API. A 256 KB batch and 100 bound parameters were invisible in tests and obvious with one real database. Reads now go in chunks under the limit, with tests that fail with the production error if the limit is removed. Test with real data before launch, not after.
• A stub written from the same guess as its subject cannot falsify that guess. A call-recording integration passed its tests against a mock built from my reading of the docs, then failed in production because the real response had a different shape. The stubs now return the shape the live API returns, checked by hand against it. Separately, a missing comma broke a deploy config while all 176 tests passed; no config check has been added to the pipeline yet.

Looking back

Atlas's promise is that agent work stays on your machine until you share it. The cloud's job is to make sharing safe: accept work however it arrives, keep teams apart, and let people and agents work together without overwriting each other. The work is ongoing: Atlas is in alpha, Shared Threads' desktop half is in review, and the planned team sync service is still a scaffold. I continue to lead that backend as Atlas's team features grow.

Built with

TypeScript · Cloudflare Workers · Durable Objects · D1 · R2 · Queues

Links

• tryatlas.ccThe product
• docs.tryatlas.ccPublic documentation, including accounts and organisations
• github.com/pacifio/atlasThe open-source desktop app (Apache-2.0)

The cloud backend is proprietary, so its source is not linked.