Skip to main content
Agent Orchestrator supports managing multiple projects simultaneously, each with its own configuration, tracker, and agent settings.

Basic Multi-Project Configuration

Define multiple projects in agent-orchestrator.yaml:
Each project gets:
  • Independent session namespace (fe-1, api-1, mob-1)
  • Separate git worktrees
  • Individual session metadata directories
  • Project-specific configuration overrides

Session Prefixes

Session prefixes help you identify which project a session belongs to:
Without prefixes:
With prefixes:
This makes it easy to:
  • Filter sessions by project: ao session ls -p frontend
  • Open all project sessions: ao open frontend
  • Identify sessions at a glance: ao status
Prefixes default to the project ID if not specified. Set explicit prefixes for better readability.

Project-Specific Overrides

Override default settings per project:
Use different AI agents per project:

Different Trackers per Project

Use GitHub Issues for one project and Linear for another:
Spawning with different trackers:

Supported Trackers

Project-Specific Agent Rules

Define coding standards per project:
External rules file (mobile/.agent-rules.md):

Project-Specific Reactions

Configure different automation levels per project:

Managing Multiple Dashboards

Run separate orchestrator instances for different project groups:

Single Dashboard (All Projects)

agent-orchestrator.yaml:
Start:
Dashboard shows all projects at http://localhost:3000

Multiple Dashboards (Separate Teams)

team-frontend.yaml:
team-backend.yaml:
Start separate instances:
Dashboards:
  • Frontend: http://localhost:3000
  • Backend: http://localhost:3001
Each orchestrator instance needs:
  • Different port (e.g., 3000, 3001, 3002)
  • Different dataDir (separate metadata)
  • Separate config file
Conflicts occur if multiple instances share the same port or data directory.

Spawning Across Projects

Spawn for Specific Project

Batch Spawn Across Projects

View Status Across All Projects

Output:

Filter by Project

Opening Sessions by Project

Open all sessions for a project in terminal tabs:

Example: Full Multi-Project Config

examples/multi-project.yaml:

Workspace Isolation

Each project’s worktrees are isolated:
Worktrees:
  • Share the .git directory with the main repo
  • Have independent working directories
  • Can be on different branches simultaneously
  • Are cleaned up when sessions are killed

Metadata Organization

Session metadata is organized by project:

Best Practices

1

Use descriptive prefixes

Choose short, recognizable prefixes:
  • ✅ fe, api, mob
  • ❌ project1, p1, x
2

Group related projects

Keep frontend/backend/mobile in one config if they’re part of the same product.
3

Separate critical from experimental

Use different reaction configs:
  • Critical: Manual merge, conservative retries
  • Experimental: Auto-merge, aggressive retries
4

Shared notification channels

Route all projects to the same Slack channel for unified monitoring.
5

Consistent agent rules

Establish org-wide standards and include them in all projects.

Troubleshooting

Port Conflicts

Error: EADDRINUSE: address already in use ::1:3000 Solution: Use different ports for multiple instances:

Session Prefix Collisions

Problem: Two projects with same prefix create conflicting session names. Solution: Use unique prefixes:

Worktree Path Conflicts

Problem: Multiple projects try to use the same worktree directory. Solution: Ensure worktreeDir is shared but session names are unique (via prefixes).

Next Steps

Custom Workflows

Create advanced automation with CI/CD integration

Auto-Reactions

Configure automated responses per project