Original, local-first, open source
Conductor keeps the task plane in markdown, the runtime close to the repository, and the review loop visible in one control surface instead of scattering it across ad hoc scripts.
Markdown task planeBrowser-first setup10 built-in agent pluginsMCP + webhooks + git worktrees
built-in coding agents with native plugin routing
repo-local control plane driven by markdown and config files
required hosted database layers or cloud-only runtime dependencies

CONDUCTOR.mdas the task surface- repo-local
conductor.yamlfor project config - isolated git worktrees and tmux sessions for execution
- a browser dashboard, CLI, MCP server, and webhook endpoints for control
Workspaces
Set up repositories, sessions, chat surfaces, changes, and review workflows around a real operational unit.
Agents
Pick the right coding agent per repository and standardize installation, aliases, authentication, and defaults.
Settings
Keep routing, MCP bindings, repository metadata, and task conventions explicit instead of hidden in UI state.
Integrations
Connect Conductor to GitHub, MCP clients, editor workflows, notifications, and webhook-driven automation.
Launch in three steps
Launch the local control plane
Add the first workspace
Point Conductor at the real repository root, select the default agent, and let it write the repo-local files it needs.
What the docs cover
Planning stays in the repo
Conductor is not another hosted ticket layer. The board is markdown and the source of truth remains near the code.
Runtime state is visible
Sessions, prompts, worktrees, and review state are part of the product surface, not invisible background machinery.
Review is first-class
Diff inspection, CI state, and handoff back to the agent are documented as part of the core workflow.
Self-hosting is real
Local development, Docker deployment, and remote access are all documented as operational concerns, not hidden setup notes.



