Dashboard & steering — Quorum docs

The dashboard is the control plane. Quorum’s terminal is output-only — it prints activity and takes no commands. Everything you do to the org, you do from the browser at http://localhost:3000.

It’s a zero-dependency HTTP server that renders read-only panels from an org-owned spec (<org-home>/dashboard/dashboard.json) and adds a chat at the top.

The panels

Whatever the spec declares, rendered live:

Org chart — the reporting tree.
Roster — the employed agents (hires and departures show up here).
Goals and the task board — what’s planned and in flight.
Requests — pending questions agents have raised for you.
CRM — shared contacts.
Recent meetings — minutes from the org’s debates.
Status / spend — today’s and this month’s cost.
Audit feed — a live stream of every bus message and system action (SSE).

Chat — steer the org

From the chat box you do two distinct things:

Message the whole org

A general directive that steers the org: it’s folded into the next cycle as a directive and becomes a goal. This is how you redirect priorities — “Ship the pricing page before outreach” — mid-run.

Message a specific agent

Pick an agent from the dropdown; that agent replies directly, in character. The whole conversation is logged (logs/chat/messages.jsonl) and shown live.

Requests — answer what agents can’t do themselves

Agents ask you for things they can’t do on their own: provision a Gmail account, grant access or credentials, approve a budget, or answer an open question. An agent raises one during its work by emitting a line:

REQUEST[<kind>]: <what it needs>

which the runtime turns into a pending request. Each has yes / no / answer… — “answer…” takes free text (paste the account details, give a decision). Your answer is written into the requesting agent’s memory and inbox, and the originating task is re-opened, so the agent actually receives what it asked for and uses it next cycle.

Capability ask decisions surface the same way — as a REQUEST[capability:<x>] for you to grant. See Permissions.

The HTTP API

The dashboard is a thin client over a small API — useful if you want to build your own view or automate steering.

endpoint	purpose
`GET /`	the dashboard HTML
`GET /api/state`	current org state (chart, roster, goals, tasks, requests, …)
`GET /api/spec`	the org-owned dashboard spec
`GET /api/metrics`	spend and counters
`GET /api/events`	live server-sent events (the audit feed)
`POST /api/message`	`{ to, text }` — `to` is `"all"` or an agent id

Binding & exposure

The dashboard exposes full org state and can send messages with no auth, so it binds to loopback (127.0.0.1) by default. Change it only deliberately:

quorum --host 0.0.0.0     # exposes an unauthenticated control plane — be sure
quorum --port 3001        # run several orgs on different ports
quorum --headless         # no dashboard server at all

Planned: pause/resume and hire/fire buttons in the dashboard, now that the browser is the control plane.