Conductor Workflow Engine
Durably orchestrate microservices, AI agents, and long-running workflows across failures.
The evidence shows scoped read/check permissions in several CI jobs, use of GitHub Secrets, a vulnerability-reporting channel, inspectable workflow inputs and outputs, and thorough retry, rerun, and task-level recovery facilities. Deductions apply because workers are explicitly allowed arbitrary code and I/O and workflows can invoke MCP tools or be generated at runtime, while no uniform least-privilege sandbox, external-effect confirmation policy, or sensitive-field redaction rules are shown. Human approval is asserted as a capability, but the autonomous example calls tools directly. Dependency controls include Gradle-wrapper validation, a frozen pnpm lockfile, and a supported-version policy; however, requirements.txt is unpinned, Actions use movable version tags, and installation instructions pipe a remote script to a shell. Netflix, Conductor OSS, and Orkes are attributed, but chiefly through project-authored statements, and publisher identity remains unknown.
The README, CI configuration, and durability demo are broadly consistent about persistence, restart recovery, task states, and multiple backends. CI defines unit, harness, scheduled full-validation, and multi-backend E2E paths. Deductions apply because none were executed for this review, the ordinary build explicitly excludes tests, PR persistence coverage is conditionally skipped, and some backends are disabled or described as partial. External LLM, MCP, database, and broker services remain availability dependencies. Scripts and CI provide useful messages for health timeouts, unknown profiles, failed tasks, and log locations, but the supplied evidence does not establish a consistent structured error model across the product.
The material clearly addresses microservices, AI agents, long-running workflows, human waits, dynamic branching, and polyglot workers, with numerous databases, brokers, JVM, Docker, and local UI configurations. This thoroughly supports audience coverage and environment fit. Capability boundaries lose points because limitations, unsupported combinations, resource ceilings, and security boundaries receive much less detail than supported features. Triggers and routing are expressed precisely through explicit JSON task graphs, conditions, and parameters, but the autonomous example relies on an LLM returning conforming JSON without showing schema-failure handling, unknown-tool controls, or an iteration ceiling.
The README is well organized around quick start, source builds, SDKs, backend configuration, FAQ, contribution routes, security policy, roadmap, and licensing. Prerequisites and the duplicate-workflow error are documented. The complete Apache-2.0 text agrees with the metadata, justifying full license credit. Deductions apply because naming spans conductor-oss and io-orkes identifiers and both ui and ui-next; known limitations are only scattered across incubating SDKs, partial Cassandra support, and the supported-version table. A release badge, workflow-definition versioning, and roadmap indicate update paths, but no actual changelog is included. Orkes is named as primary maintainer with issue, community, and security channels, although that responsibility is not independently verified.
Declarative JSON, a visual UI, API and CLI access, task-level inspection, and recovery operations make outputs generally usable. Durable execution, polyglot workers, dynamic composition, and multiple persistence choices provide substantial marginal value over a simple in-process agent loop. Deductions apply because the static evidence does not quantify deployment resources, operational complexity, LLM expense, or realized large-scale benefits, while even the quick-start ecosystem can require Java, Node, containers, or external services. Demonstration outputs are useful for operation and debugging, but production output schemas, quality constraints, and downstream-consumer contracts are not comprehensively shown.
Some claims trace to concrete files: CI specifies test matrices, the durability demo explicitly persists state, kills the server, restarts it, and checks completion, while LICENSE and SECURITY support licensing and maintenance-policy claims. Deductions apply because internet scale, billions of executions, named-enterprise adoption, 14+ providers, complete compatibility, and broad determinism guarantees are largely repeated README assertions without independent or lower-level corroboration in the supplied material. Facts, architectural inference, and comparative marketing are frequently blended, including generalizing demonstration behavior into broad guarantees, so fact-versus-inference separation is weak.
- Autonomous workflows can invoke arbitrary MCP tools or worker I/O. Add tool allowlists, network-egress controls, identity separation, argument validation, and human confirmation for high-impact actions before deployment.
- Do not run the documented remote curl-to-shell installer in a high-trust environment without pinning a version, downloading and reviewing it, and verifying integrity.
- Review the debug-docker-credentials workflow: it prints Docker Hub account information and failed login responses, potentially exposing unnecessary identity or response data in CI logs.
- Internet-scale operation, named-enterprise adoption, complete compatibility, and 14+ provider claims are not independently verified by the supplied material; this assessment also did not execute builds, tests, or the durability demo.
- Before production use, establish encryption, log redaction, retention, tenant isolation, and deletion policies for secrets and persisted workflow inputs and outputs; these controls are not adequately documented here.
What does this agent do, and when should you use it?
Conductor is an open-source durable workflow engine created at Netflix and now maintained by Orkes and its community. It represents orchestration as declarative JSON graphs while business logic runs in workers written in Java, Python, Go, JavaScript, C#, Ruby, or Rust. The engine persists every step and supports retries, timeouts, reruns from a selected task, and retries of only the failed step, allowing executions to survive crashes, restarts, and network failures. Its AI-oriented task set covers more than 14 LLM providers, MCP tool discovery and invocation, function calling, human approval, and vector-database integration for RAG. Teams can operate workflows through the CLI, HTTP API, built-in UI, or language SDKs and self-host the server on a JVM or in Docker. It is a strong fit when recoverability, observability, and runtime composition matter, provided the team is willing to operate the service and keep declarative orchestration separate from worker code.
A user defines a workflow and its tasks in JSON, registers it with conductor workflow create workflow.json, and starts an execution with conductor workflow start -w hello_workflow --sync. Conductor reads workflow inputs, resolves the task graph, and schedules built-in tasks or external workers; workers poll for tasks, execute ordinary application code, and report results. Graphs can use SWITCH for branching, DO_WHILE for loops, FORK_JOIN for dynamic fan-out, SUB_WORKFLOW for composition, and DYNAMIC tasks resolved at runtime. An agent workflow can discover tools with LIST_MCP_TOOLS, reason through LLM_CHAT_COMPLETE, and invoke the selected operation through CALL_MCP_TOOL. The engine records each step's input, output, state, timing, and retry history, producing a durable workflow execution record and task outputs that operators can inspect, restart, rerun, or retry through the API or UI.
- A platform team coordinating several microservices needs workflows to recover automatically after service restarts or intermittent network failures.
- An AI engineering team is building an autonomous loop that combines LLM reasoning, MCP tool discovery and calls, repeated execution, and human approval.
- An application team runs orders, approvals, or other processes that may wait days or months for an external signal, timer, or reviewer.
- An operations or data team needs dynamic parallel fan-out whose task count is decided at runtime, with the option to retry only failed work.
- An enterprise with mixed-language services wants Java, Python, Go, JavaScript, C#, Ruby, or Rust workers to participate in one orchestration graph.
- An organization avoiding a hosted-engine dependency wants an Apache-licensed workflow service deployable on Docker or a JVM with multiple persistence and messaging choices.
What are this agent's strengths and limitations?
- Every step is persisted, with configurable retries and timeouts plus whole-workflow restart, task-level rerun, and failed-step retry.
- Declarative orchestration is separated from business code, making the graph deterministic while allowing workers to use arbitrary languages, libraries, I/O, and APIs.
- Native AI workflow features cover more than 14 LLM providers, MCP calls, function calling, human approval, and vector databases for RAG.
- Dynamic branches, loops, parallel fan-out, sub-workflows, and runtime-resolved tasks are available without sacrificing execution history.
- The Apache 2.0 self-hosted engine documents five persistence backends, six message brokers, and deployment wherever Docker or a JVM runs.
- Seven worker-language paths are listed, with concrete package installation commands for Java, Python, JavaScript, Go, and C#.
- The quick-start path requires both Node.js 16+ and Java 21+; source builds additionally require Docker Desktop, Node.js 18+, and pnpm.
- The declarative JSON model requires teams to maintain workflow definitions separately and integrate business logic through workers.
- A production adopter must operate the Conductor servers and choose and maintain persistence and messaging infrastructure.
- The Ruby and Rust SDKs are explicitly marked incubating, so their maturity should not be assumed to match the other listed SDKs.
- LLM, MCP, vector-database, and external-API workflows still depend on provider connectivity, configuration, and credentials; no single credential setup is documented here.
- The material claims horizontal scaling to billions of workflow executions but provides no reproducible benchmark or concrete capacity-planning procedure.
How do you install or deploy this agent?
The fastest local setup requires Node.js 16+ and Java 21+:
npm install -g @conductor-oss/conductor-cli
conductor server startOpen http://localhost:8080 for the built-in ui-next interface. A Docker deployment is also documented, exposing the UI on port 5000 and the API on port 8080:
docker run -p 5000:5000 -p 8080:8080 conductoross/conductor:nextBuilding from source additionally requires Docker Desktop, Node.js 18+, and pnpm:
git clone https://github.com/conductor-oss/conductor
cd conductor
./gradlew build
cd server
../gradlew bootRunThe local startup instructions do not require API credentials. Workflows that call an LLM provider, MCP server, or another external API will require whatever endpoint configuration and credentials that integration uses.
How do you use this agent?
Create and run the documented first workflow, which calls an API and parses the response without requiring a worker:
curl -s https://raw.githubusercontent.com/conductor-oss/conductor/main/docs/quickstart/workflow.json -o workflow.json
conductor workflow create workflow.json
conductor workflow start -w hello_workflow --syncRunning workflow create twice returns an expected error because the definition already exists; use conductor workflow update to change it. Production workflows can dispatch tasks to external workers or use built-in types such as LLM_CHAT_COMPLETE, LIST_MCP_TOOLS, and CALL_MCP_TOOL. Every CLI operation has an equivalent cURL/API path, while the UI exposes task inputs, outputs, timing, and retry history.
How does this agent compare with similar options?
Compared with the code-first engines described in the source, where workflow definitions and business logic share a runtime and state recovery replays application code, Conductor keeps the orchestration graph in declarative JSON and runs business logic in ordinary workers. This reduces determinism restrictions on worker code and lets teams revise or version orchestration without redeploying workers. The tradeoff is an additional service boundary and separate workflow definitions to operate. No competing product is named, so the supplied material does not support product-by-product feature or performance claims.