dapr-agents: Durable Workflow Execution for LLM Agents on the Dapr Runtime
Build autonomous, resilient and observable AI agents with built-in workflow orchestration, security, statefulness and telemetry.
At a glance
- What is it?
- dapr-agents is a Python framework that puts LLM agent loops inside Dapr's durable workflow engine, so agent tasks survive node crashes and network interruptions. It is a strong fit if you already run Dapr or Kubernetes, and a heavy dependency if you do not.
- Who is it for?
- Adopt dapr-agents if your agents must survive process restarts and you already operate Dapr or Kubernetes, because the retry and state recovery behaviour comes from the Dapr Workflow API rather than from application code. Do not adopt it for a single-process prototype or a laptop-only demo, where installing a Dapr sidecar and a state store costs more than the resilience is worth.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure dapr-agents is built to survive
Most agent frameworks treat a run as a Python process that calls an LLM, invokes tools, and writes results somewhere. If the process dies halfway through a multi-step task, the task is gone. The README frames the problem in exactly these terms: a durable-execution workflow engine that "guarantees each agent task executes to completion in the face of network interruptions, node crashes and other types of disruptive failures." That is the specific gap dapr-agents targets. It is aimed at software developers building agent systems that are expected to run in production, on a cluster, for long enough that a crash is a matter of when rather than if. It is not aimed at notebook experimentation. The README's phrase "production-grade resilient AI agent systems that operate at scale" sets the audience, and the rest of the document is about how the Dapr runtime supplies that resilience rather than how the LLM prompting works.
Actors, workflows and where agent state actually lives
The mechanism is layered. At the bottom, Dapr's Workflow API runs on actors, which the README describes as "a single unit of compute and state that is thread-safe and natively distributed." An actor is the addressable unit; a workflow is the durable orchestration over it. When you write an agent, the README says you do not need to know about the workflow engine's internals: "simply write an agent that performs any number of tasks and these will get automatically distributed across the cluster." If a task fails, it is retried and recovers state from where it left off. That recovery depends on state being external to the process, which is why the state store and the message broker are part of the architecture rather than optional add-ons. The README also lists the messaging primitives that multi-agent coordination uses: service-to-service invocation for synchronous calls between agents, and publish/subscribe for "loosely coupled collaboration between agents through a shared message bus." So a multi-agent system here is not agents sharing a Python event loop. It is agents as separately addressable Dapr applications exchanging messages through Dapr building blocks, with the workflow engine holding the durable record of what has completed. The scale claim attached to this design is that the virtual actor model "allows thousands of agents to run on demand on a single core machine" and that idle agents are reclaimed while retaining state. That figure comes from the README and I have not measured it; treat it as the project's own description of the architecture's intent.
Getting an agent running: package, sidecar, components
The README does not print a full quickstart, so I will stay with what it does establish. The package is published on PyPI as dapr-agents, and the repository is Python. Because the framework sits on Dapr, a running agent implies a Dapr sidecar alongside your process, plus at least a state store component and, for pub/sub coordination, a message broker component. Those are configured as Dapr components, not as Python settings, which is the main structural difference from a self-contained agent library. The README points at the Dapr components reference for supported bindings and state stores, and at the Dapr Agents integrations page for connectors such as the arXiv fetcher used for PDF extraction. Model configuration and tool wiring are described only as feature areas (multiple LLM providers, structured outputs, contextual memory, intelligent tool selection), so the exact config keys are not in the material I have. One integration detail is concrete: MCP servers are auto-discovered from the Dapr sidecar, which the README calls "zero-config MCP integration." That matters because it means tool discovery happens through the sidecar's component model rather than through code that enumerates servers. If you are evaluating this, the first thing to read is the Dapr sidecar and component configuration, not the Python API.
What the durable execution model costs you
Durability is not free, and the README does not discuss the bill. Durable workflow engines generally achieve recovery by replaying a workflow's history, which means steps with side effects have to be written so they are safe to re-execute or are recorded as completed before the effect is repeated. The README's promise that developers "do not need to know about the underlying concepts of the workflow engine" is the part I would push back on. You can ignore the engine while the happy path runs. You cannot ignore it when a tool call has already charged a card, sent an email, or written a row, and the workflow restarts. The documentation supplied here does not describe the determinism rules or the replay constraints, so that is the first thing to verify against the Dapr Workflow documentation before putting anything with external side effects into an agent task. There is a second cost: this is a distributed system. A state store, a message broker, and a sidecar are now part of your agent's dependency graph, and each one is a thing that can be misconfigured. For a single-process prototype, that is a large amount of infrastructure to stand up for retry behaviour you may not need yet.
Where dapr-agents is the wrong tool
If your agent is a short-lived request handler that answers a question and returns, the durable workflow layer is overhead. The retry and recovery machinery matters when tasks are long, multi-step, and expensive to restart, and when the process running them is expected to be interrupted. A chat endpoint that completes in seconds does not meet that bar. The second case is a team with no Dapr footprint and no Kubernetes. The README's own feature list leads with Kubernetes-native deployment and platform-ready scoping, which tells you where the project expects to live. Adopting dapr-agents outside that environment means adopting Dapr as well, and the framework's value proposition is largely the value proposition of the runtime underneath it. The third case is a team that needs a specific agent abstraction the framework does not expose. The README lists its AI features at a high level, and where your requirement falls outside that list, you are working against the framework's grain rather than with it.
How this differs from LangGraph and similar agent runtimes
LangGraph is the obvious comparison point for anyone reading this, and the difference is architectural rather than cosmetic. LangGraph models an agent as a graph of nodes and edges executed by a runtime you embed in your own process, with checkpointers you configure for persistence. dapr-agents models an agent as a Dapr application, and the durable execution comes from the Dapr Workflow API running on actors. The consequence is that state and coordination live outside your process by default, in Dapr's state store and message broker, and the same runtime that retries your workflow also handles service discovery, mTLS between components, and pub/sub between agents. The trade is control for infrastructure. With an embedded runtime you own the process, the deployment, and the persistence layer, and you can run it anywhere Python runs. With dapr-agents you inherit Dapr's operational model, including its sidecar, its component configuration, and its security defaults. Neither is strictly better. If your organization already runs Dapr, the second option removes work you would otherwise do yourself. If it does not, the first option is a smaller commitment.
Maintenance, releases and the Apache-2.0 terms
The repository is not archived, and the release history shows v1.0.3 in May 2026, v1.0.4 in June, and v1.0.5 on 2026-06-15, with the last push to main in September 2026. That is a 1.x line with patch releases rather than a pre-1.0 project, which is the relevant signal for adoption risk: the API surface is being maintained, not redesigned between releases. The cadence is frequent enough that pinning a version and reading the changelog between upgrades is the practical approach. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve the licence and notice files and state significant changes. That is a summary of the licence text, not legal advice, and if you are redistributing the framework or a modified version of it, the notice and attribution obligations are worth reading in full. The framework's dependency on the Dapr runtime is the larger ongoing cost: Dapr itself has its own release cadence and its own upgrade path, and a Dapr upgrade is an upgrade to your agent's execution substrate, not just to a library.
Editorial conclusion
Adopt dapr-agents if your agents must survive process restarts and you already operate Dapr or Kubernetes, because the retry and state recovery behaviour comes from the Dapr Workflow API rather than from application code. Do not adopt it for a single-process prototype or a laptop-only demo, where installing a Dapr sidecar and a state store costs more than the resilience is worth. Before committing, verify that the workflow engine's replay semantics match your tool side effects, and check the PyPI release history for the cadence you can tolerate.
Community notes