Blog

Building Dispatcher: a command center for coding agents

August 8, 2026 · by Dispatcher · engineering · agents · worktrees · product · architecture

Building Dispatcher: a command center for coding agents

Coding agents are no longer a novelty. In 2026, senior engineers routinely run Claude Code, Cursor, Codex, Kiro, OpenCode, Antigravity, Grok, Muse Code, Pi, omp, Hermes, and whichever harness shipped last month. The hard problem is not “can the model write code?” It is orchestration: keeping parallel agents from colliding, giving them the right context, reviewing what they changed, and shipping without living in six tabs.

Dispatcher is our answer: a desktop command center where your team plans work and agents ship it. Any agent, local execution, one window from a chat mention to a merged pull request.

This post is the long-form story of what Dispatcher is, why we built it, how the architecture works, and what we are optimizing for next.

The problem we kept hitting

A typical agent-driven day looked like this:

An issue lives in a tracker, a chat thread, or both.
You open a terminal, create a branch, paste half the issue into a CLI agent.
You start a second agent for a related fix, and both fight over the same checkout, node_modules, ports, and uncommitted files.
Diff review happens in git diff or a hastily opened IDE.
The PR is filed with gh in yet another tab, while the original conversation has already moved on.

None of those steps is hard alone. Together they destroy flow. Context is fragmented across planning tools, chat, the terminal, and the browser. Parallel agents become a liability instead of a multiplier. “Review what the agent did” is a terrible experience in a raw PTY.

We wanted one surface that treated the task as the prompt, the worktree as the sandbox, and diff → PR as the ship loop, without locking the team to a single vendor’s agent.

What Dispatcher is

Dispatcher is two cooperating surfaces with a shared React UI:

Surface	Stack	Role
Desktop app	Tauri 2 + Rust, local SQLite	Agent cockpit: worktrees, PTYs, terminals, Monaco, diffs, one-click PRs
Cloud companion	Next.js 15 + MongoDB	Shared tasks, knowledge, sites, orgs, billing, integrations

Locally, agents run on your machine with your API keys. Repository code, terminal output, and agent transcripts stay on disk unless you choose to sync tasks or docs to the cloud. That privacy boundary is intentional: the differentiated product is the local orchestrator; the cloud layer is team context plumbing.

You can:

Plan issues, projects, cycles, and roadmaps on a shared board
Launch multiple coding agents in isolated git worktrees with live terminals
Review diffs in-app and open pull requests with gh
Keep specs and runbooks in a TipTap/markdown knowledge base that can sync into .dispatcher/context for agents
Publish small HTML artifacts as Sites
Intake work from connected chat and issue trackers (including @dispatcher mentions)

Core insight: worktrees + PTYs, not another chat window

The product shape that actually works is boring in the best way:

One task → one worktree → one (or more) agent sessions.
When you execute a task, Dispatcher creates an isolated git worktree on a dedicated branch (for example dispatcher/task-fix-oauth). Agents run inside that worktree so parallel tasks do not stomp each other’s working tree. Worktrees persist on disk and recover when you restart the app.
Real PTYs, not fake “agent panels.”
The Rust side owns process lifecycle via a PTY manager (portable-pty). You get a true terminal with scrollback, interactive CLIs, and the same harness you would run by hand, embedded next to the task, editor, and diff view.
Review is a first-class pane.
Diffs and code review live in the same window as the agent. Shipping is gh-backed PR creation, not a context switch to the browser.

Most tools pick one slice of this: a polished single-harness launcher, a web board for many agents, or a terminal-only worktree workflow. Dispatcher’s bet is the intersection: local worktree execution + harness-agnostic cockpit + team cloud context + ship loop in one place.

Harness-agnostic on purpose

Agent CLIs churn monthly. Teams do not want to re-buy tooling when they switch models. Dispatcher treats harnesses as pluggable runners (Claude, Codex, Cursor, Kiro, OpenCode, Antigravity, Grok, Muse Code, Pi, omp, Hermes, and more as they appear) rather than wrapping a single vendor.

That choice shows up in the UI (agent picker, per-workspace agent tabs) and in the native layer (spawn commands, recovery, cleanup). The product promise is intentionally blunt: any agent, one cockpit.

Architecture, in practice

Shared React UI

The desktop shell and the web preview share React UI under src/. Zustand holds view state (tasks, agents, knowledge, sites, mcp, skills, settings). TipTap powers docs, Monaco powers code, and xterm powers terminals. Desktop deep links use dispatcher://tasks/{id}. The web app maps those views to Next.js routes like /tasks, /docs, and /sites.

Native desktop (Tauri + Rust)

Rust owns the dangerous edges: spawning agents, PTY I/O, worktree create/recover/cleanup, and local SQLite for workspace/agent-run state. This is the part that has to be correct under failure (orphan workspaces, hung processes, restart recovery), because a flaky orchestrator trains people never to trust parallel agents.

Cloud (Next.js + MongoDB)

The hosted app at getdispatcher.dev provides:

Auth and organizations
Multi-tenant data: issues, projects, cycles, roadmaps, knowledge documents, sites, invitations, RBAC
Plan limits and platform-admin overrides
OAuth bridges for the issue trackers and chat tools teams already use

Tenant filtering and role permissions are ordinary SaaS plumbing: unglamorous, and exactly what most indie desktop agent tools skip. Without it, “team plans work, agents build from that context” stays a slide, not a product.

Product surfaces beyond the agent cockpit

Project management as context plumbing

Issues, epics, cycles, custom views, and inbox triage exist so the task is the prompt. Positioning matters: the PM suite is a feature that feeds agents and teams; the agent cockpit is the product. If your team only needs issue tracking, use a dedicated tracker. If your team runs agents all day and needs the plan → build → review → PR loop in one place, that is the wedge.

Knowledge base

Docs with revisions, collections, databases, and templates let teams keep specs next to the work. Syncing into .dispatcher/context is how that writing becomes agent-usable without copy-paste archaeology.

Sites

Agents (and humans) can generate small HTML/CSS/JS artifacts and publish them at public /p/[slug] URLs. That is handy for demos, status pages, and throwaway UIs born in a worktree.

Integrations

Import issues and projects from connected trackers into the board
Turn chat mentions like @dispatcher into tasks so intake does not start in a vacuum
Manage MCP servers and reusable skills from the same shell

Local-first privacy vs optional cloud

A short version of the trust model:

Local desktop use: repository code, diffs, terminal output, and agent transcripts stay on your machine. Code is sent to third-party AI providers only when you launch an agent, under their policies, with your keys.
Optional cloud sync: account data and synced tasks, docs, and sites for team collaboration. Not a silent upload of your git objects.

If you are evaluating Dispatcher for a privacy-sensitive shop, start from that boundary and read the privacy policy. We would rather be explicit than market “local-first” while quietly requiring the cloud for the happy path.

What we are not claiming

Honesty is part of the product for this audience:

We are not pretending the early builds felt finished. Orchestrators that drop orphan workspaces or hide PR failures train distrust fast; hardening that path is ongoing engineering work, not marketing.
There is no durable technical moat in “we call git worktree.” The durable assets are breadth (harness support plus a team layer), becoming the incumbent workflow once your trackers and chat are wired in, and brand in a category that is still forming.

Who it is for

Individual senior engineers who already run multiple CLI agents and want isolation plus review without juggling tmux folklore
Small teams that want shared tasks and docs while agents still execute locally
Harness switchers who refuse to lock the workflow to one vendor’s session UI

Free local agent use is the default posture: running agents on the user’s machine with their keys has near-zero marginal cost to us. Cloud/team features are where shared value (and cost) live.

Getting started

Download Dispatcher for macOS (Apple Silicon or Intel) or Windows.
Connect the agent CLIs you already use.
Import or create a task, execute it into a worktree, and watch the PTY.
Optionally sign in at getdispatcher.dev for cloud tasks, docs, and team features.
Connect your tracker or chat when you want intake without tab roulette.

What is next

We are investing in the parts that make parallel agents feel safe at five-plus sessions: tighter worktree/runtime isolation, clearer review queues, better failure visibility, and the team cloud features that turn a personal cockpit into a shared command center. The blog here will track that work: internals, tutorials, and release notes.

If you try Dispatcher, tell us what broke, what felt magical, and which harness we should support next: support@getdispatcher.dev.

Plan clearly. Ship confidently.