* feat(core): add scm webhook contract Defines a provider-agnostic SCM webhook contract in core types and config so SCM plugins can verify and normalize inbound webhook events without reshaping project config later. * feat(scm): trigger lifecycle checks from github webhooks Adds GitHub webhook verification and event parsing, exposes a web webhook endpoint, and routes matching PR/branch events through the existing lifecycle manager so CI and review reactions update immediately. * fix(scm): verify github signatures with raw webhook bytes Preserves the original webhook bytes alongside the decoded payload so GitHub HMAC verification uses the exact request body while the route continues to drive lifecycle checks through the existing manager. * fix(web): wire scm webhook route into main branch services Restores the main-branch service and route-test wiring while keeping the new webhook route coverage and scoped lifecycle helper in place. * fix(webhooks): use singleton lifecycle manager and fail closed on scm API errors Reuses the existing services lifecycle manager for webhook-triggered checks so reactions and state transitions don't replay from a fresh instance, and restores fail-closed behavior for GitHub review comment fetch failures. * fix(webhooks): tighten project matching and restore scm compatibility methods Prevents repository-less webhook events from matching all projects, restores GitHub SCM PR utility methods and CI status rollup fallback, and adds tests covering the compatibility paths and safer project matching behavior. * fix(webhooks): pre-check content length and continue on parse errors Adds an early content-length guard against configured maxBodyBytes before reading the body and changes candidate parse failures to fail-forward so one malformed payload path does not abort other valid candidate handling. * fix(scm-github): parse review-comment timestamps from comment payload Use comment.updated_at/created_at for pull_request_review_comment webhook timestamps so normalized events retain temporal data for comment events. * fix(webhooks): apply early size guard only when all candidates are bounded Uses the broadest candidate limit for pre-read content-length checks and skips early rejection when any matching project has no configured limit, while retaining per-candidate verification limits. * fix(webhooks): normalize repo matching and skip terminal sessions Match webhook repository names case-insensitively against configured project repos and avoid lifecycle checks for terminal sessions when resolving webhook-affected sessions. * fix(webhooks): fail forward when lifecycle checks throw * fix(scm-github): parse push webhook branch and sha * refactor(scm-github): dedupe cli exec helper wrappers * fix(scm-github): tighten exec helper type and comment timestamps * fix(scm-github): prefer head_commit timestamp for push events * fix(webhooks): tighten repository parsing and helper visibility * fix(scm-github): ignore non-head refs for push branch * chore: trigger bugbot rerun * feat(scm-gitlab): add webhook verification and event parsing * fix(webhooks): share parser utils and handle check_run branch * fix(webhooks): ignore gitlab tag refs in ci branch mapping * fix(scm-gitlab): harden token and tag ref handling * chore(scm-gitlab): update webhook helpers around bugbot threads |
||
|---|---|---|
| .changeset | ||
| .cursor | ||
| .github/workflows | ||
| .husky | ||
| artifacts | ||
| changelog | ||
| docs | ||
| examples | ||
| packages | ||
| scripts | ||
| tests/integration | ||
| .gitignore | ||
| .gitignore-template | ||
| .gitleaks.toml | ||
| .npmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| ARCHITECTURE.md | ||
| DASHBOARD_FIXES_SUMMARY.md | ||
| DESIGN-OPENCLAW-PLUGIN.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
Option A — From a repo URL (fastest):
# Install
git clone https://github.com/ComposioHQ/agent-orchestrator.git
cd agent-orchestrator && bash scripts/setup.sh
# One command to clone, configure, and launch
ao start https://github.com/your-org/your-repo
Auto-detects language, package manager, SCM platform, and default branch. Generates agent-orchestrator.yaml and starts the dashboard + orchestrator.
Option B — From an existing local repo:
cd ~/your-project && ao init --auto
ao start
Then spawn agents:
ao spawn my-project 123 # GitHub issue, Linear ticket, or ad-hoc
Dashboard opens at http://localhost:3000. Run ao status for the CLI view.
How It Works
ao spawn my-project 123
- Workspace creates an isolated git worktree with a feature branch
- Runtime starts a tmux session (or Docker container)
- Agent launches Claude Code (or Codex, or Aider) with issue context
- Agent works autonomously — reads code, writes tests, creates PR
- Reactions auto-handle CI failures and review comments
- Notifier pings you only when judgment is needed
Plugin Architecture
Eight slots. Every abstraction is swappable.
| Slot | Default | Alternatives |
|---|---|---|
| Runtime | tmux | docker, k8s, process |
| Agent | claude-code | codex, aider, opencode |
| Workspace | worktree | clone |
| Tracker | github | linear |
| SCM | github | — |
| Notifier | desktop | slack, composio, webhook |
| Terminal | iterm2 | web |
| Lifecycle | core | — |
All interfaces defined in packages/core/src/types.ts. A plugin implements one interface and exports a PluginModule. That's it.
Configuration
# agent-orchestrator.yaml
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.
CLI
ao status # Overview of all sessions
ao spawn <project> [issue] # Spawn an agent
ao send <session> "Fix the tests" # Send instructions
ao session ls # List sessions
ao session kill <session> # Kill a session
ao session restore <session> # Revive a crashed agent
ao dashboard # Open web dashboard
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 spawn and walk away. The system handles isolation, feedback routing, and status tracking. You review PRs and make decisions — the rest is automated.
Prerequisites
- Node.js 20+
- Git 2.25+
- tmux (for default runtime)
ghCLI (for GitHub integration)
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 CLAUDE.md for code conventions and architecture details.
Documentation
| Doc | What it covers |
|---|---|
| Setup Guide | Detailed installation and configuration |
| Examples | Config templates (GitHub, Linear, multi-project, auto-merge) |
| CLAUDE.md | Architecture, conventions, plugin pattern |
| Troubleshooting | Common issues and fixes |
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 CLAUDE.md for the pattern.
License
MIT