Switchboard as a Service · we run your ticket queue

We run the queue.
You keep the merge.

Switchboard is a control plane for AI coding work. As a Service, we run it for you. Hand us a bucket of tickets and we sit the gates that are ours to sit — intake, triage, file writes, commands, plans. The one gate that is never ours is merge approval.

Fewer pull requests. Better ones.

Want to run it yourself? The desktop app →

Where the work sits

Your people

  • Eng leaders
  • Tech leads
  • Developers
  • Reporters / PMs

SwitchboardOrchestration layer

  • Refuse
  • Enforce
  • Gate
  • Prove

The tools you already run

  • GitHub
  • Jira
  • Excel · CSV
  • Claude agent
  • CLAUDE.md
  • Your CI
  • Code never leaves your machine
  • Your own Anthropic key
  • GitHub · Jira · Excel · CSV
  • Refused or delivered — no third state

Switchboard, defined

Read this if you read nothing else

Switchboard is the orchestration layer between your team, your tools and your AI agent. It decides which work an agent may start, how it must work, and where it has to stop for a human.

What it is

A desktop control plane for Claude-powered coding runs, on macOS and Windows, using your own Anthropic key.

What it does

  • Refuses tickets that aren’t ready
  • Enforces your CLAUDE.md, mechanically
  • Gates writes, commands, plans, merge
  • Proves every run with an audit bundle

What it isn’t

Not a new tracker, code host or CI. Not another agent. It never merges to production. It governs the tools you already have.

How you get it

Switchboard — the software. Your team sits every gate.

+ As a Service — the extension. We run the queue; you keep the merge.

How it worksSame product, same gates — we sit the ones that are ours

We run the queue. You keep the merge.

Hand us a bucket of tickets and we sit the gates that are ours to sit — intake, triage, file writes, commands, plans. The one gate that is never ours is merge approval.

  1. 01 Intake

    As a ServiceUs

  2. 02 Triage

    As a ServiceUs

  3. 03 Run + gates

    As a ServiceUs

  4. 04 Pull request

    As a ServiceUs

  5. Review

    As a ServiceYou

  6. Merge

    As a ServiceYou

  7. Promote

    As a ServiceYou

Ours to sit in service modeThe merge line · always yours

  • Every ticket comes back as

    Refused — with its gaps named

    Refused at triage goes back to the reporter. The run ends there, successfully.

  • Or

    A pull request, green on your CI

    There is no third state. Review, merge and promotion stay with your team.

  • Optional · mode B only

    Merge to your test branch

    Under your own branch protection. Production promotion is never ours.

As a Service · two ways to run it

Your estate, or ours.

Switchboard’s first policy is that source code never leaves your device. One of these two modes keeps that promise exactly as written. The other does not, and we would rather you read it here than discover it after signing.

How the two Switchboard as a Service modes differ
PropertyMode A · In your estateMode B · In ours
Where the code sitsMode A · In your estateOn a machine you own — your VDI, jump box, or a dev box in your own cloud accountMode B · In oursCloned into an isolated environment we own
Whose model keyMode A · In your estateYoursMode B · In oursYours, held per engagement
What you provideMode A · In your estateAccess to a dev box or VDIMode B · In oursA repository grant and an NDA
First pull request inMode A · In your estateDays — access provisioning is the gateMode B · In oursHours
“Code never leaves your machine”Mode A · In your estateHolds, verbatimMode B · In oursDoes not hold
Merge to test branchMode A · In your estateNever — merge is yoursMode B · In oursOptional, under your branch protection

Work we deliver is authored by a service identity created for your engagement, not by a named Atharvix engineer — so it is filterable in your own audit and no individual ends up in your history permanently.

Engagement

Four ways to buy it.

Pilot

A named ticket bucket, an agreed acceptance bar and a date. You get the metric moved, or you get the reason it did not.

One bucketfixed scope, one date

Available now

Per ticket

Refused or delivered, nothing in between. A ticket that fails Definition-of-Ready goes back with its gaps named and is not billed as delivery.

Per ticketaccepted into the queue

Available now

Retainer

Committed throughput against your backlog, with every run’s outcome, cost and root cause visible in the ledger as it happens.

Per montha standing queue

Available now

Assured

A merge rate we commit to. We do not quote one until we have run your backlog long enough to price it — a number we have not measured is not a number.

Per monthplus a committed rate

After we have measured your backlog

What can it actually do? · Before · during · after

Refuse. Enforce. Prove.

  1. 01Before

    A ticket that isn’t ready becomes a question, not a pull request

    Readiness triage runs before any code, against your repo’s stated criteria. Tickets that fail go back to the reporter with the exact gaps named — never a guess. The cheapest agent run is the one that doesn’t happen.

  2. 02During

    Your process. Mechanically, not aspirationally

    Every tool feeds your CLAUDE.md to the model as advice and hopes. Switchboard blocks the first file write until the disciplines your repo prescribes have actually been invoked. A repo that prescribes none works unmodified.

  3. 03During

    Blocking gates, not advisory notices

    File writes, commands, plans, questions and merge approval pause the run and wait for a human. The agent cannot proceed. Every path fails closed — an unreachable supervisor blocks the agent; it never lets it through.

  4. 04After

    A record of what was decided — not just what it cost

    Every run writes effort, outcome, cost and root cause back to the ticket, and exports as a hashed audit bundle. Admins see what each member ran and what it bought, across eight outcome states — and never the transcript.

  5. 05Across

    Ticket connectors that meet you where you are

    GitHub Issues, Jira, an Excel workbook, or a plain CSV. No credentials stored, no webhooks, no setup on GitHub. Every ticket gets its own branch and worktree, so parallel runs never collide.

Switchboard — queue — an illustration of the four states a ticket can be in
  • BeforeRefuse
  • DuringEnforce · Gate
  • AfterProve
  • REV-204Needs-info

    “Improve onboarding”

    Back to reporter: no acceptance criteria; affected screens not named.

  • REV-207Write blocked

    Add retry to export job

    First file write held until the prescribed disciplines are invoked: 1 of 2 done.

  • REV-198Gate · Plan

    Fix flaky auth tests

    Plan ready: one change per test, test files only. Approve to continue.

  • REV-211PR open · merge is yours

    Fix timezone bug in digest

    Effort, outcome, cost and root cause written to the ticket. Audit bundle hashed.

Anatomy of a run

Six places a run can stop, and five of them are yours.

One run, one ticket. Autonomous where it’s safe, stopped at your door where it isn’t — and it never merges.

The six steps of a Switchboard run and which of them stop for a human
StepWhat happensStops for you
01 · Ticket picked upWhat happensRead from GitHub, Jira, a workbook or a CSV — full context, comments and all. You choose exactly which fields the agent sees.Stops for you
02 · Readiness triageWhat happensFails Definition-of-Ready? It goes back to the reporter as needs-info with the exact gaps, and the run ends there — successfully. Ready? It proceeds.Stops for youGate
03 · Process declared, then enforcedWhat happensThe run declares which disciplines your repo prescribes. The first file write is blocked until each one has been invoked.Stops for youGate
04 · Work on an isolated branchWhat happensFeature branch or worktree, per your repo’s conventions. Main is never touched. Stalls, context saturation and quota stops are caught, not recorded as success.Stops for you
05 · Plans, commands, writes, questionsWhat happensEach pauses the run until a human answers. If the supervisor is unreachable, the agent is blocked — never waved through.Stops for youGate
06 · Pull request & merge approvalWhat happensA pull request opens with effort, outcome, cost and root cause written back to the ticket. A claimed PR is checked against the real repo — a fabricated one is flagged, not filed as done. Merging is a human decision, every time.Stops for youGate

See it on a real run

One ticket, start to finish. Every figure read off the audit.

REV‑198 → PR #347, 54 minutes, two operator gates. Quoted from the session’s own export — 3,399 events, nothing inferred.

See the full run breakdown

  • 54 minTicket → merged PR
  • 230Tool calls
  • 7Subagents
  • 9Skills invoked
  • 2Human “yes” gates
  • 3,399Audited events
  1. Switchboard · session audit · 15 Sep 2026

    From flaky ticket to merged PR in fifty-four minutes

    REV-198PR #347, squash-merged to main as eca10b0. 230 tool calls, 7 subagents, 9 skills — and two points where a human said yes.

  2. The ask · Jira REV-198

    Three tests failed once each, then passed on re-run at the identical tree.

    CI is disabled, so local runs are the only evidence there is. Scope was fixed by the ticket: test files only, no production code.

  3. Gate 1 · human decision · 02:02 → 02:34

    The run stopped and asked a human before writing any code.

    It put the whole diagnosis in front of the operator in plain language — one paragraph per test, naming the exact file and line, the fix, and what it deliberately would not do. It also flagged the limit of its own work: these fixes cannot stop an outside writer touching the shared database.

    Operator answeredApprove — implement exactly this triage and plan

  4. Build · test-first · 04:14 → 18:40

    Every fix was proven by breaking it first.

  5. Review · three agents, in parallel · 19:51

    Three reviewers ran at once, and two of them converged on the same residual flake.

    The flood test could pass with fetch_count at zero — a 401-before-JWKS path never reaches the endpoint. It gained the floor assertion its own docstring already claimed.

  6. Finding 01 · deviation from acceptance criterion 1

    The ticket’s own acceptance criterion could not pass.

    The prescribed watermark — created_at >= clock_timestamp() — was implemented verbatim and failed. The run measured why rather than tuning it green: created_at carries the transaction’s transaction_timestamp(), landing 0.04–2.05s before the PATCH. It excludes the row it selects.

  7. Finding 02 · found, proven, deliberately not fixed

    A test-only ticket surfaced a real production bug.

    Impact is low: rotation runs from a single scheduled job, and the reader takes ORDER BY created_at DESC LIMIT 1.

  8. Finding 03 · the panel corrected itself · 42:14

    A reviewer retracted its own claim before it reached main.

    In round one it asserted a mechanism — that a FOR UPDATE lock serialized the two concurrent rotations — and a docstring was written to match. In round two, the same reviewer found that claim was wrong.

  9. Verification · read off the final tree · 44:00

    Twenty of twenty iterations green. 2,145 passed, zero failed.

  10. Gate 2 · merge approval · 51:56 → 52:25

    The merge request named the two things the operator should weigh before deciding.

    Operator answeredMerge #347 into main (squash, delete the branch)

  11. Shipped · 14:49:29 UTC

    eca10b0 is on main. Four files, +106 / −33, no production code.

    Branches deleted, local main fast-forwarded, working tree clean. REV-198 closed Done with all five stage sub-tasks. Five items were left open on purpose — each written into the pull request rather than carried in someone’s head.

What systems does it integrate with?

Plugs into what you run today. Asks you to migrate nothing.

No credentials stored. No webhooks. No setup on GitHub. Each system stays in charge of what it already owns.

  • Tickets · code · review

    GitHub

    GitHub Issues in; a pull request out, into your existing review flow. One branch and worktree per ticket.

  • Tickets

    Jira

    Read with full context and comments. Effort, outcome, cost and root cause are written back to the ticket.

  • Tickets

    Excel & CSV

    For teams whose real backlog is a workbook or an export from another tracker. You choose which fields the agent sees.

  • Model

    Anthropic API

    Claude on your own key and account. Pick the model per run — you keep the contract, limits and bill.

  • Process

    CLAUDE.md

    Your repo’s own conventions become enforced gates. Update the file, the rules update.

  • Desktop

    macOS + Windows

    A local app beside your repos. Source code never leaves your device.

The software · shipping soon

The desktop app is built. It’s in release preparation now.

The service on this page already runs on it. Every gate described here — intake, triage, file writes, commands, plans — is one we sit today, on your behalf.

How Switchboard protects your code

  • Local-first

    A desktop app. Source code never leaves your device.

  • Your own key

    Claude runs on your Anthropic account, under your terms and limits.

  • Fails closed

    An unreachable supervisor blocks the agent. It never lets it through.

We run the queue. You keep the merge.

Fewer pull requests.
Better ones.

Switchboard as a Service — from AtharvixPrivacyTermsContact