Switchboard and Watchtower: Local Agent Orchestration You Can Actually Supervise

The hard part of agentic coding is no longer starting an agent. It is knowing what should be worked on next, who is working on it, what changed, what was tested, and whether the result is ready to trust.

That is the problem Switchboard and Watchtower are designed to solve in SE Studio. Switchboard is the task intake and delivery board. Watchtower is the specialist review layer that sits inside it. Together they give local coding agents a workflow that looks less like a pile of terminal sessions and more like a software team with queues, handoffs, evidence, and review.

Why this exists now

OpenAI's Symphony spec put a useful name on a pattern that has been emerging quickly: issue trackers are becoming control planes for coding agents. Symphony's reference idea is simple and strong. Work lives in the tracker. A long-running service notices eligible tasks. Each task gets an isolated workspace and an agent. Humans review the result instead of steering every session by hand.

Switchboard is adjacent to that pattern, but the product bet is different. Symphony is centered on Codex app-server orchestration and Linear-style issue flow. Switchboard starts from SE Studio's local command-center model: bring the tools you already use, keep the work visible, let humans triage before execution, and make the handoffs explicit.

In practice that means the current runner can launch local Codex or Claude CLI processes. The task board is not pretending the cloud is doing everything somewhere else. The agents run from your environment, against your repo, with Git worktrees, logs, task comments, and evidence records that SE Studio can show back to you.

The board is the contract

Switchboard uses a file-backed board under `.multi-code/switchboard/`. Inbox items can come from manual creation, Watchtower review agents, GitHub import, Jira import work, campaigns, or Sprint Engine handoffs. The folder a task lives in is the source of truth for its state.

That sounds plain, and that is the point. The workflow does not depend on a hidden browser tab or a renderer-only state object. Tasks move through named folders: `planning`, `todo`, `ready`, `in_progress`, `testing`, `testing_in_progress`, `review`, `review_in_progress`, `done`, and `canceled`. Switchboard locks folders before moving work, validates transitions, and keeps comments, claims, execution attempts, evidence, and provenance on the task record.

inbox
  -> triage by human
  -> todo
  -> ready
  -> in_progress
  -> testing
  -> testing_in_progress
  -> review
  -> review_in_progress
  -> done

The human decision is still important. New findings land in the inbox. The user decides what deserves to become board work. Only after a task reaches `ready` does the runner have permission to pick it up for implementation.

The runner is a backend process, not a UI trick

The Switchboard runner is owned by the Python backend in `switchboard_core`. Electron starts or connects to that backend and forwards runner commands, but the renderer is not the source of truth. Runner state is persisted in `.multi-code/switchboard/runner/state.json`, events are appended to `.multi-code/switchboard/runner/events.jsonl`, and each execution gets its own metadata and logs under `.multi-code/switchboard/executions/`.

The runner watches three claimable queues: `ready`, `testing`, and `review`. A ready task is claimed by a developer role and moved to `in_progress`. A testing task is claimed by a tester role and moved to `testing_in_progress`. A review task is claimed by a reviewer role and moved to `review_in_progress`.

• `ready` claims become implementation work.
• `testing` claims become validation work.
• `review` claims become final review work.
• Publishing from implementation moves the task to testing.
• Publishing from testing moves the task to review.
• Publishing from review moves the task to done.

This gives the workflow a shape that humans can inspect. An implementation agent does not silently declare victory. It has to publish evidence before the card can move on. A tester has to record test commands or manual checks. A reviewer has to leave a verdict and residual-risk summary before the card is done.

Bring your own agent runtime

The first implemented provider is `local-process`. Today it supports two CLI choices: `codex` and `claude`. For Codex, the runner feeds the prompt into `codex exec`. For Claude, it uses Claude's print mode. The important part is not the exact command. The important part is that Switchboard can run against the local tools already installed on the developer's machine.

There is also a declared `codex-app-server` provider, but it intentionally fails before claiming work until that provider is implemented. That boundary matters. Switchboard should be able to grow toward app-server integrations without pretending an unsupported backend is production-ready.

For implementation work, the runner allocates a Git worktree under `.multi-code/switchboard/worktrees/`. The branch name is tied to the task and execution. That keeps the agent's edits isolated while preserving a concrete path back to the repo, diff, logs, commands, and eventual PR flow.

Watchtower turns review into intake

Watchtower is the other half of the system. It is not a separate workspace. It is the review and intake tab inside Switchboard.

A Watchtower run starts from a preset such as Lean Code Review, Performance Focus Review, Security Deep Review, or Full Product Review. SE Studio then launches selected specialist agents: code review, QA, performance, security, product strategy, frontend design review, infrastructure, and others depending on the preset.

Those agents are asked to work read-only unless the user explicitly asks for fixes. When they find something concrete, they do not hand-write task files or produce an output bundle for later scraping. They create Switchboard inbox tasks through the validated CLI contract.

scripts/switchboard create --workspace <repo> --inbox --input-json '<json-payload>'

That direct path matters. The CLI generates the task id, validates the shape, locks the inbox folder, writes atomically, and preserves provenance back to the Watchtower run and specialist agent. The inbox becomes the meeting point between autonomous review and human triage.

GitHub first, Jira next

Switchboard is being built as an issue-work surface, not a closed SE Studio-only board. The task source model already includes GitHub and Jira alongside manual, Watchtower, campaign, and Sprint Engine sources. The current direction is straightforward: fetch external issues into the inbox, let a human decide what should enter the execution board, then let the runner move accepted work through implementation, testing, and review.

The Git integration is especially important because implementation tasks are real repo work. The runner can create isolated worktrees now. The natural next step is to carry that through to branch hygiene and PR production, so an imported issue can become a reviewed change instead of a loose agent transcript.

What this changes in SE Studio

Before Switchboard, it was easy to describe SE Studio as a place to run many agents with strong visibility. That is still true, but it is no longer enough. The stronger product shape is now visible: SE Studio is becoming a local command center for agentic delivery.

Sprint Engine handles structured specialist sprints. Switchboard handles issue intake, triage, queue movement, runner execution, validation, review, and evidence. Watchtower feeds Switchboard with specialist findings before those findings become work.

The board should not just show what agents did. It should decide what agents are allowed to do next.

That distinction is the product lesson. Agents are useful when they are fast. They become dependable when the surrounding workflow is explicit: where work enters, who accepts it, where it runs, what evidence is required, how review happens, and what gets merged.

The near-term direction

The immediate work is to keep tightening the loop: richer runner status, better execution detail views, clearer worktree cleanup, stronger GitHub issue flow, Jira issue intake, and PR production from completed implementation runs. The underlying contract is already in place: queues, claims, local execution, evidence, review, and file-backed state.

That is why Switchboard and Watchtower feel like a turning point for SE Studio. They connect the product's original strength, visible local agent work, to the workflow shape teams actually need: issues come in, humans triage, agents execute, tests and reviews happen in their own lanes, and the result leaves behind enough proof to trust.