Dispatch
A peer-to-peer courier for agentic work. One person describes a task in
natural language and names a recipient; the recipient's machine runs it with
a local AI agent - but only if the two people have an explicit, scoped,
revocable trust relationship, the dispatch is cryptographically signed
by the sender's device, and the recipient approves it.
A dispatch never runs on a machine unless all three hold:
- an accepted trust edge exists from sender to recipient,
- the dispatch carries a valid signature from a device of that sender,
- it stays within the scope that edge grants - and destructive tool
calls get a per-call human approval.
Components
| Component | What it is |
|---|
| Broker | Multi-tenant FastAPI service, Postgres-backed. Issues identity, routes dispatches, enforces trust policy, relays events. Never holds a signing key; never touches a recipient's filesystem. |
Daemon (dispatch-daemon) | A small background process each user runs on their own machine. Holds that machine's Ed25519 device key, signs the user's outgoing dispatches, verifies incoming ones, and runs the agent. |
| Web UI | A React app (web/desktop) served both by the broker (/app) and by each daemon on 127.0.0.1: sign in, manage contacts + per-edge permissions, compose, watch sent dispatches, act on your inbox, run workflows. |
MCP server (dispatch-mcp) | A thin in-session client Claude Code launches per session. Holds no broker connection, key, or executor - it ensures a daemon is running and drives it over the daemon's loopback API so Dispatch works from inside Claude. |
| Agent | A Claude Agent SDK session the daemon opens per accepted dispatch, on a clean base (setting_sources=[]). Transient - created on accept, gone when the task ends. |
Every user is both a sender and a recipient; everyone runs a daemon.
The three enforcement layers
Trust is enforced in three independent places. A compromised broker cannot
forge a trusted sender, because Layer 2 happens entirely on the recipient's
machine against a key the broker can't substitute.
browser ── HTTPS/WSS ──▶ BROKER ── WSS ──▶ RECIPIENT DAEMON ──▶ Claude Agent SDK
│ │
Layer 1 ───────────────────┘ │
"Is there an accepted trust edge? In scope? │
Under the rate limit?" → else 403/429 │
│
Layer 2 ────────────────────────────────────────────┘
"Is the signature valid? Key pinned? Nonce fresh & unseen?" → else reject
│
Layer 3 ────────────────────────────────────────────┘
"Does the human approve this specific tool call?" → manual / auto per scope
Concepts
- User - identified by email. Created on first sign-in.
- Device - one per machine running the daemon. Has an Ed25519 keypair;
the private key never leaves the machine (OS keychain, or a 0600 file).
- Invitation - an emailed, single-use, expiring link. How a trust edge
is born.
- Trust edge - a directed
from_user → to_user relationship. Created
when the recipient accepts an invitation. Per-direction: B accepting A's
invite lets A dispatch to B, nothing more.
- Scopes - what an edge permits, set by the recipient (the trustor):
{
"tools": ["Read", "Glob", "Grep"], // subset of Read/Write/Edit/Bash/Glob/Grep
"mcp": [], // MCP servers a dispatch may use: bare
// names (["gog"]) or ["*"] for all
"paths": ["~/work"], // file-path allowlist ([] = no path limit)
"approval": "manual", // "manual" = approve every tool call | "auto"
"max_dispatches_per_day": 50,
"expires_at": null
}
New edges default to least privilege: read-only tools, no MCP, manual approval.
- Dispatch - one task. Signed by the sender's device, authorized by an
edge, executed by the recipient's daemon.
Letting dispatches use your MCP tools
A dispatch can use the recipient's own MCP servers (their Notion, search,
domain tools) - that's what makes it powerful - without exposing the rest of
your machine. No manual setup:
