Agent Orchestrator: one worktree per task and a loop that routes CI failures back to the owning agent

A main agent plans, workers each get a branch and a worktree

The core idea is splitting one request across many agents without their branches colliding. You tell a project's main agent what you want built. It plans the work, starts a worker for each piece, and gives every worker its own agent, branch and worktree. The main agent comes back to you only when something needs a decision. The tool runs as a local desktop workspace, and the project states that your code stays on your machine. That is the difference from asking one agent to do everything in a single checkout: parallel workers never edit the same working tree.

CI failures, review comments and conflicts flow back to the branch owner

The part that justifies the tool is what happens after a pull request opens. Failed checks, review comments and merge conflicts are sent back to the worker that owns the branch, and that loop repeats until the PR is approved. A reviewer agent can also read every PR before a person does. The consequence for a human is that you stop copying CI logs into chat windows. The cost is trust: the loop keeps an agent working on a branch automatically, so you need to watch what it pushes rather than assume each retry is correct.

Sessions sort themselves into lanes on one board

Every session appears on a single board, sorted into lanes from the state of the agent, its PR, CI and reviews, so whatever needs you rises to the top. Each worker also gets a browser to preview and test its app, and you can talk to it in structured chat or drop into the agent's own terminal UI. Agent and model are chosen per task, so one fleet can mix different tools.

Long agent list, uneven support per role

The supported list is long: Claude Code, Codex, Cursor, opencode, Aider, GitHub Copilot, Gemini CLI, DeepSeek, Goose, Cline and many more. The catch is in one sentence: Worker, Chat and reviewer support differ by agent, and the current matrix lives in the agent setup guides at docs.orchestrator.inc. Seeing your agent's name is not proof it can act as a reviewer or run the CI loop. Check the matrix for your specific agent before designing a workflow around it.

Only nightly builds in the recent release stream

The last push to main was on 2 November 2026, and the three most recent releases are all nightly tags of the same line, such as v0.14.9-nightly.202611030413, published within days of each other. The version is still below 1.0. Teams wanting a fixed, tested version will have to pick a nightly and hold it. A desktop-version-floor.json file at the repository root suggests the project sets a minimum desktop version, so older installs may be asked to update.

The frontend and Go backend share a generated OpenAPI contract

For contributors, the root package.json shows how the halves fit together. The api:spec script runs go generate inside backend/internal/httpd/apispec, and api:ts feeds the resulting openapi.yaml to openapi-typescript 7.4.4 to write frontend/src/api/schema.ts; npm run api does both in order. Database access is generated too: the sqlc script runs sqlc v1.31.1 in backend, and migration:create calls scripts/create-migration.mjs. The lint script runs go test across the backend before golangci-lint v2.13.2. The cloud:check script regenerates the cloud-client schema and fails on any git diff, so a hand edit to a generated file breaks the check. A flake.nix and flake.lock sit at the root alongside .envrc. The practical consequence: changing an endpoint means regenerating both sides, and forgetting api:ts leaves the frontend typed against a stale schema.

Three names for one project

The repository sits at Untrivial-ai/agent-orchestrator, the product is called Orchestrator.inc, the homepage is aoagents.dev, and the README badges and release links point to OrchestratorInc/agent-orchestrator. The app itself is obtained from orchestrator.inc rather than through a package manager command. When filing issues or verifying a download, make sure you are on the repository and site you meant. The source is split into a Go backend/ with a go.work workspace, a frontend/, and packages/ that include cloud-client and product-ui, under the Apache-2.0 license.

Editorial conclusion

Agent Orchestrator suits developers already running several coding agents in parallel who lose time shepherding branches through CI and review. If you use one agent at a time, the orchestration layer adds little. Before adopting it, check the agent setup guides for whether your agent supports Worker, Chat and reviewer roles, and decide whether you are comfortable on nightly builds.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes