* fix(lifecycle): implement stuck detection using agent-stuck threshold The agent-stuck reaction config supported a threshold field (e.g. "10m"), but determineStatus() never returned "stuck" — there was no code path that consumed the threshold or transitioned sessions based on idle time. Sessions would stay parked at pr_open/working forever even when the agent had been idle for hours. Added idle-time check in determineStatus(): when getActivityState() reports "idle" or "blocked" with a timestamp, compare the idle duration against the agent-stuck.threshold config. If exceeded, return "stuck" so the reaction system can fire notifications. Also removed the priority !== "info" guard on transition notifications, so all priority levels (including info) are routed through notificationRouting. This lets the config control which notifiers receive each priority level, rather than silently dropping info-level transition events. * fix(lifecycle): add post-PR stuck detection as safety net The original stuck check in step 2 (before PR checks) can be bypassed when getActivityState() returns null (session file not found, cache miss, I/O failure). When this happens, the code falls through to the PR path which returns 'pr_open' without ever checking idle duration. Fix: extract isIdleBeyondThreshold() helper and call it in three places: 1. Step 2: before PR checks (fast path, catches most cases) 2. Step 4b: after PR checks return 'pr_open' (safety net) 3. Step 5: after all checks, for agents that finish without a PR This ensures stuck detection fires even when the JSONL activity detection fails to return idle state. Sessions can no longer get permanently stuck at 'pr_open' when the agent has been idle beyond the threshold. Also removes the debug console.error calls from the previous commit. * fix(lifecycle): treat reviewDecision 'none' as approved for merge readiness PRs with no required reviewers never reached 'mergeable' status because getReviewDecision returned 'none', which was not handled. The lifecycle poll fell through to 'review_pending' or the default, so merge.ready never fired and the approved-and-green reaction never triggered. Also: skip stuck short-circuit when session has an open PR so merge readiness checks in step 4 can still run. Without this, idle agents with open PRs get stuck status and never transition to mergeable. Closes composio#0 (internal fix) * fix(opencode): classify activity state from session timestamps * test(lifecycle): cover opencode idle-threshold stuck transition * fix(lifecycle): preserve global stuck threshold with project overrides * fix(lifecycle): run PR auto-detection before stuck transitions --------- Co-authored-by: Harsh <harshb012@gmail.com> |
||
|---|---|---|
| .changeset | ||
| .cursor | ||
| .github/workflows | ||
| .husky | ||
| artifacts | ||
| changelog | ||
| docs | ||
| examples | ||
| packages | ||
| scripts | ||
| tests/integration | ||
| .gitignore | ||
| .gitignore-template | ||
| .gitleaks.toml | ||
| .npmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| ARCHITECTURE.md | ||
| CONTRIBUTING.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
ao doctor [--fix] # Check install, runtime, and stale temp issues
ao update # Update local AO install and run smoke tests
Maintenance
# Run deterministic install and runtime checks
ao doctor
# Apply safe cleanup and launcher fixes
ao doctor --fix
# Update this local AO checkout, rebuild critical packages, and verify the launcher
ao update
ao doctor checks PATH and launcher resolution, required binaries, tmux and GitHub CLI health, config support directories, stale AO temp files, and core build/runtime sanity. ao update fast-forwards the local install repo on main, runs pnpm install, clean-rebuilds @composio/ao-core, @composio/ao-cli, and @composio/ao-web, refreshes the global ao launcher with npm link, and finishes with CLI smoke tests.
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 docs/DEVELOPMENT.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) |
| Development Guide | Architecture, conventions, plugin pattern |
| Contributing | How to contribute, build plugins, PR process |
| 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 CONTRIBUTING.md and the Development Guide for the pattern.
License
MIT