switchyard

a git platform for fleets of coding agents

many agents,
one main

switchyard gives every agent its own lane, tells agents when their work overlaps, and lands their changes on main through checks. it follows your github repository, so your team keeps working where it does today.

already using switchyard? sign in to the app

three agent lanes flow into a merge train that lands on main lanes L1, L2 and L3 each belong to one agent. a signal warns L1 and L2 that both touch cart.ts. the merge train runs checks and lands the lanes on main, which follows github. signal · cart.ts L1 · claude apple pay L2 · codex tax rules L3 · cursor receipts train checks ✓ main follows github

the problem

agents collide

put ten agents on one repository and they get in each other's way. two rewrite the same function. a third builds on code that is about to change. nobody finds out until the merge fails.

pull requests were built for people

one author, one branch, one reviewer with time to read. agents open dozens of changes an hour, and the review queue becomes the bottleneck. writing the code is fast; landing it is slow.

how it works

  1. 01 a lane per agent

    each agent gets a lane: its own fork of the repository in cloudflare artifacts, and a token that can push to that fork and nothing else. agents use plain git, the yard cli or mcp.

  2. 02 plans and signals

    before it writes code, an agent states its plan: the files and symbols it will touch. on every push, switchyard merges main with every lane and tells both agents when their work overlaps, with advice on which goes first.

  3. 03 a merge train with checks

    finished lanes join the merge train. it tests them together on top of main, runs your checks in containers and lands only what passes. when a batch fails, it finds the lane that broke it and lands the rest.

  4. 04 follows github

    a project follows a github repository. landings go to github first, and pushes made there flow back in. github stays the authority for your people; switchyard handles the agents.

measured, on cloudflare

100 agents, one project

agents on one project, and every lane landed
100
landings on main for those 100 lanes
15
from submit to landed at the median, and 108 s at p95
71 s
artifacts operations per landed lane
8.1

a load test against the deployed service: 100 agents, three pushes each, twenty at a time. the train batched lanes together, so main moved 15 times instead of 100.

for fleets

one mcp server, many agents

point a whole fleet at one switchyard mcp server. each connection claims its own lane, so an orchestrator can start fifty agents without fifty setups.

lane tags new

tag each lane with its workflow run, phase, agent and task. filter by any tag to follow one run from its plans to its landings.

built on cloudflare

  • workersthe api, the mcp server and the board, close to every agent.
  • durable objectsone coordinator per project: lanes, plans, the operation log and the train.
  • artifactsa git repository per project and a fork per lane, with push events.
  • containersthe merge engine and your checks, each in its own container.

join the waitlist

we are opening the hosted version to teams a few at a time. leave your email and we will write when there is room for you.

we keep your email, your two answers, your browser's user agent and when you joined, to plan the rollout. we do not store your ip address, and we send nothing else.