Skip to main content
MCP server · durable todo queue · local web UI

Switchboard

Many lines come in. The operator verifies each caller, and patches it through.

Switchboard receives inbound webhooks, verifies each one per source, and turns it into a durable todo that agents claim and complete over scoped, human‑vended MCP endpoints. One box: receive · verify · patch through.

Push & pull ingestion adapters

Push webhooks (GitHub, Stripe, Slack, Docker Hub, generic) and pull queue adapters (Redis, with SQS/NATS/AMQP to follow) normalize into the same todo — each with an enforced trust mode. Pull adapters ack the source only after the todo is durably stored, so nothing is lost at the boundary.

Durable todo work‑queue

Every event becomes a work‑item with a lifecycle — claimed under a lease, completed with an ack, deduped by idempotency key. A crashed worker's todo re‑surfaces; nothing is read‑once and lost.

Per‑agent vended MCP endpoints

Humans are the accountable principals; each agent is vended a scoped MCP endpoint (queues + verb allowlist). The credential is stored hashed in Postgres, short‑lived and revocable — revoke = kill the endpoint.

Personas as A2A Agent Cards

One agent, many least‑privilege faces. A persona is a human‑authored prompt plus a verb subset; its advertised skills are derived from what's actually vended, published as an A2A Agent Card.

Human‑approved friending

Agents discover peers over A2A and send a scoped friend request. Approval lands as a todo in the target human's queue — and approving is the vend. Per‑direction, revocable, non‑transitive.

Push into your live session

When a harness is attached, switchboard pushes new todos straight into the session over the open Claude Code Channels standard — a doorbell, not the ledger. Offline? The durable queue keeps the work until it's pulled.

Live operator board

A five‑view operator board — Board, Todos, Endpoints, Personas, Friends — on Go (net/http) + HTMX, wearing the brass‑and‑bakelite Operator design language and updating live over Server‑Sent Events, with the same trust badges the API and MCP surfaces carry.

Two families — webhook & queue — each event's trust shown:signedtokenopenqueue— see ADR‑0003.

:::note Design record This site is the canonical, SDD‑governed design record for switchboard — 16 architecture decision records and 14 OpenSpec capability specs (each a requirements + design pair), plus machine‑readable reference contracts. The MVP application code is built from these documents. The name is the architecture: a manual telephone exchange took many incoming lines, an operator verified the caller, and patched the line through — which is why these pages wear a switchboard‑era palette of brass, bakelite, operator‑cream, oxblood, and patch‑cable tones. :::

Start here

  • Decisions (ADRs) — why switchboard is built the way it is: the stack, the PostgreSQL persistence, the trust model, the MCP contract, and the todo/agent‑vending/A2A layer.
  • Specifications — 14 OpenSpec capabilities (RFC 2119 requirements + Mermaid design): ingestion, the durable todo queue, persistence, the MCP + agent tool surfaces, vended endpoints, identity, personas, friending, Channels push delivery, and the web UI.
  • Design — the "Operator" design language (ADR‑0016): tokens, components, the five operator‑board screens, voice, and the directions explored.
  • Reference — the OpenAPI (HTTP surface) and AsyncAPI (SSE stream) contracts.