9 Open-Source Agent Orchestrators for AI Coding (2026)

Open-source agent orchestrators let me run multiple AI coding agents in parallel across isolated git worktrees, but most still leave task alignment, conflict resolution, and merge decisions on my plate.

This review covers nine numbered entries (eleven tools in total, since the Conductor entry bundles three variants): Agent Orchestrator, Emdash, Baton, the Conductor family (conductor.build, Code Conductor, Microsoft Conductor), Bernstein, Claude Squad, Crystal/Nimbalyst, Vibe Kanban, and Agent Kanban. The goal is practical: give you enough detail to pick the right coordination depth for your workflow, and show where a hosted platform takes over when OSS tools hit their limits. Cosmos is Augment Code's unified cloud agents platform, generally available on paid plans, and it anchors that end of the range.

Why Parallel Agent Tooling Exists

The single-agent IDE assistant assumes one writer, one working directory, one mental model. That assumption breaks the moment I try to run three agents against the same repo. They clobber each other's files, fight over the dev server port, and leave me reconstructing what happened from git reflog.

Every tool in this roundup exists because the OSS community hit that wall and had to solve it. Git worktrees became the consensus isolation primitive within about eighteen months, and the interesting differences are what each project built on top of that foundation. The same period produced a second category above them, the cloud agent platform, which moves the runtime off the developer's machine entirely.

What I Evaluated

I scored every tool against four criteria that matter when I'm running three to six agents on a real codebase. The quick reference:

The coordination axis is where the tools diverge most. I think of it as a three-step ladder:

1. Per-edit approval (human-in-the-loop): I review every change before it lands. Claude Squad, Crystal/Nimbalyst, and the Conductor family sit here.
2. Milestone gates (human-on-the-loop): The tool handles retries and CI failures autonomously, and I step in at PR time. Agent Orchestrator, Bernstein.
3. Platform-managed loops: Agents run as a standing service off shared triggers, with reusable Experts, memory that carries between runs, and human checkpoints at the consequential steps. Cosmos.

With those criteria set, here's how each tool performs in practice.

1. Agent Orchestrator (Formerly Composio Agent Orchestrator)

Repository: Untrivial-ai/agent-orchestrator, formerly ComposioHQ/agent-orchestrator | License: Apache-2.0 | Install: desktop app, or npm install -g @aoagents/ao (legacy)

Agent Orchestrator (AO) is a full-automation system: multiple agents running in isolated worktrees, each with its own PR, supervised from a single control surface. Of every tool I tested, AO is the one that pushes hardest past session management into autonomous PR handling. Agents fix CI failures, respond to review comments, and manage their own PR lifecycle without asking me to approve each edit.

I tested AO on a mid-size TypeScript monorepo with flaky tests. The lifecycle manager caught three CI failures, pulled the logs, fed them to the agent, and retried twice before escalating one to me. The autonomy held up under realistic conditions, which is the behavior I want from a parallel runner.

Isolation: A separate git worktree per session, with its own branch and terminal.

Agent support: 26 worker agent harnesses, including Claude Code, Codex, Aider, OpenCode, Cursor, Copilot, Goose, Amp, Droid, and Kimi. Reviewer agents are configured separately from workers, with their own harness list. The plugin architecture is where new adapters get added, and extending it works as cleanly in practice as the docs claim.

Coordination: Human-on-the-loop with milestone gates. CI failures, review comments, and merge conflicts route back to the session that produced them. Agent crash recovery polls and attempts automatic restarts.

UI: Desktop app as the main control surface, with projects on the left, active sessions in the center, and the selected session's terminal or structured chat, PR state, review runs, and an in-app browser preview in the inspector. A local daemon watches session state, CI, and review feedback.

Known limitations: Agents go idle more than I expected between steps. On a four-agent run, two sessions sat idle for 90+ seconds waiting on tool approval. If you're paying per-token, that idleness adds up. The project also moved from ComposioHQ to Untrivial-ai and froze its npm CLI at 0.10.0, so older tutorials point at package names and install paths that no longer receive updates.

Choose AO if: You want PR-level autonomy and don't mind running a desktop app with a background daemon. Skip AO if: You need per-edit review or work primarily offline.

2. Emdash (YC W26)

Repository: generalaction/emdash | License: Apache-2.0

Emdash is the Electron desktop app I reach for when a team uses a mix of coding agents. It positions itself as an "agent-first development environment," and breadth is its defining feature: 34 CLI providers including Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, Goose, Kiro (AWS), Pi, Qwen Code, and Hermes Agent.

The port collision story is what sold me on Emdash's engineering seriousness. The .emdash.json config defines setup, run, and teardown scripts per task, and $EMDASH_PORT injection gives each task a unique port: PORT=$EMDASH_PORT pnpm run dev. That solves the shared-port problem worktrees leave open, which almost no other OSS tool in this list handles cleanly.

Isolation: Git worktrees locally or on remote machines over SSH. Setup and teardown scripts per task.

Agent support:

Coordination: Parallel, human-supervised, worktree-isolated. Agents run independently; I assign tasks, review output, and merge.

UI: Electron desktop with ticket intake from Linear, GitHub, Jira, GitLab, Asana, Featurebase, Monday.com, Forgejo, and Plain, plus inline diff inspection, commenting, and PR creation.

Known limitations: No agent-to-agent coordination, no shared config across agents. If one agent learns the codebase's test conventions, the other five don't benefit. Teams wanting task decomposition or pre-merge quality gates will need to layer tooling on top.

Choose Emdash if: Your team uses a mix of CLI agents and you want a desktop UI. Skip Emdash if: You need agents to coordinate with each other and not simply run side by side.

3. Baton

Repository (OSS): mraza007/baton | License: MIT | Language: Python

Two projects share the "Baton" name. I tested the open-source mraza007/baton, which polls GitHub Issues and runs Claude Code in isolated worktrees. The second Baton (getbaton.dev) is a desktop app for monitoring multiple agents including Codex CLI; its source availability isn't clearly documented.

The mraza007/baton architecture is narrow by design. A Poller runs gh issue list to find matching issues, a Dispatcher controls concurrency across parallel workers, and a Reconciler detects stale runs. All configuration lives in one WORKFLOW.md file with YAML front matter and a Jinja2 prompt body:

# Baton workflow (simplified from README)
# WORKFLOW.md YAML front matter configures:
#   - poller settings
#   - concurrency limits
#   - prompt templates via Jinja2
baton start  # Begins poll-dispatch-reconcile loop

Isolation: Git worktrees, one per GitHub Issue.

Agent support: Claude Code, which is the only agent the project documents. The agent.command setting takes any CLI, so another agent can be substituted, but nothing else ships configured.

Coordination: Poll-dispatch-reconcile loop. No task graph, no verification.

UI: CLI-only with Click and color-coded terminal logging. No TUI, no GUI.

Known limitations: No automated merge conflict resolution. Worktree isolation is repo-level, not machine-level, so shared services still collide. If your issue queue is messy, Baton's polling turns that noise into agent runs.

Choose Baton if: GitHub Issues is already your task queue and you want zero extra UI. Skip Baton if: You want a visual dashboard or multi-agent coordination.

4. Conductor (Three Projects, One Name)

"Conductor" refers to at least four distinct projects in AI coding. I'm covering three relevant ones below and skipping Netflix Conductor, which solves workflow orchestration in a completely different domain.

Here's the quick synthesis. conductor.build is a polished macOS desktop app but closed-source, so it falls out of scope for an OSS roundup. Code Conductor (ryanmac/code-conductor, MIT) is a GitHub-native CLI that labels issues conductor:task and lets agents claim them, though it supports only Claude Code. Microsoft Conductor (microsoft/conductor, MIT) is the most credible long-term bet: a CLI tool for defining and running multi-agent workflows with the GitHub Copilot SDK and Anthropic Claude, with YAML-defined workflows and a web dashboard. It has moved quickly: version 0.1.27 now documents static and dynamic parallel groups, reusable sub-workflows with templated input mapping, script and terminate steps, dialog mode for agents that need to ask before proceeding, and conditional routing with no LLM in the orchestration loop.

Choose a Conductor if: You want YAML-defined workflows (Microsoft) or a GitHub-Issue queue (ryanmac). Skip them if: You need production-ready tooling today; Code Conductor is earlier-stage than AO or Bernstein, and conductor.build is closed to inspection.

5. Bernstein

Repository: sipyourdrink-ltd/bernstein | License: Apache-2.0 | Install: uv tool install bernstein or pipx install bernstein

Bernstein is the most architecturally interesting tool in this roundup. It implements a full planning-to-merge pipeline: Goal → LLM Planner → Task Graph → Orchestrator → Agents (parallel) → Janitor (verify) → Git merge → main. I tested it on a small refactor task across three files, and the Janitor caught a type error one agent introduced before it reached the merge queue. Pre-merge quality gates worked as documented.

Three properties separate Bernstein from everything else:

• Deterministic scheduling. The orchestrator uses Python code for every scheduling decision, with no LLM calls involved. Same inputs produce the same outputs regardless of how agent responses interleave.
• Zero LLM tokens on coordination. The LLM runs once, during initial goal decomposition. After that, scheduling costs nothing in tokens.
• Verifiable after the fact. State lives in a .sdd/ directory outside agent memory, with an always-on lineage spine and replay journal, plus an opt-in HMAC-chained audit log whose receipts verify offline.

Isolation: Git worktrees per coding task, behind merge gates.

Agent support: 49 selectable adapters wired into the registry, though the maintainer recommends the proven three (Claude Code, Codex, Gemini CLI) for production runs.

Coordination: The Janitor runs lint, type checks, and tests before merge. Only verified work lands.

UI: Terminal dashboard with live agent logs and a task board, plus a browser view for task graph inspection and diffs.

Known limitations: Adapter parity is the real constraint. Stop and restart behavior, output shape, and error handling vary by adapter, which is why the proven three are the safe production choice. Multi-node execution exists, but single-host orchestration is the default, so large fan-outs still bottleneck on one machine. Model routing, retry escalation, and cost controls are documented but not omniscient: provider limits and external failures still get discovered reactively, so the first failure of a run is often the one that finds them. The project is solo-maintained.

Choose Bernstein if: You want deterministic scheduling and pre-merge verification without paying for a commercial tool. Skip Bernstein if: You need the resourcing and response times of a funded project.

6. Claude Squad

Repository: smtg-ai/claude-squad | License: AGPL-3.0 | Binary: cs

Claude Squad is the TUI I recommend for solo developers who want parallel agents today. The architecture layers tmux for terminal sessions, git worktrees for filesystem isolation, and a TUI for unified navigation. The cs binary launched six sessions on my laptop in under five seconds, and the keybindings are fast enough that I stopped thinking about them after about twenty minutes.

Isolation: Git worktrees plus tmux. Each agent works in its own branch and physical directory via worktrees, while tmux handles session persistence and navigation.

Agent support: Claude Code (default), Codex (cs -p "codex"), Aider, Gemini, OpenCode, and Amp, each launched via -p or --program.

Coordination: Human-in-the-loop session management. Each agent works independently, and I review all changes before applying or pushing. No agent-to-agent communication, no task dependency graph. The design centers on session lifecycle (create, navigate, delete, stage).

UI: TUI with vim-style navigation. The core actions: n creates a new session and N creates one with a prompt, D kills the selected session, ↑/↓ or j/k navigates, ↵ or o attaches to a session to reprompt, c checks out by committing changes and pausing, s commits and pushes the branch, r resumes a paused session, ctrl-q detaches.

Known limitations: AGPL-3.0 is a real constraint. If you're building internal tooling on top of Claude Squad that might ever become a network service, get legal review first. No native Windows support (tmux dependency). The --autoyes flag for auto-accepting prompts is still experimental, and I wouldn't run it unattended.

Choose Claude Squad if: You're a solo developer or small team working in the terminal and you want parallel agents running now. Skip Claude Squad if: You need Windows support, automated coordination, or a license that permits commercial embedding.

7. Crystal (Now Nimbalyst)

Repository: stravu/crystal (deprecated February 2026) | Successor: nimbalyst.com

Crystal was a Stravu desktop app for running multiple Codex and Claude Code sessions in parallel worktrees. The repository was deprecated in February 2026 when the team redirected users to Nimbalyst, which expands the original's capabilities with interactive visual editing of markdown, mockups, Excalidraw, and code alongside parallel session management. Nimbalyst is open source and local-first, free for individuals, with a paid tier for team collaboration.

I'm including it here because Crystal shows up in older search results and comparisons. Don't start new work on it. The live decision is between Nimbalyst and the other active tools in this list.

Isolation: Git worktrees per agent session.

Agent support: Claude Code from initial release; OpenAI Codex added in v0.3.

Coordination: Human-in-the-loop parallel dispatch. Multiple independent sessions with no automated director/worker hierarchy.

Choose Nimbalyst if: You want the Crystal model plus visual editing. Skip both Crystal and Nimbalyst if: You need the maturity and community of Claude Squad or a maintained Kanban option.

8. Vibe Kanban (Now Community-Maintained)

Repository: BloopAI/vibe-kanban | License: Apache-2.0 | Install: npx vibe-kanban

Status update (read this before adopting). Bloop, the company behind Vibe Kanban, announced a shutdown on April 10, 2026. The project continues as open source and community-maintained, paid subscriptions were refunded, and the Bloop-operated cloud features (kanban issues, comments, projects, organisations) have since been removed. Vibe Kanban now runs on a fully local architecture. Treat it as a community project, not a vendor-backed tool.

With that caveat, here's what made Vibe Kanban worth testing in the first place. The MCP server is the interesting piece: a "planning" ticket can instruct an agent to decompose work and generate downstream cards automatically. That's the closest any tool in this roundup gets to autonomous task decomposition short of going full Bernstein.

Isolation: Git worktrees per workspace, each with its own branch and folder.

Agent support: The README lists 10+ agents including Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, OpenCode, Droid, CCR, and Qwen Code.

Coordination: Kanban board with To Do, In Progress, Review, and Done columns. MCP-driven card creation for task decomposition.

UI: Web app with workspaces panel, built-in browser with devtools and device emulation, inline diff review, and PR creation.

Known limitations: On a repo with twenty active tasks, I ended up with twenty worktree folders, which bloats disk and confuses find. A GitHub Discussion (#2727) captured previously active tension about whether the tool should stay focused on AI orchestration or expand into generic Kanban; that conversation is likely to quiet down after the shutdown, though the underlying question remains for whoever picks up maintenance. Strict pipeline dependencies (task B must wait for task A) aren't clearly supported. On top of that, future maintenance velocity depends entirely on community contributors, not a funded team.

Choose Vibe Kanban if: You want a shared visual board and a built-in browser for previewing UI changes, and you're comfortable depending on a community-maintained project. Skip Vibe Kanban if: You need vendor support, hard task dependencies, or you work on repos where disk usage from many worktrees matters.

9. Agent Kanban

Repository: appsoftwareltd/vscode-agent-kanban | License: Elastic License 2.0

Agent Kanban takes a different approach from every other tool here by living entirely inside VS Code as a Copilot Chat participant, skipping the custom LLM loop entirely. GitHub Copilot's native agent mode does the work, and Agent Kanban provides task structure through markdown-backed Kanban lanes.

The AGENTS.md sentinel mechanism is the clever bit. On activation and every command, the extension writes context into the file, and VS Code re-injects it into the system prompt on every agent turn. @kanban /refresh re-injects context if the agent drifts during a long conversation. I ran a four-hour session without context loss, which I couldn't reliably do with raw Copilot Chat.

A newer version now lives at agentkanban.io, with remote task boards, realtime sync for teams, and optional git worktrees, connected through a companion extension and an API key. The extension covered here stays available and free for local-only workflows, and it's the version I tested.

Isolation: Main workspace by default, with optional git worktree isolation per task.

Agent support: GitHub Copilot only, via VS Code Copilot Chat.

Coordination: The @kanban chat participant routes commands to task files in .agentkanban/:

.agentkanban/
  board.yaml          # Lane definitions, base prompt
  memory.md           # Global memory
  INSTRUCTION.md      # Agent workflow instructions (managed by the extension)
  tasks/
    task_<date>_<id>_<title>.md
    todo_<date>_<id>_<title>.md
    archive/          # Hidden from the board

Known limitations: Copilot-only, so teams on Claude Code or Codex can't use it. The ELv2 license prohibits offering it as a competing hosted service, though internal use is fine. Don't confuse this project with saltbo/agent-kanban, which is a completely separate codebase with a different architecture.

Choose Agent Kanban if: Your team is standardized on GitHub Copilot and lives in VS Code. Skip it if: You use any other agent or want agent choice.

Full Comparison

When OSS Orchestrators Are Enough (and When They Aren't)

Every tool here converges on git worktrees, and most leave coordination to me. That works well inside clear boundaries: one repo, modest agent count, code I understand directly. The question is what happens past those boundaries.

Where OSS orchestrators fit

OSS orchestrators are the right call when:

• The codebase fits in one repository.
• Agent count stays in the 3-6 range I can track visually.
• I'm directly familiar with every service the agents touch.
• I'm comfortable resolving merge conflicts by hand.

Claude Squad gets me from zero to parallel agents fastest. Vibe Kanban still gives me a visual board and a browser preview, with the caveat that the project is now community-maintained after Bloop's shutdown. Bernstein's deterministic scheduler plus the Janitor hits the sweet spot for teams that want pre-merge verification without commercial licensing.

The shared constraint across these tools is that coordination between agents is either manual (most tools) or limited to task-graph scheduling within one repo (Bernstein, Agent Orchestrator). Nothing here coordinates agents across services against shared, persistent context, which is the boundary where agentic OS platforms start to matter.

Where Cosmos changes the shape of the problem

Cosmos is where I go when the coordination problem stops belonging to me and starts belonging to the team. Agents run on managed infrastructure, and the isolation, memory, and audit trail I assemble by hand in the OSS tools arrive with it.

• Environments. Agents execute in isolated sandboxes: Augment's managed cloud, my own machines for code that cannot leave the building, or a pool of both. Isolation stops depending on how many worktrees my SSD can hold.
• Experts. A saved, reusable agent configuration. Improve the prompt once and every future run inherits the improvement, so what an agent gets right survives the session that produced it. No worktree tool in this roundup does that.
• Sessions. Every run is an auditable record of what the agent did, which tools it called, and where a human stepped in.
• Context Engine and shared memory. Codebase understanding sits under all of it, with memory that spans runs, agents, and teams at both tenant and user scope. Correct an agent once and the correction stays available to the next run and the next person.

The Expert is the piece that matters for team work. Say our code review standard changes and every future review should pick it up. In the OSS tools, that means editing prompts in each developer's local config and hoping the other five follow. Here, the change lands on the Expert once, and the next review run uses it.

The platform also starts from events that already exist in the workflow. Native triggers cover GitHub, GitLab, Slack, Linear, Jira, and schedules, with typed webhooks for the rest of the stack, so a run can begin when a PR opens or an alert fires without anyone dispatching it by hand. A run pauses when it reaches a checkpoint and resumes when someone replies, and consequential actions wait for a person to approve them.

Honest tradeoffs. Cosmos is a hosted platform with a paid floor. Business runs $100 per month flat with no per-seat charge, covering up to 50 seats and 50 concurrent sessions, with $100 of usage included and top-ups charged as you go. Enterprise pricing is custom. Every OSS tool in this roundup costs nothing beyond the agent subscriptions you already pay for, and for a solo developer on one repo that difference is the whole argument. Cosmos earns the cost when the coordination problem is organizational, where standing workflows, memory that survives the session, and audit trails matter more than the license fee. It carries SOC 2 Type II and ISO 42001 compliance for teams that have to clear a procurement review.

Decision framework

Pick the Coordination Depth That Matches Your Workflow

Every tool here solves parallel execution. The real decision is how much coordination you want automated and how much you want to keep. Claude Squad keeps it all with you. Agent Orchestrator automates CI recovery. Bernstein automates scheduling and quality gates. Each step trades control for throughput.

That tradeoff works inside one repo, on one machine, for one person. When the same work has to run for a whole team every day, off the triggers the team already uses, the bottleneck stops being merge conflicts and becomes the fact that none of what the agents learn survives the session. Cosmos moves the work off the laptop and onto shared infrastructure, where Experts hold the configuration and memory carries corrections between runs. Every OSS tool here keeps each developer's setup private to that developer.

FAQ

Related

• Google Antigravity vs Augment Cosmos: Multi-Agent Platforms
• Cursor Background Agents vs Cosmos: IDE vs Agentic OS
• GitHub Copilot Agent Mode vs Augment Cosmos: Where Agent Coordination Lives
• OpenAI Codex vs Augment Cosmos: AI Coding Compared
• Claude Managed Agents vs Augment Cosmos: 2026