DuraGraph

What does this agent do, and when should you use it?

DuraGraph is a self-hosted, enterprise-oriented orchestration layer for AI agent workflows built around one idea: every state transition is written as an immutable event to PostgreSQL in the same transaction as the work itself. That makes runs crash-safe and replayable — if a worker dies mid-tool-call, the engine resumes from the last committed state instead of losing work or re-executing it. The repository is a monorepo: cmd/duragraph holds the single control-plane binary (engine, embedded dashboard, dev bootstrapper), internal/ implements DDD, event sourcing and CQRS layers, dashboard/ is a React + TanStack Router + xyflow console with a visual workflow editor embedded into the binary at build time, python/ and go-sdk/ provide worker SDKs, examples/ ships Go and Python reference agents, and deploy/ carries Docker assets, SQL migrations and Helm charts. The external surface is a stable REST + SSE API over runs, threads, assistants and graphs, and workers register graph definitions on startup through the SDKs — no code generation or DSL. Deployment is two-mode: dev runs embedded PostgreSQL and NATS in the one binary, production points at external Postgres and NATS.

Workers connect to the control plane with the Python or Go SDK and register their graph definitions at startup. Clients create work with POST /api/v1/threads/:id/runs; the graph execution engine then walks nodes, edges, conditional branches, human-in-the-loop interrupts and tool calls, persisting each state transition as an event in the PostgreSQL event store as part of the same transaction. If a worker crashes, the engine resumes from the last committed state without double execution. An outbox relay forwards domain events to NATS JetStream, which drives SSE and dashboard updates decoupled from write throughput. Read paths go through CQRS queries: GET /api/v1/runs/:id fetches run state, GET /api/v1/threads/:id/runs lists a session's runs, GET /api/v1/threads/:id/runs/:run_id/stream streams live execution events, POST /api/v1/assistants registers an assistant and GET /api/v1/assistants/:id/graph introspects graph topology. OpenTelemetry-friendly Prometheus metrics are exposed as well.

1. Teams running long-lived LLM agents that can execute for hours and who need a worker to resume from the last committed state after a crash rather than losing the run.
2. Engineering groups that need auditability: every state change is timestamped, ordered and signed by aggregate version, so evals and compliance views can be built directly on the event store.
3. Developers debugging a failing production run who want to step through the exact sequence of decisions that produced it instead of reading a stack trace and a vague last-known position.
4. Individuals or small teams who want to try an agent workflow locally with zero infrastructure: one duragraph dev command starts the engine with embedded Postgres and NATS, then the Playground sends the first message.
5. Existing Go or Python agent codebases that can register graph definitions via go-sdk or the python/ SDK without adopting a new DSL or running a code generator.
6. Platform teams standardizing on a self-hosted control plane with REST + SSE APIs, an embedded dashboard and Prometheus metrics, planning to swap in external Postgres and NATS for production.

How do you install or deploy this agent?

Four install paths are documented:

# Homebrew (macOS, Linux)
brew install Duragraph/tap/duragraph

# One-line install script
curl -fsSL https://duragraph.ai/install.sh | sh

# From Go
go install github.com/Duragraph/duragraph/cmd/duragraph@latest

# Or grab a prebuilt binary
# → https://github.com/Duragraph/duragraph/releases

For source development:

git clone https://github.com/Duragraph/duragraph.git
cd duragraph
task dev   # runs the engine + dashboard against a local Postgres + NATS
task test  # unit + integration suite

Credentials: none are needed up front — dev mode embeds PostgreSQL and NATS, and the first sign-in uses the bootstrap admin printed in the startup logs. Production expects external PostgreSQL and NATS; deploy/ contains Docker and SQL migrations, while production Helm charts are still listed as in flight.

How do you use this agent?

Start the server:

duragraph dev
# → Engine + dashboard on http://localhost:8081

Run your first agent: open http://localhost:8081, sign in with the bootstrap admin printed in the logs, go to Playground, pick a registered assistant and send a message. Each node lights up as it runs, the full graph topology is visible, and a replayable event log is available under Traces. The examples/ directory has RAG, tool-using agent, document processing and eval references in Go and Python that run against duragraph dev out of the box.

Connect your own agent: start a worker and register graph definitions through the python/ or go-sdk/ SDK, then drive runs over the REST + SSE API:

POST   /api/v1/threads/:id/runs                  # create a run
GET    /api/v1/runs/:id                          # fetch run state
GET    /api/v1/threads/:id/runs                  # list a session's runs
GET    /api/v1/threads/:id/runs/:run_id/stream   # SSE: live execution events
POST   /api/v1/assistants                        # register an assistant
GET    /api/v1/assistants/:id/graph              # introspect graph topology

What are this agent's strengths and limitations?

How does this agent compare with similar options?

Key facts side by side with the most closely related agents.

How does FollowAgents rate this agent?

FAQ