The first admin is a fixed address with its password in a log file, and the compose stack opts out of its own loopback guard

Four tiers, three episode thresholds, and an oracle that re-checks the outcome

The governance story has two mechanisms. The first is a maturity ladder with four tiers, STUDENT, INTERN, SUPERVISED and AUTONOMOUS, and promotion is counted in episodes that are outcome-checked rather than self-reported, at thresholds of 10, 25 and 50 successful runs. So the first three tiers are the supervised ones in practice and only the last one is autonomous. The second mechanism is a postcondition oracle that is on by default: every mutating action is re-derived against your system of record by something independent of the agent that performed it, and confidence is split into a self-reported part and an externally verified part. The framing in the file is that an agent saying it is done gets checked rather than believed, which is the difference between a log and a control. The same paragraph handles the injection case: a prompt-injected agent at any tier operates inside that tier's scoped blast radius, bounded by a default-on sandbox layer covering filesystem scope, a tool whitelist, tripwires, resource caps, a kill-run control, an egress allowlist and a full provenance audit.

The performance receipts are attributed to a repository benchmark, and the sourcing lives in a marketing folder

The opening makes a statistical claim before it makes a product claim: 88% of AI agent pilots never reach production, with a small footnote attributing it to an industry figure from 2026 and adding that the project makes no claims about its own deployments. Further down, a receipts line lists 0.027ms P99 governance checks attributed to a repository benchmark, 616k operations per second of cached throughput, 69 or more documented hardening rounds with about 1,100 fixes in a deep security sweep alone, and 85k test functions given more precisely as 84,737 across 2,759 files verified in August 2026. Where the external numbers come from is a path in the repository rather than a footnote: the sourcing notes, a copy kit and a positioning document all sit under a marketing directory in `docs/`. So the repository contains both the benchmark claims and the copy used to sell them, and the distinction between the two is the directory they live in.

The bootstrap admin is a fixed address and its password is written to a log file

The quick start is three make targets, and then one line that is worth reading twice:

git clone https://github.com/rush86999/atom.git && cd atom
make setup                 # one-shot dev bootstrap (venv, deps, .env, frontend)
make backend               # full backend on :8001
# in a second terminal:
make frontend              # Next.js UI on :3001

The expected result is to open the UI and sign in as `[email protected]`, with the password in a file at `backend/logs/bootstrap_admin_password.txt`. So the first account has a published address and a generated secret written into a log directory inside the working tree. Two details compound it. The example says the local models route is `ATOM_LOCAL_ONLY=true` with an Ollama base URL, while the same paragraph offers a subscription key as the recommended option for cost, and the file names the general purpose models that one key is said to unlock. And the development ports and the container ports do not match: the make targets put the UI on 3001 and the backend on 8001, while the compose stack maps the frontend to 3000 and the backend host port to 8001 for a container port of 8000.

The compose stack passes the loopback allowance the image build refuses to default

The image build has a guard and explains it. The frontend stage notes that `NEXT_PUBLIC_*` variables are baked into the Next.js build at compile time, so they have to be build arguments rather than runtime environment, and that no loopback value is defaulted because the configuration file has a fail-fast guard demanding a conscious origin, or an explicit loopback allowance, so an image cannot silently bake localhost. The shipped compose file then passes exactly that explicit allowance as a build argument, so the guard is present in the code and disabled in the stack. The rest of the compose file is stricter than that. The two secret variables are written with a required-value syntax, so compose refuses to start when they are unset, and the database waits on a real health check before the backend starts. The database itself is the weak point: user, password and name all default to plaintext values that are then interpolated into the connection string passed to the backend. The backend is also handed a URL for a service on port 3003 that is not defined in the visible part of the file.

The frontend build copies the lockfile and then runs npm install

The image is three stages, and the first one is where a detail sits. It copies the frontend package manifest and its lockfile, then installs with `npm install --legacy-peer-deps` rather than a locked install. The lockfile is present in the build context, and the install is explicitly told to tolerate peer dependency conflicts, so what gets baked into the image is a resolution computed at build time rather than the one the repository recorded. The second stage is a Python build that installs the backend requirements, and the third is the runtime, which is a Python slim image into which Node 22 is installed over the network, so the shipped container is a Python environment carrying a Node runtime for the agent tooling. Two other choices are visible. There are four compose files rather than one, for the main stack, the personal edition, and two end to end variants, and there are four client surfaces, a Next.js frontend, a desktop app, a menubar app and a mobile app, alongside deployment files for Fly.io and a directory of infrastructure definitions.

Two archive directories, two coordination documents, and four tool configuration directories

The root of the repository is where the project's working habits are visible. There is both an `archive/` directory and a hidden `.archive/` directory, so material that has been retired exists in two places with different visibility. There are two coordination documents, `AGENT_COORDINATION.md` and `COORDINATION.md`, alongside `AGENTS.md` and `CLAUDE.md`, and four directories of tool configuration for assistants and editors, `.zcode/`, `.zed/`, `.planning/` and `.githooks/`. Linting is configured in two files at once, a flake8 config and an isort config, and there is a Percy configuration for visual regression testing and a Prometheus directory. A `main_api_app.py` sits at the root next to the Makefile and the Dockerfile, and the environment example explains that the root file is what the Docker stacks read while a native development run reads a different file under `backend/`, with the full reference for every variable in a separate document under `docs/reference/`.

The environment example carries three names for the API address and a flag that gates cloud storage

The root environment template is short and structured by numbered sections, starting with core configuration. Three variables point at what looks like the same backend address under three names: a Next.js public base URL, a Next.js public API URL, and a Python API service base URL, all pointing at the same local port in the example. Then come the development defaults, a single worker, debug enabled, and a comment that the environment target is what enforces the application secret and disables the dev escapes when set to production, which is the switch that matters for a real deployment. The storage section sets a LanceDB path and a SQLite path, enables LanceDB, and adds a cloud flag described as gating the S3 and R2 paths, with Personal Edition embedded and file based by default and the SaaS edition the thing that turns it on. A third section, numbered 2b, turns on per-turn fact extraction described as a Hermes-style memory layer.

The root package manifest is a shim whose two scripts do the same thing

At the root of a repository with a Next.js frontend, a Python backend, a desktop app, a menubar app and a mobile app, the JavaScript manifest is four lines of substance. It is named `atom-root`, marked private, and declares two scripts: `dev` and `frontend`. Both resolve to the same command, running the development server of the frontend through a directory prefix. So the root manifest is a convenience shim rather than a workspace root, there is no workspaces field, and the dependency tree for the frontend lives in the frontend directory instead. The one piece of cross-project policy in the open source story is stated in the README rather than enforced by the packaging: the free edition is the full repository under AGPL version 3, keys you put in the environment file are treated as bring-your-own-key and are never gated by plan or tier, and the commercial or managed editions are described as running this same code on the client's own infrastructure with no closed-source build.

Editorial conclusion

Atom fits a team that wants agents with a visible permission ladder and an audit trail on its own hardware, and that is willing to read the governance documentation rather than take the claims on trust. Before the first run, change the default admin account rather than living with the address the documentation prints, keep the development environment variable out of production since that is what switches the dev escapes off, and decide whether the subscription based model route is something you want an agent platform depending on. If you deploy through the compose stack, note that it passes the loopback allowance as a build argument, which is the one guard the image build otherwise refuses to default.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. rush86999/atom on GitHub