Conductor: a durable execution engine for workflows and agents

The problem Conductor addresses: orchestration state that outlives the process

A workflow that spans several services has a state problem. If the coordinating process dies halfway through, you need to know which steps completed, which are in flight, and which never started. Conductor's answer is that every step is persisted, and the README states executions survive crashes, restarts, and network failures with configurable retries and timeouts. The orchestration itself is a versioned, inspectable graph, while workers and built-in tasks do the actual work.

The intended audience is broad but specific in shape. The README lists polyglot workers in Java, Python, Go, JavaScript, C#, Ruby, and Rust, which implies teams that do not want to standardise on one runtime for business logic. The newer material points at a second audience: people building agent loops who want the loop to be a durable graph rather than framework code inside a single process. The README frames this as shipping durable adaptive graphs instead of framework code, which is a claim about where the control flow lives, not about what the agents do.

How the execution model works: a declarative graph plus polling workers

A Conductor workflow is a JSON document with a name, a version, and a list of tasks. Each task has a name, a taskReferenceName, and a type. The type determines who executes it. Worker-backed tasks are picked up by external processes that poll, execute, and report back, which the README describes directly. Built-in tasks are executed by the server itself. The quickstart workflow is described as calling an API and parsing the response with no workers needed, so at least some useful graphs run without any external process at all.

Control flow is expressed as task types rather than code. The README's agent example uses DO_WHILE with a loopCondition string and a loopOver array. Values enter tasks through inputParameters with ${...} references; the discover task, for instance, reads ${workflow.input.mcpServerUrl}.

The server and the workers scale independently. The README mentions task domains, rate limits, concurrency limits, and metrics as the controls, and lists five persistence backends and six message brokers.

LLM and MCP tasks turn the agent loop into graph nodes

The most distinctive part of the current README is the autonomous_agent example. It is a three-part loop: a LIST_MCP_TOOLS task that takes an mcpServer URL and returns available tools, a DO_WHILE whose condition is $.think['done'] != true && $.loop['iteration'] < 10, and inside the loop the steps the README describes as reasoning with an LLM, calling the chosen tool and repeating until done.

The loop condition reads done from the think task's output, so the loop continues until that value is true. The iteration cap of 10 sits in the same condition, which bounds the loop even if done is never set.

The README also mentions human approval and vector workflows for RAG, and describes the overall pattern as plan, validate approved capabilities, bounded fan-out or human approval, evaluate, continue or finish. The word bounded is doing real work there. Dynamic forks and sub-workflows can be resolved at runtime, and the README adds a caution that generated workflow definitions should be validated before starting them. That is an admission that runtime-resolved graphs are harder to reason about statically, and it is the right place to be careful.

Getting a server running: two commands and a cached JAR

The README's stated prerequisites are Node.js v16 or later and Java 21 or later. The quickstart is two commands:

npm install -g @conductor-oss/conductor-cli conductor server start

That starts a server on port 8080 with the ui-next UI. There is also a Docker path: docker run -p 5000:5000 -p 8080:8080 conductoross/conductor:next, with the UI on 5000 and the API on 8080. The port difference between the two paths is worth noticing before you wire anything to a fixed address.

The upgrade note is the most operationally useful paragraph in the README. The CLI caches the server JAR at ~/.conductor-cli/, and a stale cache means you may not be running what you think. Two remedies are given: conductor server start latest, or rm ~/.conductor-cli/conductor-server-latest.jar followed by conductor server start. If you pin versions in other tooling, this cache is a place where that discipline can silently break.

Creating and running a workflow uses the CLI as well. The README fetches a sample definition with curl into workflow.json, then runs conductor workflow create workflow.json, then conductor workflow start -w hello_workflow --sync. The --sync flag makes the start call wait for the result. The README notes that running create twice returns an error the second time because the workflow already exists, and that conductor workflow update is the command for modifying an existing definition. That is a small detail with a real consequence: workflow definitions are versioned artefacts you update, not files you overwrite in place. The README also states that all CLI commands have equivalent cURL or API calls.

Where Conductor is the wrong choice

The engine assumes you are willing to run a server. That is the first boundary. A single service that needs to retry an HTTP call does not need a workflow graph, a persistence backend, and a message broker; a retry library inside the process is smaller and has no operational surface. Conductor earns its cost when the coordination spans processes or outlives a single deploy.

The second boundary is that the graph is a separate artefact from the code. Workers are plain code in any language, but the control flow lives in JSON that you create and update through the CLI or API. Teams that want orchestration expressed as ordinary functions in one language will find the split between definition and worker unfamiliar, and the README's own note about validating generated definitions suggests the split gets sharper when definitions are produced at runtime.

The third boundary is the infrastructure. The README lists five persistence backends and six message brokers, and choosing among them is a decision that affects backup, migration, and failure behaviour. Anyone evaluating Conductor should treat backend selection as an open question, not a solved one.

Conductor against Temporal and Airflow

Temporal is the closest comparison, and the difference is where the workflow lives. In Temporal, the workflow is code you write in a supported language and the SDK replays it to reconstruct state. In Conductor, the workflow is a declarative JSON graph that the server interprets, and the code lives in workers that poll for tasks. Conductor's approach means the graph is inspectable and editable without redeploying a worker, and it means the graph is a document you can generate and validate. Temporal's approach means control flow uses the language's own constructs rather than a fixed set of task types and expression strings.

Airflow is a different comparison because it is a scheduler. Airflow runs a DAG on a timetable and is built around batch pipelines and backfills. Conductor is triggered per execution and holds the state of that execution until it finishes, with pause, resume, restart, rerun, retry, and terminate as operations on a live execution. If your problem is nightly data processing, Airflow's model is the natural one. If your problem is a long-running request that crosses services and needs to be resumed after a crash, Conductor's model is the natural one.

The AI angle is where Conductor currently differentiates. Native LLM tasks, LIST_MCP_TOOLS, and DO_WHILE as a first-class loop type mean an agent loop can be expressed in the same graph as its surrounding business steps. Frameworks that keep the loop in application code do not give you the same pause and resume semantics for free.

Versioning, maintenance, and the licence

The repository shows a steady release cadence, with v3.33.0 on 2026-10-26 and v3.34.0-rc1 on 2026-10-30, and the last push on 2026-10-31. The project is not archived and the README states it is actively maintained by Orkes and the community, with a Slack channel linked for support. The release line includes release candidates alongside patch releases, so a deployment policy that only tracks stable tags will sometimes sit a version behind.

Upgrade cost concentrates in two places. The CLI cache at ~/.conductor-cli/ is one, covered above. Workflow versioning is the other: definitions carry a version field, and the README's example sets it to 1. Since create fails on an existing name and update is the modification path, changes to a running workflow's shape are a deliberate operation rather than a file drop. What happens to in-flight executions when a definition changes is something to establish against your own persistence backend before you rely on it.

The licence is Apache-2.0, which permits commercial use and modification. The README's own framing is self-hosted, no lock-in. That is a statement about the licence and the deployment model, not a guarantee about any hosted offering built on top of it. For the specific obligations Apache-2.0 places on redistribution, read the licence text or ask counsel; this article does not give legal advice.

Editorial conclusion

Conductor fits teams that need a versioned, inspectable graph coordinating polyglot workers, including LLM and MCP steps. It does not fit a single-service project that only needs a retry wrapper, or a batch pipeline where Airflow's scheduler model is the natural fit. Before adopting, verify two things in your own environment: which persistence backend you will run, since the README lists five, and whether the CLI's cached JAR at ~/.conductor-cli/ matches the server version you intend to deploy.

Frequently asked questions

Official sources

1. conductor-oss/conductor on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases