Run an agent company, end to end.

Four ideas carry the whole system. Hold these and everything else is detail.

A task is the only atom. An epic, a bug fix, a proposal, a release — all tasks. A task advances through states by firing edges, and its state is whose turn it is. That's the entire model; the rest of this page is how you drive it.

DAIS_HOME resolves from the env var, else ~/.dais/config, else falls back to DAIS_ROOT — so a fresh clone runs self-contained until you point it somewhere.

Requirements: sqlite3, python3 (stdlib only), the Claude Code CLI (claude) for the agents, and gh for opening PRs. Runs on macOS (bash 3.2+) and Linux.

A workspace holds projects. Scaffold one from the coding template, validate it, and inspect what it will run.

Then make it yours by editing the files under projects/myapp/:

• project.yaml — repo, model + effort (with per-role model_<role> / effort_<role> overrides), the stage goal agents steer toward.
• roles — who exists and each role's access (draft / edit / review).
• agents/*.md — the persona each role runs with.
• CONTEXT.md — project memory, read first on every run (north star, targets, decisions, gotchas).

The full prompt an agent sees escalates in specificity: workspace CONTEXT → project CONTEXT → role playbook → role persona. Keep durable truth in the CONTEXT files and craft conventions in the playbook, and the personas stay short.

This board runs the coding machine — authored JSON, fully editable. A task's state is whose turn it is, and the scheduler dispatches the single role with an outgoing edge from that state. You never set a status. You fire an edge:

Advancing is always the same shape. Ask a task what you can fire, then fire it:

Front door — ◆ proposal_review. A lead files a new direction as a proposed task, fleshes it to a spec, and fires submit. It parks at proposal_review until you fire approve — which spawns the implementation task(s). Nothing new gets built until you approve the direction. request_changes bounces it back; reject cancels it.

Back door — the ◆ release greenlight. QA-passed work parks in the approved pool. A release task sweeps it up (assemble) and waits at release_review for you to fire greenlight — guarded by typed_confirm and attest:migrations_applied. Those are strong-human guards: no auto-approver can forge them, which is exactly what makes shipping structurally un-automatable.

Two ways to drive. By hand, you read the board and fire edges yourself. Or you let the loop dispatch agents for you — either way, every agent does one well-scoped unit of work per run and then stops, so the board moves in small, inspectable steps, never a runaway.

• dais status — the dashboard: running now, what's waiting on you, queues, recent runs.
• dais top — the live cockpit (master–detail TUI); the primary way to operate.
• dais tasks <project> [--status S] [--assignee R] — filter the task list.
• dais edges <id> · dais actions <id> — what can fire from a task, and the exact command for each.

• dais fire <id> <verb> — advance a task by firing a declared edge (the only way state changes).
• dais task add <project> "title" · dais task set <id> … — file work and edit metadata (priority, notes, PR, dependencies).
• dais start <id> — run the role that owns this task's state right now (bypasses pause).

• dais watch [secs] — the continuous auto-dispatcher: each tick runs the most valuable pending task, then stops.
• dais tick [project] — run exactly one scheduling tick (the router picks who runs).
• dais pause / dais resume — park or un-park the loop; dais schedule install runs it in the background (launchd / cron).

A release is just another task, entering at release_open. The engineer fires assemble, which aggregates every task in the approved pool into it — the set it will close. It parks at release_review with the engineer's audit notes (merge order, what was verified per PR, the migration plan). You fire greenlight; the engineer fires shipped, which runs the release script and fires each encompassed task's edge to done — all in one atomic transition.

merge == deploy vs. merge ≠ deploy. On a project where a merge to main is the deploy — like this very site, which Cloudflare Pages builds from main — the greenlight is the prod gate; there is no second step. Where merge ≠ deploy, the release runs a separate deploy per the repo's runbook, still founder-gated. If shipping fails, the task drops to release_failed and spawns a rollback — the machine has the unhappy path too.

The coding machine is a starting point, not a mold. A machine is JSON with three parts: states (tags — initial / terminal / pool / band), edges (from, to, one by actor, a verb, optional guards, optional effect), and checks (named shell commands a verify: guard runs). Copy it per project and draw the graph you want.

The guard vocabulary is closed — compose these, don't invent:

• confirm — a click. Weak; an auto-approver can satisfy it.
• typed_confirm — a human types a phrase. Strong.
• attest:<fact> — a human asserts an unverifiable fact. Strong.
• verify:<check> — an automatic check (tests, no-conflict, brand_voice) via checks.<name>; absent that command it fails closed unless the firing role self-asserts with --verify.
• role:<r> — actor authorization.

The two strong-human guards are the whole protection mechanism: an outward edge carrying one is structurally un-automatable. Danger is declared per-edge, not coded per-action.

Effects fire edges, they never poke state. spawn creates tasks, aggregate pulls tasks into encompasses, script runs a merge/deploy/publish, then fires an edge on related tasks. A release closing eight children does it by firing eight real → done edges, each still subject to that edge's guards — so even spawned and aggregated work stays inside the machine and stays lintable.

Lint blocks only on incoherence, never policy: dangling references, a non-terminal state with no way out, ambiguous dispatch, a missing initial or terminal. Everything safety-flavored is a warning you can wave off. Green errors ⇒ build whatever shape you want.

Playbooks & new roles. Working conventions bind to the role, not the universal prompt, so one harness spans code, legal, and content — set a role's playbook or a project default. And you can let Claude draft a role for you:

Agents run headless on the Claude subscription you already pay for — no per-token API bill, so raw cost isn't the constraint. The real budget is the subscription's rolling window, which is precisely why every role does one well-scoped unit of work per run and then stops.

Frugality lives in the machine — small steps, gated hand-offs, one agent per tick — not in a memo nobody reads. A board that ships steadily and never surprises you beats one that burns a window doing something you never approved. The gates make that trade for you, structurally.