R1 · how it works

How R1 works.

The harness in six views: how memory is shaped, how the lifecycle gates work, how parallel work stays safe, and what three real task patterns look like end to end.

How R1 remembers

Memory tiers, what stays sticky, what gets recalled on demand, and how the receipt graph makes memory use reviewable later.

paired with the homepage memory demo

PLAN. EXECUTE. VERIFY. COMMIT.

The gate machine, the transition rules, and why the merge boundary belongs to the harness instead of the model.

paired with the homepage lifecycle demo

How R1 runs work in parallel

Dependency ordering, file-scope conflict avoidance, merge serialization, and rollback behavior when a branch fails late.

paired with the homepage parallel timeline

A backend feature, end to end

One task from plan output through diff review, with the exact artifacts a human reviewer actually cares about.

feature work example

A database migration, end to end

A safer pattern for migrations: forward path, rollback path, verification probes, and merge guards before release.

schema change example

A flaky test, investigated

How R1 reproduces, isolates, retries, and escalates without turning a noisy test into a blind guess-and-merge loop.

debugging example