yaronsc

We added hash-chained workflow histories to Dapr Workflows (a Durable Execution engine).

Each batch of workflow events is cryptographically linked to the previous batch and signed using the SPIFFE workload identity that produced it. This makes workflow histories tamper-evident and allows verification of execution integrity, provenance, and identity.

The docs cover the design, verification model, and implementation details.

Happy to answer questions about the architecture or tradeoffs.

I'm the creator of the Dapr CNCF project, happy to answer any questions.

One pattern we've seen while building AI agents is that developers often have to make a frustrating choice between agent frameworks and workflow engines.

Frameworks like LangGraph, Strands, CrewAI, ADK, etc. already implement reasoning loops, tool execution, retries, and memory. But they typically don't provide durable execution—if the process crashes, the agent will restart from scratch. Some have very basic checkpoint systems that leave failure detection and resumption to the user, which is essentially the hard problem workflow engines solve.

The problem with workflow engines is they handle durability well but require developers to rewrite their agent logic inside the workflow system, which means rebuilding the agent framework from scratch.

This work aims to remove that tradeoff by allowing existing agent frameworks to get all the benefits of a durable workflow orchestrator without rewriting any part of their code.

Thank you! :) (Dapr maintainer here)

Hi everyone, I performed a deep analysis of the code, runtime behavior and architecture of many popular agent frameworks and decided to publish a post with some initial findings on what I perceive to be critical gaps when it comes to guaranteed execution in real world scenarios, that shift the hardest problems to the users. Happy to discuss further

This is a way to give developers and semi-technical people a way to generate and run code-first workflows using a visual language, be it UML or otherwise. We will be expanding support for text prompts in the future

Very much so, and in next iterations we will be expanding the scope both in what the generated code does as well as the ways to prompt

Definitely fair feedback, we will look into it

1. A user can always go into the generated code and make changes to it. The code generated includes explanations for what each step in the workflow does

2. Dapr has 9 APIs, one of which is Workflows which indeed competes with Temporal. Dapr Workflows isn't DAG based, it's code-first. This tool allows you to start with an external representation

Great point. Our tool does UML/BPMN as well as regular drawn diagrams without a specific notation, and will soon expand into regular prompts

Dapr is a code-first workflow engine that doesn't require a DSL language and includes many other integration points like pub/sub, service discovery and more. It also runs and deploys natively on K8s

Thanks for the response! What you're saying about embedding and enriching existing code based is definitely next level and I'll bring it back to the team to explore

Great idea and a work in progress :)

Hi thanks for your question. You wrote "more or less" and that's very accurate - the generated code by just feeding it to any LLM provider usually doesn't work out of the box, includes many hallucinations and also doesn't provide a solution that can be immediately downloaded and run in your IDE

Will take a look, thanks!

Good suggestion, thank you

Dapr's state management API supports more than 20 different databases, with the ability to stream data at high scale right into the agent tasks. That's a major differentiator as you can plug in almost any database and message bus into Dapr Agents.

We wanted to create a vendor neutral framework that doesn't over pivot on features that are tied to the backing of a commercial product. The other and no less important point is the ecosystem that Dapr has around messaging and state integrations. A lot of the Agentic AI frameworks you see today will not withstand a restart of the process,let alone complete cluster shutdown. Dapr has durability built-in to handle these catastrophic failures

Benchmarks are WIP. We're thinking about durability, task latency, agent throughput. What else would you like to see?

Makes total sense and we have this as WIP

Having the calls go through Dapr is actually a pretty powerful feature: Dapr will handle retries and handle failures and guarantee an at-least-once delivery. For high-throughput scenarios we have a gRPC client which can see a much higher throughput than regular HTTP.

Yes, you are right: from the consumer's viewpoint, it's "ask to subscribe, ask to publish a message" and you're off.

Hey e12e, Dapr is meant for both small or large setups. It's designed to handle your scale as it grows and be highly performant.

Dapr itself is a sidecar - it can be easily autoscaled by external autoscalers like Kubernetes offers, KEDA and others.