conductor-oss/conductor

Conductor is an Apache-2.0, self-hosted orchestration engine for microservice flows and AI agents. Instead of expressing orchestration in application code, you define it as a versioned JSON graph of tasks; workers written in ordinary code perform side effects and report back. The engine persists each step, so retries, timeouts, pause/resume, and recovery after a worker or infrastructure failure are handled at the orchestration layer rather than by your framework. It originated at Netflix and is maintained by Orkes and the community (repository overview, docs).

How the workflow looks in practice

A quickstart path uses the CLI: install @conductor-oss/conductor-cli, start the server, then create and start a sample workflow that calls an API and parses the response without any custom workers (quickstart). The server UI is served locally for inspecting definitions and executions. Docker users can run an image exposing the UI and API on separate ports. The project also documents dynamic behavior: forks, sub-workflows, and tasks can be resolved at runtime, and it advises validating generated definitions before starting them (dynamic workflows). That is the part relevant to agent-style loops, alongside built-in LLM and MCP tool tasks and human-approval steps.

AI agent orchestration as a supported path

Conductor treats agents as one kind of workflow rather than a separate product: an example graph discovers MCP tools, loops through an LLM, and conditionally calls a tool, with the loop bounded by an iteration limit and a done flag. The documentation points to a first-agent walkthrough and to a governed adaptive-graph pattern (agent guide, dynamic workflows). Workers can be written in Java, Python, Go, JavaScript, C#, Ruby, or Rust with official SDKs, and the Ruby and Rust SDKs are labeled incubating. If you already have code in a framework, the engine's claim is that orchestration stays a separate, inspectable artifact instead of being compiled into that code.

Requirements and operational conditions

• The 60-second CLI route requires Node.js 16+ and Java 21+ (quickstart).
• Building from source additionally needs Docker Desktop, JDK 21+, Node.js 18+, and pnpm for the UI (build guide).
• Persistence is configurable across Redis, Postgres, MySQL, and Elasticsearch/OpenSearch combinations, each with its own config file; the default is Redis plus ES7 (backend configs). Running executions stay pinned to the workflow definition version they started with, so deploying a new version does not break in-flight runs (README).
• History retention depends on configuration, and the keepLastN option intentionally removes older loop iterations, so replay and audit detail is bounded by those settings (README). The README says upgrades may need a forced fresh server JAR download if an older version is cached (quickstart).

Scope

The documentation describes broad production claims such as scaling servers and workers independently through task domains, concurrency limits, and metrics, but the supplied material contains no benchmark results or independent evaluation, so those are author claims. In short, the engine is a fit where durable, inspectable long-running flows matter, including ones that pause on approval for weeks; it is heavier to operate than a library that runs orchestration inside one process.