// development workflow IN DAILY USE

How AgentOS Gets Built

One slice at a time. Ceremony proportional to risk. The human decides.

The rules I use to keep AI-built software safe and predictable. I decide what gets built, an AI does the building, and a second AI is brought in to poke holes in a design before any work starts. The riskier a change, the more checks it faces, and every piece of work starts and ends with a written record.

The rulebook for how AgentOS gets built. I decide what happens; a Claude Code session does the building; when the risk is significant enough, a second AI is spawned to poke holes in the design before anything is built. Every piece of work is a slice with a written kickoff and a written closeout, riskier changes face more ceremony, and the whole cycle is projected into a VS Code cockpit with one-click launches. This page is the methodology; the build log is what it produced, and the roadmap is where it is headed.

work lands in small, safe steps checks scale with the risk I make every ship call risky designs get an independent review
26 slices shipped in 9 days 06 risk classes 18 standing invariants 11 decision gates
the_loop [01]

The Operating Loop

Six steps, every time. Small low-risk changes and big risky ones follow the same loop; the risky ones just face more scrutiny before any work starts.

Six steps, every time. The same loop runs whether the slice is a documentation-only design or a new write surface; only the depth of the design gate changes.

Six steps in a cycle. 01 select, 02 kickoff, 03 design gate, 04 implement, 05 validate, 06 closeout. Closeout feeds back to select: it recommends the next slice. closeout recommends the next slice 01 Select 02 Kickoff 03 Design gate 04 Implement 05 Validate 06 Closeout
01 Select I pick a slice from the roadmap's Next section. The backlog row flips to in-progress.
02 Kickoff The AI writes down what the slice will do, the rules it must obey, and how success will be checked, before any work starts. The session materialises a kickoff record from the register, quoting the row and the binding invariants verbatim.
03 Design gate Risk-proportional. Low-risk work goes straight to code; write surfaces get a design document and an adversarial review first.
04 Implement Isolated, revertible commits.
05 Validate Exactly the gates the kickoff named. No renegotiating at closeout.
06 Closeout A written record with an explicit outcome, plus a stated recommendation for what to do next.
01Select: I pick a slice from the roadmap's Next section. The backlog row flips to in-progress.
02Kickoff: the AI writes down what the slice will do, the rules it must obey, and how success will be checked, before any work starts.
02Kickoff: the session materialises a kickoff record from the register, quoting the row and the binding invariants verbatim.
03Design gate: risk-proportional. Low-risk work goes straight to code; write surfaces get a design document and an adversarial review first.
04Implement: isolated, revertible commits.
05Validate: exactly the gates the kickoff named. No renegotiating at closeout.
06Closeout: a written record with an explicit outcome, plus a stated recommendation for what to do next.

06 returns to 01: the closeout recommendation is what I select next.

I decide

Slice selection, every open design question, approval grants, review-finding dispositions, and the ship call. The AI never resolves a genuinely open fork silently, even mid-slice: it stops and asks.

The AI executes

Materialises kickoffs, implements, runs the validation gates, writes the records, and proposes the next step. Proposals come with a recommendation, not a menu.

A third role sits outside the pair: an external adversarial reviewer, a separately spawned AI whose only job is to refute the designs. Section 0306 below.
slices_and_risk [02]

Slices and Risk Classes

There is no sprint board and no ticket system. The unit of work is the slice: small enough to commit on its own, big enough to ship something real, with a durable ID that is never reused. Kickoff and closeout share that ID, so every slice is bracketed by two written records. Each slice carries a risk class, and the ceremony scales with it.

R0: docs only

Design memos, plans, and register changes. No code.

R1: read-only code

Deterministic code. No model call, no write surface, no UI change.

R2: observe-only UI

Screens and views that only display information and can never change anything.

UI changes and new read surfaces. Any new endpoint is GET-only.

R3: model spend

Runs that cost real money. The kickoff names a spend bound before anything launches.

R4: write or authority

Anything that can change data, grant approvals, or alter how the system behaves. Design-first, independently reviewed.

Apply paths, approvals, config mutation, any new mutating seam. Design-first, externally reviewed.

R5: platform boundary

Remote, multi-user, hosted. Opening that fence is its own decision, with the full R4 treatment on top.

R0 to R2 go straight from kickoff to work. R3 must name its spend limit first. R4 and R5 get a written design plus an independent adversarial review before any code. Designing and building are always separate pieces of work.
R0 to R2 go straight from kickoff to work. R3 must name its spend bound first. R4 and R5 get a design section in the phase document plus an external adversarial review before any code. Design and implementation are always separate slices: a shipped design mints new implementation rows at closeout.
the_steering_board [03]

One Roadmap, Nothing Multi-Paragraph

The roadmap is a single markdown file with a hard rule: nothing multi-paragraph lands in it. It changes only by row edits and status flips; narrative lives in per-phase documents. That keeps it a steering surface, not a junk drawer.

01Now: dated one-paragraph records of what just shipped.
02Next: recommended candidates, grouped by role. The order recommends; I decide.
03Decision Gates: standing conditions that bind named rows. A kickoff touching a bound row quotes its gate verbatim.
04Backlog Register: live rows only, each with ID, role, risk class, prerequisites, and status.
05Shipped Register: one line per shipped slice, linking to the authoritative closeout record.
06Invariants: eighteen standing guardrails, bound by ID at kickoff. The full list is in the next section.
07Slice Protocol: the lifecycle, the risk classes, and the kickoff and closeout templates.
The live register and the shipped register together are the single source of taken slice IDs, and an exported copy is never canonical. Any fresh session, on any machine, picks up the exact state of play from the documents alone: the process deliberately stores nothing load-bearing in chat history.
the_guardrails [04]

Eighteen Invariants, Bound by ID

The condensed constitution of the system: what never widens, what never grants authority, what stays read-only. Kickoffs bind these by ID, closeouts check them by ID, and the per-phase docs stay authoritative for the detail.

IDInvariant
G1No free models for reliability-critical audit, challenge, or apply runs.
G2No apply widening: structural, architectural, cross-surface, or ambiguous findings stay manual.
G3No portfolio-wide apply: every write is single-target, verifier-gated, build-gated, and ledgered.
G4No apply-write through the queue: approvals bind to an exact apply fingerprint, granted out of band.
G5The challenger stays advisory: a clear verdict never masks a failure.
G6The failure-domain enum is smoke-locked and never widened casually.
G7Restart the server after any server-side deploy, before live validation.
G8No new platform code beyond accepted slices: new gateway endpoints are GET-only.
G9Config never grants authority: JSON cannot define new executable behaviour.
G10Secrets live in env or SecretStorage only: never in config, queues, ledgers, or reports.
G11Runtime artefacts are not source: no broad deletes over tracked report folders.
G12Every slice is independently committable, compile-green, and smoke-green.
G13Proposal-first: no model output is applied without deterministic validation and human review.
G14Observe surfaces stay read-only except explicitly confirmed launches.
G15A standing fence over hosted, multi-user, write-surface, and queued-apply expansions: opening it is its own decision.
G16Every grant record carries originating-surface and grantor-auth provenance from first write.
G17Decision-quality telemetry is descriptive only and never gates.
G18A design gate that refuses a real operator need must name the lawful alternative in the same document.
Alongside the invariants sit eleven decision gates: standing design decisions, each anchored to an owner document, that bind named rows. A bound row cannot kick off without quoting its gate verbatim. The memory boundary lives here (memory informs, the spine decides), as does the remote decision boundary (a phone approval issues the same grant object through the same path as the desk).
ceremonies [05]

Ceremonies

A ceremony here is a written record produced at a fixed point, in a fixed shape, and said out loud rather than left implied by file changes. AI-run work does not fail by crashing; it fails by trailing off. The ceremonies exist to make "done" an explicit, checkable claim.

Kickoff record

Written before work starts: intent, in and out of scope, binding invariants quoted by ID, checkable acceptance criteria, the named validation gates, and the spend bound where models are involved. The kickoff is the contract; closeout validates against exactly what it named.

Closeout record

Capped at about 200 words: outcome (shipped, partial, or abandoned), commits, what changed, each gate with its result, and two fields that can never be omitted: Manual check (what to click or run to see the result yourself) and User docs (what changed in the user guide). A slice with nothing to show writes N/A plus why. Absence is a stated fact, never a silence.

Register ceremony

The closeout checklist: append the record to the phase doc, move the row to the shipped register, update Now and Next, update the user guide, write memory, update the changelog, commit, restart the server if it changed. New backlog rows are minted the moment they exist, including every deferral.

Fold ceremony

How review findings are absorbed. The reviewer's verbatim verdict is pasted into the reviewed document, and every finding gets a written disposition: fold (with the edit), reject (with the reason), or defer (with the owning row). The AI proposes each disposition; I decide each one.

adversarial_review [03][06]

The Adversarial Review

Before anything risky is built, a second, unrelated AI is handed the design with one instruction: break it. It shares nothing with the AI that wrote the design, so it cannot inherit the same blind spots, and an extra review round costs nothing.

Design documents get refuted before they get built. The authoring session spawns a second, unrelated AI (headless Codex CLI, running read-only) with a fixed prompt whose only instruction is to break the design. Because it runs on a subscription CLI, the marginal cost of a review round is zero.

Independence rules
01Fresh context: the reviewer gets the document and its named sources. None of the authoring session's reasoning is passed, so it cannot inherit the author's blind spots.
02Refute, not assess: the prompt asks for the strongest breakage. A zero-finding review must list what it tried and failed to break.
03Fixed prompt: the reviewer always gets the same fixed instructions, so the AI that wrote the design can never soften the review by wording the prompt itself.
03Fixed prompt: the reviewer prompt is a recorded template. Per-run improvisation by the authoring model is the anchoring channel this closes.
04Provenance: the reviewer's model and CLI are recorded in the reviewed document.
The output contract

Every review returns a verdict (GO | CONDITIONAL-GO | NO-GO), findings ranked most severe first, answers to the document's open questions, and a tried-and-failed list. The verdict never gates mechanically: a NO-GO with rejected findings and my sign-off can still ship, recorded as such. The protocol makes disagreement visible, not binding.

First live run, 10 July 2026, on the chat-surface and model-routing design: two Codex rounds, both NO-GO, 13 findings, 12 folded into the design, 1 rejected with the rejection upheld on re-review, then a Microsoft Copilot acceptance pass on the folded document. The design shipped stronger than any single model wrote it.
three_backlogs [07]

Three Backlogs, Three Formality Levels

Not everything deserves a risk class. Work queues at the formality it needs.

Backlog Register

The real work queue, inside the roadmap. Rowed, ID'd, risk-classed, gated. Everything that becomes a slice lives here first, and nothing gets built without a row. The roadmap page renders it in full.

UI Fix Register

The UI/UX backlog, explicitly ceremony-free: add an entry whenever something is spotted. Screenshots attach by a file-naming convention, so an entry never needs editing to gain an image. Fixes launch from the cockpit one at a time or as a batch.

Docs backlog

Undocumented changes, collated on request by diffing the git log against the changelog, then worked as ordinary documentation updates.

the_cockpit [08]

The Development Tab

The whole workflow is projected into a Development tab in the VS Code dashboard: four sub-tabs (Slice, Roadmap, Build log, UI/UX Register) rendering the live documents off disk. It is a cockpit, not a second control plane, and its interaction model is deliberately narrow.

Slice page

Previous, current, and next-up slices with the full register field set rendered faithfully: empty fields render empty, never invented. A per-slice ceremony checklist tracks the ritual; a candidate table shows what could run next.

One-click launches

Kick off, Continue, and batch-fix buttons compose a seeded Claude Code prompt (Start 5W.2) and open the terminal. Confirmed launches only: the buttons write no files, flip no rows, and grant no authority. The session does the work; the tab just removes the friction.

One write seam

The only thing the tab can write is a new UI Fix Register entry, through a validated capture form: deterministic ID allocation, an atomic single-file write, a path guard. It writes nowhere else, by design and by review.

Checkboxes gate nothing

Ceremony checkboxes persist locally and are never evidence a gate passed. At most they add an overrideable warning before a launch. A ticked box is a note to self, not proof: proof lives in the closeout record's gate results.

why_this_shape [04][09]

Why This Shape

01
Ceremony proportional to risk

Docs-only work moves at conversation speed. Anything that writes, spends, or grants authority pays for design and review first. The risk classes make that a rule, not a judgement call made under momentum.

02
Outcomes stated, never implied

Every slice ends with an explicit outcome and a next recommendation. Every closeout must state how I can check the result myself, and 'nothing to check' must be argued, not assumed.

Every slice ends with an explicit outcome and a next recommendation. The mandatory Manual check field means I can always verify a claim myself, and N/A must be argued, not assumed.

03
Written records over memoryRegisters over memory

The documents carry the whole state of play. The AI's memory points at the documents; it never replaces them. A fresh session on a fresh machine picks up from the written records alone.

The documents carry the whole state of play. Session memory indexes them; it never substitutes for them. A fresh session on a fresh machine resumes from the repo alone.

04
Independent refutation over self-review

An author reviewing its own design inherits its own anchoring. A fresh-context reviewer with a fixed refutation prompt does not. Disagreement is made visible and recorded; it is never made binding.

See what it produced

The build log is the chronological record of this workflow in action; the roadmap is its live steering board.

Read the build log →