Agent Orchestrator: A Desktop Harness for Fleets of Coding Agents

The problem is coordination, not capability

Single coding agents have become good at focused tasks. Run several across a repository and the bottleneck shifts. You need to decide what matters, split work cleanly, hand each agent the right context, avoid branch collisions, and track every change through review and merge. Agent Orchestrator, or AO, is a local desktop workspace built for that coordination job. It does not replace your coding agent. It wraps whatever agent you already use, giving each task its own workspace, branch, and feedback loop. The README is explicit: AO supplies project context, isolated execution, coordination, and an operational view. The intended user is someone who has already adopted agentic coding and now feels the pain of managing disconnected terminals, branches, and browser tabs.

Workers, orchestrator, and the Kanban as the core triad

AO has three structural pieces. A worker is the unit of execution: one task, one coding agent, one isolated workspace. You create a worker via New task, pick the agent and model, attach files, and work in structured Chat or the agent's native terminal UI. The orchestrator is a separate persistent planning agent that sits above workers. It keeps a project-scoped conversation about goals, decisions, and constraints, and it can break a plan into tasks, spawn workers, pass context, and coordinate follow-up. The Kanban is the operational surface. Each worker appears as a card, and AO derives the card's column from session, pull request, CI, and review facts. Columns are Working, Needs you, In review, and Ready to merge. The distinction between workers and orchestrator is clean: the orchestrator owns planning and delegation, workers own implementation, tests, commits, and pull requests.

Isolation and feedback loops are the real mechanism

The mechanism that makes fleets work is isolation plus a closed feedback loop. Every Git-backed worker gets its own branch and worktree. Scratch workers, for tasks that do not need Git, get AO-managed branchless directories. This prevents the classic failure of parallel agents colliding on the same working tree. The loop closes through the daemon. AO's local daemon watches agent activity and source-control state, and it feeds CI failures, review comments, and merge conflicts back to the agent that owns the work. The README says the daemon 'watches agent activity and source-control state' and that the result is a shared, live view. That is a different architecture from a hosted CI bot. Everything runs locally, which means your code and agent conversations stay on your machine, but it also means the daemon must be running and your Git provider must expose the state AO needs.

Getting it running and configuring a worker

The README points to a Download AO link and the documentation site at aoagents.dev/docs. Installation is via a desktop app, not a CLI tool. There is no command-line installation shown in the material. After adding a repository, you create a worker session. The README lists the choices: the coding agent, the model, and the interface (structured Chat or native terminal UI). For Git-backed work, AO creates the branch and worktree automatically. The orchestrator is a separate session you start at the project level. The configuration keys are not documented in the README; the docs site would hold those. The release page shows nightly builds, for example v0.12.10-nightly.202608290454, which suggests a fast-moving project where you may need to track nightly changes.

Where AO is the wrong tool

AO assumes you already have a coding agent you like. It does not provide one. If you are evaluating your first agent, this project adds nothing until you have an agent to supervise. It also assumes Git-backed work and a source-control workflow. Scratch workers exist, but they are described as branchless directories, which means you lose the PR and review integration that is central to the Kanban. The Kanban's Needs you column depends on signals like failed CI and requested changes. If your CI provider or Git host does not expose those signals in a way the daemon can read, the board will show stale or incomplete state. The README does not list supported Git providers or CI systems, so you must verify that compatibility yourself. Finally, the desktop app plus local daemon means every machine running AO must keep both alive. That is a heavier operational footprint than a hosted service.

A real alternative: plain Git worktrees plus a CI bot

The closest alternative is to build the coordination manually with Git worktrees and a CI bot. Git worktrees give each agent its own checkout directory, which solves the branch collision problem that AO solves with worktrees. A CI bot, such as a GitHub Action that comments on PRs, can send CI failures and review comments back to an agent. The difference is that this alternative has no orchestrator and no Kanban. You would need to decide task splits yourself, and you would track state by looking at separate PR pages and CI logs. AO centralizes those signals into one board and adds a planning agent that can delegate. The trade-off is control versus convenience. The manual approach is transparent and uses only tools you already have, but it scales poorly past a few parallel tasks. AO is a bet that the orchestration layer is worth the extra moving parts.

Maintenance, license, and upgrade cost

The project is written in Go and licensed under Apache-2.0. That license allows commercial use, modification, and redistribution, with attribution. The repository is not archived, and the last push is dated 2026-08-29, with multiple nightly releases on the same day. That signals active development, but also a high churn rate. Nightly builds mean you may be exposed to regressions if you track the latest release. The README mentions a Contributing guide and a Discord server, so there is a community channel for support. The upgrade cost is not documented in the README. You should expect to read release notes for each nightly to understand breaking changes. The daemon and desktop app are separate processes, so upgrading likely means updating both. There is no mention of a migration path or data format stability, so treat session state as potentially fragile across versions.

What the orchestrator actually decides

The orchestrator is not a task executor. It is a planning agent that works at the level of product direction, technical strategy, and sequencing. The README says it 'combines that planning history with repository context and live AO state, including active workers, ownership, pull requests, CI, and reviews.' That means the orchestrator can see what is already in flight before it delegates. It can 'break a plan into focused tasks, spawn or redirect workers, pass each worker the relevant context, follow their progress, and coordinate follow-up work.' The key phrase is 'redirect workers.' That implies the orchestrator can reassign work based on live state, not just create new tasks. This is a stronger capability than a simple task queue. However, the README does not specify how the orchestrator decides priorities or how it weighs conflicting signals. That decision logic is likely in the code, not documented here, so treat its behavior as a black box until you test it.

Editorial conclusion

Adopt Agent Orchestrator if you already rely on coding agents like Claude Code and need a single local pane to supervise parallel work, track PRs, and return CI failures to the right agent. Skip it if you want a new agent or a hosted CI service, because AO assumes your existing agents and your own Git hosting. Before committing, verify that your agent's native terminal UI works inside AO's harness, that your Git provider's CI status is readable by the daemon, and that the nightly release cadence (v0.12.10-nightly builds) matches your tolerance for frequent updates. The project is Apache-2.0, so you can fork and adapt it, but the real test is whether the orchestrator's delegation decisions match your team's actual priorities.

Official sources

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