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, plus SWITCH with an evaluatorType of value-param and an expression. Values pass between tasks through inputParameters with ${...} references, so the think task reads ${discover.output.tools} and the loop body reads ${loop.output.results}. That is the data flow in one sentence: outputs of earlier tasks are addressable by reference in later task inputs, and the server holds the state between them.

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 without naming them. Those two numbers are the main thing the README leaves you to look up elsewhere.

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 an LLM_CHAT_COMPLETE task followed by a SWITCH that routes on the model's chosen action.

The LLM_CHAT_COMPLETE task carries llmProvider, model, a messages array with role and message fields, and a jsonOutput flag. The system message in the example instructs the model to respond with JSON in one of two shapes: a tool call with action and arguments, or a final answer with done set to true. The loop condition reads done from the think task's output, so the model's own JSON decides whether the loop continues. The iteration cap of 10 sits in the same condition, which bounds the loop even if the model never sets done.

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 unstated infrastructure. Five persistence backends and six message brokers are listed as counts, not names. Choosing among them is a decision the README does not make for you, and it 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. LLM_CHAT_COMPLETE, 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-rc2 and v3.32.3 both dated September 2026, and the last push matching the newest release. 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. The README does not describe a migration procedure for in-flight executions when a definition changes, so that 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 already run Java infrastructure and 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 claims five but names none, and whether the CLI's cached JAR at ~/.conductor-cli/ matches the server version you intend to deploy.

Official sources

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