Atomic: a coding agent runtime where the workflow is a graph with gates, not a prompt

The unit of work is a graph of stages, not a single prompt

Atomic describes itself as a verifiable coding agent runtime, and the difference from a coding agent you talk to is that the process is written down. You describe inputs, parallel stages, synthesis and outputs in prose, and Atomic writes and reloads a runnable TypeScript graph from that description. The workflow is then a real artefact in the repository rather than a set of instructions the agent is supposed to remember.

The README is blunt about the trade. Atomic prioritises quality over quick responses, and complex runs can take hours, days or weeks, because the runtime researches, implements and verifies work that quick coding agent passes leave to you. That sentence is the whole pitch and the whole cost in one place, and it should shape your expectation before you install anything.

The stated benefit is less babysitting, fewer code review comments and work backed by evidence rather than another round of manual prompting. The README also quotes what users report: a reduction of one to one and a half hours of manual verification per task, a merge rate of about 95 percent on generated pull requests with a zero percent revert rate, and production incidents caught that continuous integration did not cover. Those are the project's own figures, reported by users, and they come with no measurement method attached.

Approval gates make the run wait for a person

A human in the loop gate is the mechanism that makes a long run safe to start and leave alone. The README puts an approval gate anywhere in the graph, and the run waits at that point for a person before it proceeds. Nothing about the gate is cosmetic: it is a node in the execution graph, the same kind of thing as a stage.

That is what makes the design different from asking an agent to be careful. Instead of a prompt that asks the model to stop and confirm, there is a place in the graph where control is structurally handed over, and the run's progress, including its checkpoint counts, is visible to the operator.

Durability works the same way. Runs checkpoint as they go, so killing the process leaves them retained and resumable rather than lost. The README describes a resume picker in the installed product listing retained workflow runs with their checkpoint counts. For a runtime whose runs are measured in days, that combination, gates plus checkpoints, is what makes an unattended run defensible: a human decides where to intervene, and an interrupted run can pick up where it stopped instead of restarting from nothing.

Intercom lets separate sessions split a job and agree on an answer

The other structural feature is intercom, the channel Atomic sessions use to message each other. The README describes planner and worker coordination over intercom: separate sessions message each other to split a job and agree on the answer.

This is the piece that addresses a familiar failure mode of multi-step agent work. When one session does everything, the planning and the execution share a single context that grows without limit and gets summarised away. Splitting them means the planner can stay small and focused while a worker does the wide, noisy part of the job, and the two communicate through messages rather than through a shared transcript.

A live run can also be steered. The README says you can attach to a running stage, watch it stream, and steer, pause or abort it mid-flight, with the operator sending a steering message into the running stage. Taken with the gates, this gives three levels of intervention: not starting the run, answering a gate when it appears, and redirecting a stage while it is executing.

The documentation for all of this lives outside the repository, at docs.bastani.ai, with a separate intercom page and a crash course repository that the README links for step by step walkthroughs of each feature.

A TypeScript shell over a Rust native crate

The repository is a monorepo with two languages and more than one package. The root package.json is named atomic-monorepo, marked private, and declares workspaces of packages/*. The engines block sets the floor:

  "engines": {
    "node": ">=22.19.0",
    "bun": ">=1.4.3"
  },

Rust enters through a Cargo workspace with a single member:

[workspace]
members = ["crates/atomic-natives"]
resolver = "3"

The dependency list in that Cargo file explains what the native side is for. It pulls in napi with the napi10 feature, which is how a Rust crate is exposed to Node, along with portable-pty for pseudo terminals, tokio for the async runtime, memmap2 and grep-matcher, globset and ignore for fast searching, rayon for parallelism, and sha2 for hashing. The tree-sitter grammars are the striking part: typescript, javascript, python, rust, go, ruby, css, json, bash, c, cpp and java are all listed as dependencies, which suggests the runtime parses code structurally rather than treating it as opaque text.

Alongside that sit the working files of a serious engineering project: DESIGN.md, PRODUCT.md, DEV_SETUP.md, SECURITY.md, CONTRIBUTING.md, AGENTS.md, CLAUDE.md, a specs/ directory, a research/ directory, .atomic/ and .agents/ directories, biome.json for formatting and linting, a vitest configuration, tsconfig files and a rust-toolchain.toml that pins the Rust side.

The test scripts are the clearest map of the codebase

The package.json scripts tell you what the project considers its contract, which is more informative than a directory listing. The workspace commands name the packages directly: @bastani/pi-ai, @bastani/atomic-natives and @bastani/atomic. The build script builds them in that order, running an alias step for pi-ai in between, and the typecheck script mirrors the same chain.

The test surface is split by kind rather than lumped together:

    "test:unit": "vitest --run --project unit",
    "test:integration": "vitest --run --project integration",
    "test:ci-contracts": "vitest --run --project ci",

There is also a scripts test that runs node's own test runner over the scripts directory, a conformance run for the coding agent package executed with bun, and an all-target script that chains unit and integration. The project also keeps a check script for the shrinkwrap, which is a way of saying that the locked dependency tree is verified rather than assumed.

For a first look at the repository, this is where to start. The vitest projects tell you that the codebase distinguishes unit tests, integration tests and CI contracts, and the shrinkwrap check tells you that dependency drift is treated as a defect. Both are claims about discipline you can go and check.

Installing means a script, a toolchain and a native build

The repository ships install.sh and install.ps1 at the root, which is where a Linux or macOS user and a Windows user respectively would start. The README's Get started section points onward to the documentation site, and the setup details are covered by DEV_SETUP.md in the repository.

The prerequisites are visible in the configuration files. Node 22.19.0 or newer and Bun 1.4.3 or newer are declared, and the Rust crate is built through napi, so a Rust toolchain is needed, pinned by rust-toolchain.toml. Hooks are installed through prek, with a prepare script that installs the hooks and applies the pi-ai alias:

    "hooks:install": "npx --no-install prek install --prepare-hooks",
    "hooks:run": "npx --no-install prek run --all-files",

The pre-commit hook configuration is a prek.toml file, and biome.json handles formatting with a format script that writes changes and a check script that treats warnings as errors. In practice this means a working installation is a Node and Bun toolchain, a Rust toolchain, and a set of hooks, which is a heavier floor than a single npm install of a JavaScript package.

One detail worth knowing before you set up CI: the model data is generated and hydrated by separate scripts, generate:models and hydrate:model-data, both scoped to the pi-ai workspace. Whatever produces the model catalogue is a deliberate, separate step in the build.

MIT in the files, a custom classification on the repository

The licence picture has a wrinkle. The README badge reads License: MIT and the Cargo workspace package block declares license = MIT, and the LICENSE file is at the root of the repository. The repository, however, is classified with a custom licence that GitHub cannot categorise. Those are two different sources saying different things about the same file, and the file itself is the one to read.

The Cargo metadata is otherwise tidy: version 0.0.0 at the workspace level with the real version applied elsewhere, edition 2024, repository pointing back at the project, and a release profile with lto enabled and symbols stripped.

Release numbering tells you where the project sits. The recent tags are 0.9.39 on 2026-10-19, preceded the same day by 0.9.39-alpha.2 and 0.9.39-alpha.1, and the last push to the repository was on 2026-10-22. A version below 1.0 with alpha tags shipping minutes before the final tag is a project that is still moving its interfaces, and the README's own reference to Atomic being an installed product with a crash course and a case study page shows a commercial shape around an open source core. Read the LICENSE file before you build on it, and this is not legal advice.

Where Atomic is the wrong tool

The obvious wrong fit is speed. If you want an answer or a patch in the next five minutes, a graph with research, synthesis and verification stages is the wrong instrument, and the README says as much by contrasting itself with quick coding agent passes. That alternative approach exists in abundance, and the difference is structural rather than a matter of model quality: a single pass produces output and leaves verification to you, while Atomic moves verification into the run and can gate it.

The second wrong fit is the environment. Node 22.19 or newer, Bun 1.4.3 or newer, a Rust toolchain for the native crate, tree-sitter grammars for a dozen languages and pre-commit hooks make this a heavier installation than a library. On a locked down workstation or a minimal container, that setup is work.

The third is the absence of guarantees. The figures in the README are self reported by users, without a described measurement method, and they describe merge rates and time saved rather than correctness. The gates and checkpoints give you control and auditability, which is a different kind of value from a promise about output quality, and a team that needs the second should evaluate it separately.

The fourth is that the documentation lives off the repository. The workflow, intercom and feature pages are on the vendor's documentation site, and the crash course is a separate repository. A team that wants to read and change the runtime's behaviour offline is working against the shape of the project as it is distributed.

Editorial conclusion

Atomic fits teams that want a coding agent whose process is auditable, where a run has stages, checks and approval gates, and where the result carries evidence rather than a transcript. It does not fit anyone who needs an answer in minutes, and it does not fit a stack without Node 22.19 or Bun 1.4.3 and a Rust toolchain for the native crate. Before adopting it, run one small workflow with a gate in it and read the checkpoints before trusting an unattended run.

Frequently asked questions

Official sources

1. bastani-inc/atomic on GitHub
2. Issues
3. Project website
4. README
5. Releases