What is a verifiable coding agent runtime?
A verifiable coding agent runtime executes the process around an agent. Developers can inspect work progress, checks run, produced evidence, and required human-input points. Atomic is that runtime. Loops are repeatable agent systems built and run on Atomic. Workflow definitions specify their stages and controls.
Runtime, loop, and workflow are different layers
The runtime executes and tracks agent work. A loop is the repeatable engineering system a team wants to run. A workflow is the TypeScript definition of the loop’s stages, tools, prompts, checks, artifacts, gates, and human-input points.
What the runtime controls
Atomic can enforce schema-backed contracts for stage outputs and declared workflow inputs and outputs. A stage with a schema must return valid structured output. Validation errors trigger bounded corrective prompts. The stage fails if it still does not satisfy the contract. Atomic durably checkpoints supported ctx.* workflow operations. A resumed run can replay completed results without repeating side effects enclosed by those operations.
Workflows can include executable checks, reviewer stages, and gates. Atomic’s built-in Goal and Ralph loops collect structured reviewer evidence. Ralph’s code-defined gates approve the work or start another iteration. Goal’s reducer selects completion, another turn, blocked, or human escalation. These decisions are deterministic for the evidence they receive. Model generation and reviewer judgment are not.
The runtime provides these verification primitives. The workflow selects which primitives run. Not every workflow includes every check, reviewer, gate, or approval. Passing a configured contract does not guarantee correctness or security.
How Atomic executes workflow graphs
Atomic materializes each workflow run as a dynamic directed acyclic graph (DAG) of tracked execution stages and nodes. Ordinary TypeScript decides which tracked work runs. Atomic records parent edges when nodes spawn and advances the graph frontier when their promises settle.
Sequential chains, parallel fan-out and fan-in, runtime-created branches, and composed child workflows become inspectable run topology. The recorded topology preserves parent lineage and lifecycle status, and supports descendant failure handling, pause/resume controls, nested graph expansion, checkpointing and reconstruction, and durable replay.
Authorized subagent delegation is opt-in and depth-limited. Child workflows compose through explicit ctx.workflow(...) boundaries with a separate workflow depth limit, so workflow hierarchy and subagent delegation remain bounded independently.
From natural language to an executable workflow
Developers can describe a workflow in natural language and let Atomic create it, or write and version it directly in TypeScript. Natural-language authoring is one creation path. The durable executable representation remains a workflow definition in the repository.
npm install -g @bastani/atomic
atomicRead the workflow documentation for the current TypeScript API, durable execution model, and human-input controls.
Dynamic coding-agent workflows
Workflows are inspectable TypeScript. Their execution path can respond to earlier results without becoming a black box. A definition can branch on structured output, run independent work in parallel, compose reusable child workflows, and include human-input points. Developers choose the stages, tools, models, checks, gates, and controls that fit the engineering task.
Read about coding agent workflows for software engineering, inspect the current SDK authoring surface, or compare Atomic’s bundled workflow examples by control and verification shape.
Engineering loops and software factories
Loop engineering means designing repeatable agent systems instead of repeatedly issuing one-off prompts. A useful engineering loop defines its inputs, stages, evidence, stop conditions, and intervention points. Atomic runs these systems and preserves inspectable run state and artifacts.
Atomic uses “software factory” for a broader system composed from engineering loops. Teams can call loops as child workflows and run independent branches concurrently. Background execution and durable resume let configured verification continue overnight or across days, provided the host environment remains available. Developers retain control. They can request run or stage status. They can inspect progress, evidence, and transcripts. They can steer, follow up, attach, pause, resume, or intervene as needed.
How verification fits
A runtime provides the execution surface. Verification depends on the checks and evidence designed into a workflow. Read verification for coding agents for a practical model of checks, artifacts, reviewer independence, gates, and failure handling.
This page is a runtime overview. The complete technical documentation is the current source of truth for workflow APIs, execution behavior, and controls.