Internal systems & data

An org’s state is just files. Every internal system stores its state as plain files on disk, so it’s inspectable, diffable, and crash-safe: the board is the source of truth, every task is persisted before it runs, and a mid-cycle crash resumes next tick. Store writes are atomic — content lands in a temp file and is renamed into place — so a crash mid-write never leaves a half-written file behind.

The systems

System	Holds	Where
GoalTracker	goals + progress + the fair-rotation cursor	workspace/goals
TaskBoard	the task DAG — deps, delegation, quality flags	workspace/tasks
Triggers	schedules, webhooks, process watchers, inboxes + firing state	workspace/triggers
Docs	the org’s shared documents — roadmap, market analysis, decisions; agent-writable	workspace/docs
Meetings	meeting minutes — the org’s deliberation record	workspace/meetings
CRM	shared contacts — plus billing fields (customer id, subscription, plan, status) once they pay	workspace/crm
Roster	the ledger of employed agents	agents/roster.json
Services	the registry of published services — what the org has live, by URL — see Acting in the world	workspace/services
Secrets	org credentials, injected per grant as env vars — see Permissions	secrets/
Chat	the operator ↔ org conversation	logs/chat
AuditLog	append-only JSONL, one file per actor	logs/audit
CostLedger	every agent run’s tokens + USD	logs/cost/ledger.jsonl
RevenueLedger	money in — payments the org booked from its own pull (idempotent) — see Acting in the world	logs/revenue/revenue.jsonl

Per-agent worklogs and long-term memory live under agents/<id>/, not in the shared docs folder.

Structured stores are runtime-owned

The structured stores — goals, tasks, crm, triggers — are owned and written by the runtime, not hand-edited by agents. That’s what keeps them schema-valid, atomic, and fully audited. Agents read the shared data directly (it’s files) and produce their work as files and artifacts, but they go through the systems to change structured state.

Don’t hand-edit goals, tasks, or crm yourself either — go through the running org so the changes stay valid and audited.

The one agent-writable corner of workspace/ is docs/ — the org’s durable documents (ROADMAP.md, MARKET.md, DECISIONS.md), plain Markdown that agents keep current and you read in the file browser. See Acting in the world.

The on-disk layout

workspace/ holds only shared data; per-agent files and all logs live elsewhere under the org home:

<org-home>/
  QUORUM.md               the org definition (name, budget, mission, agents) — yours to version
  agents/                 each agent's working directory (its Bash/code sandbox)
    <id>/                 MEMORY.md, scratch, artifacts
    roster.json           the ledger of employed agents
  workspace/              SHARED data / internal systems only
    meetings/ crm/ goals/ tasks/ services/ triggers/
    docs/                 the org's shared documents (ROADMAP.md, MARKET.md, …) — agent-writable
  skills/                 reusable know-how packs, injected per each agent's `skills:` key
  jobs/                   agent-owned cron jobs (JSON manifests the org manages itself)
  browser/                per-agent browser profiles (cookies are credentials — gitignored)
  secrets/                org credentials (owner-only, gitignored) — `quorum secret`
  logs/
    audit/<actor>.jsonl   append-only audit log, one file per actor
    cost/ledger.jsonl     token + money cost ledger
    revenue/revenue.jsonl money-in ledger (payments booked from the org's pull)
    chat/messages.jsonl   the dashboard chat transcript
    metrics.db            SQLite read-model projected from the audit log
  .quorum.json            on-disk format stamp (created at init)

The audit log & metrics

Every bus message and system action is recorded to the audit log — one JSONL file per actor under logs/audit/. On boot, the runtime projects the audit log into a SQLite read-model (logs/metrics.db, via Node’s built-in node:sqlite) and then follows it live, which is what powers the dashboard’s metrics and audit feed without re-scanning JSONL on every request.