Integrations
Conductor connects markdown intake, repo state, runtime sessions, editor jump points, and review signals. These are the actual operating surfaces, not a generic marketplace grid.
Open the linked docs for setup details, but use this page to understand how Conductor actually plugs into a working engineering loop.
Code review + CI
Open PRs, monitor CI, sync review state, and dispatch work against repo-aware project config.
Tooling bridge
Use Conductor from Cursor, Claude Desktop, or any MCP-compatible tool via the built-in MCP server.
Parallel sessions
Run each task in an isolated terminal session so parallel work remains inspectable and recoverable.
Worktree jump
Jump from the browser into VS Code, Cursor, and remote worktrees without losing repo context.
Secure browser access
Expose the browser UI with a tunnel or reverse proxy while keeping the orchestrator local.
Lifecycle signals
Use desktop or Discord notifiers to surface agent lifecycle updates without camping in the browser.
HTTP automation
Trigger tasks and state transitions from external systems without introducing a hosted orchestration layer.
Repo-native source
Route markdown board work from CONDUCTOR.md through dispatch, review, and merge without leaving the repo.
Conductor can expose itself as an MCP server and also mount per-project MCP servers from conductor.yaml.
projects:
my-app:
mcpServers:
postgres:
command: npx
args: ["-y", "@modelcontextprotocol/server-postgres"]The useful question is not whether Conductor has a long integration checklist. It is whether the repo, board, runtime, and review surfaces stay connected when real work moves through the system.
The core surfaces are GitHub for PR and CI state, tmux for isolated execution, MCP for tool access, editor handoff for opening the right worktree fast, and webhooks or notifications when work needs to escape the browser.