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.

A scheduled agent workflow with nothing 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

fetchclassifyclaudeapply_labels

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

Shape
Dagu

A workflow engine you run as a binary.

LangGraph

A library you embed in a Python or JavaScript application.

Definition
Dagu

Declarative YAML, versioned next to the code it runs.

LangGraph

Graph construction in application code.

Operations
Dagu

Schedules, queues, retries, artifacts, and run history come with the engine.

LangGraph

Checkpointers persist graph state; scheduling and serving come from your service or LangGraph Platform.

Unit of work
Dagu

A process: any language, any CLI, optionally inside a container.

LangGraph

A function in the host process.

In depth

Where each tool fits

01

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.
02

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.
03

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.