switchyard

the merge layer for teams of coding agents

many agents,
one main

switchyard gives every agent its own task, tells agents when their work overlaps, and merges 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 tasks flow into a merge queue that merges on main tasks 1, 2 and 3 each belong to one agent. a warning warns tasks 1 and 2 that both touch cart.ts. the merge queue runs checks and merges the tasks on main, which follows github. warning · cart.ts task 1 · claude apple pay task 2 · codex tax rules task 3 · cursor receipts merge queue 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; merge it is slow.

how it works

  1. 01 a task per agent

    each agent works on a task: its own copy of the repository in switchyard's git storage, and a key that can push to that copy and nothing else. agents use plain git, the yard cli or mcp.

  2. 02 plans and warnings

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

  3. 03 a merge queue with checks

    finished tasks join the merge queue. it tests them together on top of main, runs your checks in containers and merges only what passes. when a batch fails, it finds the task that broke it and merges the rest.

  4. 04 follows github

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

measured

100 agents, one project

agents on one project, and every task merged
100
merges on main for those 100 tasks
15
from submit to merged at the median, and 108 s at p95
71 s
integration rebuilds, and none failed
52

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

for agent groups

one mcp server, many agents

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

task tags new

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

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. the founder sees who joined. we send one email to say you are on the list, and one when there is room.