LangGraph alternative
A runtime for agent workflows, not a library inside your app.
LangGraph is a good way to express an agent graph in code. Dagu is the layer that runs it: one self-hosted binary where a workflow is YAML, agents are ordinary steps, and schedules, queues, retries, durable pauses, and run history come from the engine instead of the application you write around it.
# triage.yaml
schedule: "*/15 * * * *"
steps:
- id: fetch
run: ./scripts/fetch-new-issues.sh
output: ISSUES
- id: classify
action: harness.run
with:
provider: claude
prompt: Classify each issue in ${ISSUES}. Return JSON.
output_schema:
type: object
additionalProperties: false
required: [labels]
properties:
labels:
type: array
items:
type: string
retry_policy:
limit: 3
interval_sec: 30
depends: [fetch]
- id: apply_labels
run: ./scripts/apply-labels.sh
depends: [classify]
Execution order
Workflows are YAML, not application code
Steps are processes, so any language or CLI works
Schedules, queues, retries, and history ship in the binary
Waiting runs release the process and resume later
At a glance
LangGraph vs. Dagu for teams that have to operate it
A workflow engine you run as a binary.
A library you embed in a Python or JavaScript application.
Declarative YAML, versioned next to the code it runs.
Graph construction in application code.
Schedules, queues, retries, artifacts, and run history come with the engine.
Checkpointers persist graph state; scheduling and serving come from your service or LangGraph Platform.
A process: any language, any CLI, optionally inside a container.
A function in the host process.
In depth
Where each tool fits
A library needs an application. An engine does not.
LangGraph builds the graph. Something still has to schedule it, queue it, retry it, persist its state, and show you what happened. That something is the service you write, or LangGraph Platform. Dagu is already that layer.
- Run one binary. There is no web service to write and no worker pool to design.
- Scheduling, queueing, retries, and run history are engine features rather than integrations.
- Deploy the same definition on a laptop, one VM, or a coordinator with workers.
Steps are processes, so the workflow is not language-bound
LangGraph nodes are Python or JavaScript functions running in your process. A Dagu step is a command, so the unit of work is whatever already runs in your environment.
- Call shell scripts, binaries, containers, SSH commands, HTTP endpoints, and SQL from one workflow.
- Run coding agents through `harness.run`: Claude, Codex, Gemini, OpenCode, or an internal CLI.
- Give any step a container sandbox with explicit mounts, toolchains, and egress rules.
Draw the graph when you can, hand over the order when you cannot
LangGraph asks you to draw every path, which is correct until the order depends on what a reviewer said. Dagu keeps `type: graph` as the default and adds `type: agent` for the work that never fit in one.
- An Agent DAG declares completion criteria and lets a model pick the next action.
- The model chooses only among the steps you declared, so the blast radius is the file.
- Both types produce the same run, with the same logs, retries, artifacts, and history.
FAQ
Practical questions before adopting Dagu
Is Dagu a drop-in replacement for LangGraph?
No. They sit at different layers. LangGraph is a good fit when you want to compose model calls in Python or JavaScript with fine-grained control over graph state. Dagu is the better fit when the work is a set of commands and agent CLIs that need schedules, retries, approvals, and an audit trail.
Can I keep using LangGraph inside Dagu?
Yes. Keep the LangGraph application as a script or container and run it as a step. Dagu supplies the schedule, retry policy, logs, artifacts, and run history around it.
How does Dagu handle human-in-the-loop?
Human tasks, and `ask_user` inside Agent DAGs, suspend the run durably. The process exits and the worker slot is released, and the run resumes on a fresh process once a person answers.
Does Dagu need a database?
No. Dagu is a single binary that stores workflow definitions, run history, and logs as files, so there is no metadata database or message broker to operate before the first run.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.