os.Claude

How it works

Behaviour runs. Everything else is read.

The whole system rests on one distinction: does an artefact run, or is it read? Two read-only layers bracket four behavioural ones — facts below, rules above, behaviour in between. That is the entire trick. The rest is discipline.

The model

The six layers

00

Inputs

read — descriptive

Everything the behavioural layers consume. Live streams from the connector mesh — Gmail, GitHub, Vercel, Sanity, Shopify, Linear, meeting notes — plus persistent memory in the decision log, and the conventions absorbed from Layer 05. Inputs are received, not authored; they set the frame for everything above.

01

Skills

runs

46 artefacts

A skill is a repeatable behaviour written down: what to do, with a trigger, a loop, and guardrails. Skills carry no schedule and no surface of their own — the moment something only runs on a clock, it belongs to Layer 02. This is where most of the system's substance lives.

02

Scheduled

runs, on a clock

14 artefacts

Tasks reproduce the cadence of a team — standup, triage, reports, hygiene — on the connector surface. Routines execute on the Claude Code surface, where the repos are: night runs intake the day's tickets, use cheap tokens, and drain the backlog. Each scheduled job is a thin loader over a canon artefact, so the instructions have one source of truth.

03

Agents & operators

organises

13 artefacts

Named collections of skills with a mission. Agents are horizontal — one capability across every venture. Operators are vertical — one venture end-to-end, commanding the fleet without executing anything themselves. Each declares its remit, boundaries, and failure modes. Accountability is the point.

04

Workflows

runs

2 artefacts

Standing paths that work flows through. The delivery workflow carries every build ticket from Backlog to Done across triage, build, review, and merge. The venture operating loop is what an operator drives its vertical through: read the goal, assess, decide, dispatch, gate, report, repeat.

05

Governance

read — normative

19 artefacts

The rules that keep the rest honest: conventions for every tool the system touches, standards that set quality bars, playbooks that prescribe sequences, and the operating model itself — the system's self-model, read before anything is built or changed.

The delivery loop

The life of a ticket

The clearest way to see the system is to follow one piece of work through it. This path runs many times a week, mostly overnight, mostly without a human in the loop.

  1. Backlog

    R3-LAY

    A ticket arrives — from the operator, a scheduled sweep, or a friction capture. Relay shapes it to standard: acceptance criteria in the body, the right labels, the right project.

  2. Todo

    R3-LAY

    Triage promotes it when it needs no human decision, or holds it for one when it does. Status is the concurrency lock — Todo means ready, In Progress means claimed.

  3. In Progress

    F0-RGE

    Forge claims the highest-priority eligible ticket, one per repo, and implements it against the connected codebase. Unresolvable blocker? It fails safe: Blocked, Urgent, assigned to the operator.

  4. In Review

    PR-1SM

    Forge opens a pull request on a claude/ branch — it never merges. Prism reads the diff against the embedded criteria and writes a plain-language verdict the operator can act on without reading the code.

  5. Approved

    R3-LAY

    A clean pass routes itself; flagged work waits for the operator. Bounces back to Forge are capped at two strikes before a human looks.

  6. Done

    R3-LAY

    Relay squash-merges, deletes the branch, marks the ticket Done, and comments the confirmation. The decision log records anything consequential.

Why it holds

The rules that make it safe

One source of truth

Instructions live in canon artefacts; schedulers are thin loaders that read them verbatim. When the words change, every run changes with them — nothing drifts in a config field no one looks at.

Agents never gate themselves

The builder never merges. The reviewer never advances the ticket. Approval is a signal the operator or a clean-pass rule sets — separation of duties, borrowed from places that learned it the hard way.

Fail safe, loudly

An agent that hits something unresolvable stops, marks the work Blocked, assigns the operator, and says exactly what went wrong. Silence is the only failure mode that isn't tolerated.

The system improves itself — by proposal

Friction observed while running becomes a queue; a weekly retro drains it into ready-to-adopt artefact changes. Nothing edits canon on its own. The human approves; the system remembers.