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.

From source (or to track main): clone and symlink the launcher onto your PATH, a pointer, not a copy.

A workspace holds projects. Scaffold one from a stock template, validate it, and inspect what it will run. Four ship with the tool: coding (the full lifecycle this walkthrough uses), lean (one builder, your review is the gate), advisory (decisions, not code; zero outward edges), and marketing (a content lane).

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

• agents/*.md: the cast. Each file is one role: config in the YAML frontmatter (model, effort, provider, auth, trigger, playbook), persona prose below.
• machine.json: the lifecycle, and the roles block that owns each role's access (draft / edit / review).
• project.yaml: repo, workspace-wide defaults (model, provider, playbook), the stage goal agents steer toward.
• 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.

Providers: Claude or Codex, per role. Every role runs on Claude by default; set provider: openai in a role's frontmatter to run it on OpenAI's Codex instead, so a mixed org works (Codex QA reviewing Claude-built code). auth: subscription (the default) uses the provider CLI's own login; auth: api is metered and reads the provider's key from your environment or a gitignored .env, never from a config file.

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:

The design lane. Not every ready task should go straight to code. When an engineer picks one up and finds the shape is undecided, they fire needs_design instead of claiming it, and the task moves to design where the designer role owns it. The designer either fires design_done to hand a decided spec back to ready, or review_done when the pass was a review and there is nothing left to build. You can overrule the detour at any point with skip_design, which puts the task back in the build queue as filed. It is a real lane with a real role, not a status label: the same rule holds that a task in design is dispatched to the designer and nobody else.

The note state. note is for things filed at you rather than for you to build. An agent files what it learned or noticed, you read it, and you fire acknowledge to close it out. No impl task gets spawned, which is the whole point: an FYI that cannot quietly turn into work.

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:migration_reviewed. 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: a one-glance dashboard of what's running now, what's waiting on you, the queues, and 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 stock machines are starting points, not molds. 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:

By default, agents run headless on the AI subscription you already pay for: your Claude plan, or a ChatGPT plan for roles you set to provider: openai. That default means no per-token API bill, so raw cost isn't the constraint. The real budget is the plan's rolling window, which is precisely why every role does one well-scoped unit of work per run and then stops.

Metering is an explicit opt-in: a role that sets auth: api runs against the provider's API key (ANTHROPIC_API_KEY or OPENAI_API_KEY) instead of the CLI login, and is billed per token. Nothing meters unless a role's frontmatter asks for it, so you reach for API auth deliberately, role by role.

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.