Orchestrator: the agent runner on your own machine
2 min read
An orchestrator is the process running on a machine you control that claims
dispatched work and executes a coding agent against a local checkout. In
DevPilot it is started with devpilot bridge connect and it is the only
component that ever touches your source.
What it does
It registers itself against the hosted plane, receives a machine token, then either subscribes for push notifications or polls for work assigned to it. When it claims a job it runs the configured agent — Claude Code today, via adapter modes — against the repository already on disk, and reports status, completion, and any resulting pull request URL back.
The boundary it enforces
The division is the product, so it is worth being exact about it.
The hosted plane holds identity, routing, queueing and status. It receives the issue title, identifier, target repository name, and status updates. It never clones a repository, never holds git credentials, and never sees a working tree.
The orchestrator holds everything else: the checkout, the credentials, the agent process, and the output.
The precise version of the claim is worth stating, because the catchy version stopped being literally true. DevPilot does not move your source. What you can deliberately send is a shared session message — text you or your agent choose to paste into a transcript — and that is encrypted end to end with the key held outside our reach.
Why claims are scoped to the machine
Work is addressed to a specific orchestrator, and the claim asserts that:
WHERE id = $1 AND orchestrator_id = $2 AND claimed_at IS NULL
The second condition is not redundant. Without it, any registered machine could claim — or release — another organization's work by guessing a row id. The same reasoning governs the release path, which is scoped to the calling machine except when the system sweeper runs.
Rows are only ever offered to the machine they belong to, which is what makes a fleet across several developers' laptops safe to run against one queue.
Fleet, and what breaks
Several orchestrators can serve one organization — a laptop and a desktop, or one per developer. Routing decides which machine a given repository's work goes to, so two machines configured for the same repo will contend, and the dispatch queue resolves that with a conditional update rather than coordination.
An orchestrator that stops reporting mid-run leaves a claimed row behind. Claims expire after a timeout and return to the pool, which is the recovery path for a closed laptop, a dropped VPN, or a killed process. The timeout is the one genuinely arbitrary number in the design: too short and you re-dispatch work that is still running, too long and a dead machine parks an issue.