* fix: reduce dashboard JS bundle from 1.7MB to 170KB (gzipped) (#792) Switch `ao start` default from `next dev` (7.6MB uncompressed) to optimized production builds (128KB per route). Add `--dev` flag for HMR when editing dashboard UI. Add bundle analyzer, server-only guards, and lazy-load DirectTerminal via next/dynamic. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: skip dashboard rebuild when assets exist, fix CI timeout Skip the production build step when .next/BUILD_ID and dist-server/ already exist (e.g. after pnpm build in CI). Add c8 ignore for untestable process-spawning startup code to fix diff coverage. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor: adopt PR #903 patterns — centralize rebuild logic and add preflight web artifact checks Extract rebuildDashboardProductionArtifacts into dashboard-rebuild.ts, add isInstalledUnderNodeModules/assertDashboardRebuildSupported guards, remove findProcessWebDir, and verify .next/BUILD_ID + dist-server/start-all.js in preflight. Dashboard command now always uses production server. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: skip production preflight in --dev mode, add coverage for rebuild helpers - Skip preflight.checkBuilt() when --dev is passed (dev mode uses HMR, doesn't need .next/BUILD_ID or dist-server/start-all.js) - Add c8 ignore to dashboard.ts process-spawning code (matches start.ts pattern) - Add tests for rebuildDashboardProductionArtifacts (success, failure, npm guard) - Add preflight tests for npm-install web artifact hint paths Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: align preflight skip with actual dev-server condition Only skip production artifact preflight when both --dev is passed AND we're in the monorepo (where dev mode actually works). For npm global installs, --dev is silently ignored and production server runs, so preflight must still validate .next/BUILD_ID and dist-server/start-all.js. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: match @next/bundle-analyzer version to next@^15.1.0 The @next/* packages follow the Next.js release train. Pin the bundle analyzer to ^15.1.0 to match the project's next dependency. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: correct recovery command for npm installs and remove redundant guard - Change stale-build recovery suggestion from "ao update" (which only works in source checkouts) to "npm install -g @composio/ao@latest" for npm global installs - Remove redundant assertDashboardRebuildSupported call in dashboard.ts since rebuildDashboardProductionArtifacts already calls it internally Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .changeset | ||
| .cursor | ||
| .github/workflows | ||
| .husky | ||
| artifacts | ||
| changelog | ||
| docs | ||
| examples | ||
| openclaw-plugin | ||
| packages | ||
| scripts | ||
| skills/agent-orchestrator | ||
| tests/integration | ||
| .eslintignore | ||
| .gitignore | ||
| .gitignore-template | ||
| .gitleaks.toml | ||
| .npmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| AGENTS.md | ||
| ARCHITECTURE.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| DASHBOARD_FIXES_SUMMARY.md | ||
| DESIGN-OPENCLAW-PLUGIN.md | ||
| DESIGN.md | ||
| LICENSE | ||
| README.md | ||
| SECURITY.md | ||
| SETUP.md | ||
| TROUBLESHOOTING.md | ||
| agent-orchestrator.yaml.example | ||
| eslint.config.js | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| test-ao-config.yaml | ||
| test-ao-config2.yaml | ||
| tsconfig.base.json | ||
README.md
Agent Orchestrator — The Orchestration Layer for Parallel AI Agents
Spawn parallel AI coding agents, each in its own git worktree. Agents autonomously fix CI failures, address review comments, and open PRs — you supervise from one dashboard.
Agent Orchestrator manages fleets of AI coding agents working in parallel on your codebase. Each agent gets its own git worktree, its own branch, and its own PR. When CI fails, the agent fixes it. When reviewers leave comments, the agent addresses them. You only get pulled in when human judgment is needed.
Agent-agnostic (Claude Code, Codex, Aider) · Runtime-agnostic (tmux, Docker) · Tracker-agnostic (GitHub, Linear)
Quick Start
Prerequisites: Node.js 20+, Git 2.25+, tmux,
ghCLI. Install tmux viabrew install tmux(macOS) orsudo apt install tmux(Linux).
Install
npm install -g @composio/ao
Permission denied? Install from source?
If npm install -g fails with EACCES, prefix with sudo or fix your npm permissions.
To install from source (for contributors):
git clone https://github.com/ComposioHQ/agent-orchestrator.git
cd agent-orchestrator && bash scripts/setup.sh
Start
Point it at any repo — it clones, configures, and launches the dashboard in one command:
ao start https://github.com/your-org/your-repo
Or from inside an existing local repo:
cd ~/your-project && ao start
That's it. The dashboard opens at http://localhost:3000 and the orchestrator agent starts managing your project.
Add more projects
ao start ~/path/to/another-repo
How It Works
- You start —
ao startlaunches the dashboard and an orchestrator agent - Orchestrator spawns workers — each issue gets its own agent in an isolated git worktree
- Agents work autonomously — they read code, write tests, create PRs
- Reactions handle feedback — CI failures and review comments are automatically routed back to the agent
- You review and merge — you only get pulled in when human judgment is needed
The orchestrator agent uses the AO CLI internally to manage sessions. You don't need to learn or use the CLI — the dashboard and orchestrator handle everything.
Configuration
ao start auto-generates agent-orchestrator.yaml with sensible defaults. You can edit it afterwards to customize behavior:
# agent-orchestrator.yaml
# Runtime data is auto-derived under ~/.agent-orchestrator/{hash}-{projectId}/
port: 3000
defaults:
runtime: tmux
agent: claude-code
workspace: worktree
notifiers: [desktop]
projects:
my-app:
repo: owner/my-app
path: ~/my-app
defaultBranch: main
sessionPrefix: app
reactions:
ci-failed:
auto: true
action: send-to-agent
retries: 2
changes-requested:
auto: true
action: send-to-agent
escalateAfter: 30m
approved-and-green:
auto: false # flip to true for auto-merge
action: notify
CI fails → agent gets the logs and fixes it. Reviewer requests changes → agent addresses them. PR approved with green CI → you get a notification to merge.
See agent-orchestrator.yaml.example for the full reference, or run ao config-help for the complete schema.
Plugin Architecture
Seven plugin slots. Lifecycle stays in core.
| Slot | Default | Alternatives |
|---|---|---|
| Runtime | tmux | process |
| Agent | claude-code | codex, aider, opencode |
| Workspace | worktree | clone |
| Tracker | github | linear, gitlab |
| SCM | github | gitlab |
| Notifier | desktop | slack, discord, composio, webhook, openclaw |
| Terminal | iterm2 | web |
All interfaces defined in packages/core/src/types.ts. A plugin implements one interface and exports a PluginModule. That's it.
Why Agent Orchestrator?
Running one AI agent in a terminal is easy. Running 30 across different issues, branches, and PRs is a coordination problem.
Without orchestration, you manually: create branches, start agents, check if they're stuck, read CI failures, forward review comments, track which PRs are ready to merge, clean up when done.
With Agent Orchestrator, you: ao start and walk away. The system handles isolation, feedback routing, and status tracking. You review PRs and make decisions — the rest is automated.
Documentation
| Doc | What it covers |
|---|---|
| Setup Guide | Detailed installation, configuration, and troubleshooting |
| CLI Reference | All ao commands (mostly used by the orchestrator agent) |
| Examples | Config templates (GitHub, Linear, multi-project, auto-merge) |
| Development Guide | Architecture, conventions, plugin pattern |
| Contributing | How to contribute, build plugins, PR process |
Development
pnpm install && pnpm build # Install and build all packages
pnpm test # Run tests (3,288 test cases)
pnpm dev # Start web dashboard dev server
See docs/DEVELOPMENT.md for code conventions and architecture details.
Contributing
Contributions welcome. The plugin system makes it straightforward to add support for new agents, runtimes, trackers, and notification channels. Every plugin is an implementation of a TypeScript interface — see CONTRIBUTING.md and the Development Guide for the pattern.
License
MIT