Repository navigation
Seeking Feedback on AI Agentic Framework Design: Integrating Dapr Workflows and Actors #30
Description
Activity
Sorry for the delayed response. Looks like this issue fell through the cracks.
Generally speaking, this is a perfectly good use case for a workflow. My somewhat biased recommendation is that workflows would be a cleaner solution vs. actors because the end-to-end flow is more easily reviewable and debuggable vs. actors and queues. There's also less infrastructure to manage.
The benefit you'd also get with HTTP APIs is the ability to start one of these agentic workflows and poll for its completion. This could simplify integration with external services which are capable of invoking APIs.
HTH
Reacted by Roberto RodriguezThank you for circling back, Chris Gillum (@cgillum) ! No worries at all. I completely understand how issues can sometimes fall through the cracks.
It is honestly amazing to receive this response almost exactly two years later and look back at where the idea ended up.
I started exploring this problem toward the end of 2023 and built my first proof of concept in early 2024. When I opened this issue in July 2024, I was still unsure whether workflows were the right approach for combining deterministic execution with LLM-driven decisions. Your response is a nice confirmation that the direction I ended up taking made sense.
I kept working on the idea and released [Floki](https://github.com/Cyb3rWard0g/floki) toward the end of 2024. It was built around Dapr Workflows for durable agent orchestration, while also using Dapr’s messaging, service invocation, actors, and state-management capabilities.
In 2025, I donated Floki to the CNCF Dapr project, where it became the foundation for what is now [Dapr Agents](https://github.com/dapr/dapr-agents). Durable workflow execution is now a core part of the project’s approach to building resilient agentic systems.
It has been really exciting to see durability get so much more attention in the agent ecosystem.
Even though the response came two years later, it feels like a really nice full-circle moment. Thank you again for the feedback and for all the work you and the Durable Task team have done. Learning about Durable Task, Dapr Workflows, and the different implementations back in 2023 and 2024 played a big part in shaping what eventually became Floki and now Dapr Agents.
Reacted by Chris Gillum, Ashim Mahara and Yaron Schneider
Hello Team,
I am building an AI Agentic Framework in Python to utilize Dapr Workflows and Actors for triggering conversational agents. In my use case, I sometimes have specific steps (workflows) that guide agents, and other times I let an Agent Orchestrator (LLM-based) determine the next steps (activities). These activities would then point to or call other specific agents (services).
I understand that workflows are ideal for deterministic plans. However, in my Agent Orchestrator use case, the "activities" are not in a specific order. My idea is to create a workflow that triggers the Agent Orchestrator as activity number 1. Following that, I want to run a generic activity number 2 that invokes or calls a service (agent). Depending on the orchestrator's decision, one of the 2-3 available agents would be called for each iteration.
My question is whether this is a good use case for workflows. Or, should I consider using an Orchestrator Actor that pushes the request to the appropriate queue (one topic per agent/service) and lets the services handle the requests by retrieving tasks from the queue? I noticed that one of the workflow patterns in the Dapr documentation is Async HTTP APIs. Would that pattern be beneficial for this scenario? Here's the link for reference: Async HTTP APIs.
Could a combination of workflows and actors be the best approach here? I would love to get your feedback on this use case. Should I create an issue in the Dapr repositories too? If so, which ones.
Thank you in advance!