Atlas

Atlas is how I want to build software: I set the direction, and agents deliver the work under rules I set. It holds the lifecycle my agents follow, the checks that prove their work, and the records that carry a task across sessions. Today it is a private package. Some parts are live, and some are built but still started by hand.

Why it exists

I want to act as the product manager of my projects, not as the person who types every change. In my own words: "I just want to be the product manager of this project, right?"

That only works if agents deliver the same way each time. The way I work with agents started inside Engram and then moved to Loom. In August 2026 it moved again, into Atlas, so that one place holds it. The goal, as I put it: "I wanted to make software development faster and repeatable across multiple repos".

One lifecycle, with gates

Each task moves through six stages: capture, spec, build, verify, ship, and learn. Before the build starts, the spec is locked, and a lock has conditions that must hold first.

After the lock, four tripwires stop the agent and hand the task back to me: a change to the agreed criteria, a security question, a schema change, or a new cost. Agents log each move between stages when they can.

The lock and the tripwires are instructions that agents read and follow. Newer work code goes further: it refuses work that has no locked scope in Git. This website is built under a copy of the instructions.

Work with proof

A finished change is not the same as a proven one. Atlas can hand a task to a worker model, and the worker reserves budget before each call. The result is tested in an isolated container with no network, reviewed, and merged into a local test repo under supervision.

That path is built and tested on sample tasks. One real-model proof passed, on a tiny sample change. Nothing in it runs on a schedule, and it has not merged a real pull request or deployed anything.

What it keeps and shows

Agents forget between sessions, so Atlas keeps what they learn about a repo as records with sources. Before an agent changes a record, it must show the version it last read. If the record changed in between, the save fails, and the agent reads again.

GitHub stays the source of the work itself. Atlas reads it and shows it to me in a read-only view that runs on my own machine: the open questions, the priorities, the order of the work, and what each task still owes. Atlas also renders documentation websites. Its first site is Engram's.

Where it goes next

The next big step is a coordinator that runs as a service. I put it this way while we locked the design: "coordinator is basically like an Atlas deployed service that manages multiple services and repositories, where a service can be a collection of repos, right?"

Engram is the planned home for its work records. A shared pool of workers should take tasks from many repos, and a manual version of that pool is built. Atlas can install itself into a repo. Atlas runs it, and Engram has one trial install, kept apart from its live repo. The scheduled routines are written but not switched on, and editing the plan from the owner view is still planned.