Enable scalable structured AI agent coordination with Dapr Workflows | ODFP976

Hi there, my name is Kendall Roden. Welcome to our session on durable execution, where we'll explore the powerful combination of Dapr and Diagrid. More specifically, we'll explore how Dapr and Diagrid enable code-first resilient workflow orchestration and how this capability is evolving to support emerging AI and agent-based scenarios. Before we dive in, let me give you a bit of context. Diagrid was founded in 2021 by Mark Fussell and Jeroen Schneider, the co-creators of Dapr. Their mission? to boost developer productivity by providing tools and APIs that simplify the process of building and operating cloud-native apps. Tapper began at Microsoft in 2019 as an open-source project designed to tackle the growing complexity of distributed systems. Since then, it's evolved into one of the most active CNCF projects, officially graduating in 2024 with a vibrant and expanding community. Diagrid emerged to build on that foundation, supporting production use cases and enabling teams to scale with confidence. At its core, Dapr provides portable building block APIs and a powerful programming model, from things like service invocation, PubSub, and state management to durable workflows and the recently released conversation API. The Dapr APIs abstract way underlying infrastructure and reduce code complexity. They're language agnostic and exposed via sidecar architecture to applications, so developers can stay focused on business logic and not plumbing code. It's all designed to help you build resilient distributed applications without being locked into one cloud language or runtime. As Dapr adoption continues to grow and evolve, we're seeing a continued shift from organizations toward workload-centric development, where platform teams provide reusable building blocks and frameworks, while product teams focus on delivering features. Dapr fits right in as a unifying API layer across clouds and environments. According to the latest State of Dapr report, teams adopting Dapr are reducing cognitive overhead, speeding up delivery, and improving their overall system resilience. But as organizations move from prototyping to production with Dapr, one thing is clear. The simplicity Dapr brings to development teams must be matched with support for Dapr operational maturity. And this is where Diagrid comes in. At Diagrid, we support developers running Dapr production by offering enterprise-grade support. When urgent issues arise, Our engineering team is on-call delivering hot fixes, CVE patches, and upstream contributions to keep systems secure and stable. We also offer deep customer enablement through onboarding, architecture reviews, and targeted training to help teams use DAPR effectively in production. In addition to providing support, we also offer the Diagrid DAPR Distribution, or D3E, which is a custom-built DAPR tailored for enterprise requirements. It supports things like namespace level isolation of the Dapr control plane, reduced Kubernetes permissions, and integrations like Dynatrace. These enhancements make it easier for Dapr to run in regulated or large-scale multi-tenant environments. Alongside support and D3E, Diagrid Conductor rounds out the Diagrid Enterprise authoring, bringing operational automation and visibility to teams running Dapr in production. Conductor connects to your Kubernetes clusters and automates tasks like Dapr upgrades, certificate rotation, configuration reconciliation, and safe rollouts, reducing manual overhead and operational risk. It also provides real-time advisories across security, reliability, performance, and observability, helping teams identify and resolve issues before they impact production. With a live app graph and per-app metrics, Conductor gives you deep visibility into how your Dapr-enabled services interact with one another, making it easier to troubleshoot and manage your Dapr workloads with confidence. It's available in the Azure marketplace. For teams running open-source Dabr on Kubernetes, Diagrid Enterprise provides the tooling and support needed to operate it confidently in production. But Dabr is still tied primarily to Kubernetes, which can introduce friction from an operational perspective, especially for teams looking to move quickly or reduce infrastructure overhead. That's why we built Catalyst, a fully managed Dabr platform designed to simplify adoption from day one. Catalyst provides a centralized way to use Dapr across teams and environments without having to deploy or manage the runtime yourself. Supports connections from any compute platform, Kubernetes, containers, VMs, or serverless, and delivers Dapr's APIs as a fully managed service. It also unlocks the latest Dapr features like the workflow API, enabling teams to build stateful event-driven workflows without standing up and operating workflow infrastructure. It's a simpler way for developers to adopt Dapr and for platform teams to offer it as a shared internal service. Unlike open source DAPR, Catalyst doesn't require sidecars to run in the same Kubernetes pod or container app as your application workload. Instead, it exposes the DAPR APIs over the network using a remote sidecar called the Catalyst App ID, so your services remain decoupled from infrastructure constraints. This unlocks broader deployment flexibility while giving you consistent access to the DAPR APIs. Catalyst is available as a fully hosted service or can be deployed in your private network depending on your operational and compliance needs. In either setup, it acts as a centralized Dapr platform and workflow engine. This gives platform teams control and visibility, while also giving developers a faster path to building productively with Dapr. Now that you have the background on both Dapr and Diagrid, let's shift gears and explore some of the most exciting innovations built on top of this foundation, starting with serverless workflow execution. The Dapr workflow API is stable as of Dapr 1.15. Dapr workflows enable developers to orchestrate stateful long-running business processes. Let's walk through a real Dapr workflow running on Catalyst, a centralized Dapr API platform, demonstrating durable execution, platform independence, and full workflow visibility without any infrastructure setup. Here we're in the Catalyst dashboard, looking at multiple applications coordinated through a Dapr workflow. Here, each application is identified by an application ID and registered as part of a project within Catalyst. If we take a look at one of the app IDs, which are essentially remote dapper sidecars hosted within Catalyst, we can see important information like how we can connect to a given app ID and also the different types of API calls that are being made from each of the respective applications. For example, we can see the order processor app is publishing to a PubSub component and also invoking other services like inventory payments and shipping as we saw in the app graph. Additional metrics insights are provided to help us understand how an app ID is being used. In this demo, the order processor workflow coordinates key activities like inventory checks, payments, and shipping. Each activity can use other DAPR APIs. For example, the notify step publishes messages to a PubSub component. These messages are then picked up by the front end subscriber at the notification service and displayed here in real time for demo purposes. Here we can see how your application connects to the Catalyst-hosted DAPR workflow engine. The SDK establishes a bidirectional GRPC stream which allows Catalyst to manage the workflow execution. Let's take a look at an example Python application that makes use of Dapr workflows. It's all just to use Dapr workflows. We'll first import the Dapr workflow SDK for the language of our choice. We then instantiate the runtime using workflow runtime. This object registers workflows and activities and handles the connection to the Catalyst engine. Next, we can focus on actually building out a workflow. You can see here we have a workflow context object. which gives you access to workflow capabilities like calling activities. In this case, we're chaining multiple activity calls together for validating the order, reserving inventory, processing payment, and sending notifications as to the status of a given order. For the sake of this demo, we've created an order endpoint that allows a user to submit a new order, which will then use the workflow SDK to kick off a new workflow instance. To run our workflow, we can use an existing Dapra multi-app run file, which will launch our local applications while connecting to the remote hosted sidecars or app IDs. This same exact file can be used to run Dapr locally, making the two very compatible. Using the Diagrid dev run command, we can execute against the Dapr YAML file. Catalyst will handle provisioning the required resources and launching the local applications, connecting them to Catalyst. This workflow is simply triggered by making an HTTP call to the order endpoint. That means my app could be a serverless function, a container on any cloud, or even running on the edge. it just needs access to the Dapr workflow SDK and connectivity to Catalyst. Catalyst provides instant visibility into the API request that was just made, including any other Dapr API calls that were made as part of that workflow initiation. We can also use Catalyst workflow visualization to see all of the workflow executions within a given Catalyst project. This makes it easy to be running, completed, or even failed workflows with full visibility into the workflow inputs, outputs, and status. The workflow execution graph is generated progressively as a workflow executes at runtime, indicating the specific execution path taken. This isn't a simulation or mocked up flow. It's a real orchestration of a real business process. It's triggering downstream services, handling state, and automatically managing retries if anything goes wrong. Catalyst makes troubleshooting workflows more approachable for developers and operators. You can trace every input and output, track retries, and get actionable error insights without extra tooling. So in review, we now know what it looks like to run Dapr workflows with Catalyst, which lets you orchestrate multi-step durable business processes like order handling or payment pipelines. But let's take that one step further. What if you could build not just workflows, but autonomous, stateful logic that could run continuously and react to changes in real time? That's exactly what Dapr Agents enable. Dapr Agents is a new developer framework built on top of Dapr that enables building production-grade AI agent systems. It allows software developers to create AI agents that reason, act, and collaborate using large language models while leveraging the underlying stateful workflow execution in DAVR. Acting as intelligent building blocks, agents seamlessly combine LLM-driven reasoning with tool integration, memory, and collaboration features to enable scalable agentic systems. This diagram shows how agents use tool calls to access external capabilities. The user asks a question, the LLM identifies the needed tools and parameters, the agent executes the function call and the LLM crafts a response using the returned data. In our Lord of the Rings demo, the same pattern enables character-based agents to access unique abilities while Dapper orchestrates their collaboration. Each member of the fellowship maintains their distinct personality while working together through Dapper's PubSub messaging and workflow coordination. I've kicked off our workflow in the background and sent in a prompt about the best path to Mordor. What you're seeing here is a demo UI that's subscribing to the PubSub channels used behind the scenes in order to establish communication between our Lord of the Rings agents. The LLM orchestrator is the critical coordination layer in the system. Unlike the character agents with specialized knowledge, the orchestrator serves as a central conductor. It processes inputs, determines relevance, and intelligently routes information to the appropriate agents. This separation of responsibilities is key. Character agents focus on domain expertise, while the orchestrator handles the workflow logic. This pattern enables complex multi-step reasoning that would be impossible for a single agent to manage. It's all the real value is in how Dapr's PubSub messaging and workflow orchestration provide enterprise-grade resilience beneath this collaboration. If any agent fails, Dapr handles retries while maintaining workflow state. As you watch these agents collaborate to plan their journey to Mordor, you're seeing how Dapr agents enables truly autonomous observable AI systems, that can distribute complex problem solving across specialized components. Now let's hop into how Catalyst can help give visibility into these agents. Here we can see the workflows dashboard with the completed executions that were made as part of that Lord of the Rings multi-agent system. Notice the distinction between the tool calling workflows for each individual agent action and the LLM workflow orchestrator that's coordinating everything. Examining one of the tool calling workflows shows how our agents interact with OpenAI's language models. Noting the input contains message metadata and request parameters, while the output shows the LLM's response describing the journey from Rivendell. The workflow graph shows a simple sequence, generating a response, then extracting it as a message. In the History tab, we can trace the exact sequence of task executions, from generate response to broadcast messages to agents. This is the enterprise-grade workflow engine underlying the agent collaboration you witnessed before. Catalyst provides messaging infrastructure out of the box, letting you focus on agents rather than worrying about infrastructure configuration. Here we can actually see the various topics that are used to coordinate communication across agents. We can also use the built-in key value store provided by Catalyst to get up and running quickly. Here we see this KVStore is used to host the agent registry, which is what allows the orchestrator to discover the available agents and route messages appropriately. Now let's take a look at that LLM workflow. This orchestrator uses Dapper's continuous new pattern with a max iteration set to three, which is why we see a progress summary in the output and a completed status on the workflow. We're now seeing the historical context of what happened specifically for iteration three of this workflow. If we take a look at the history, we'll get a better understanding of how the orchestration across agents work. In iteration three, the last input received from an agent was something about the Misty Mountains. Based on that input and the objective that's needed to be accomplished, The orchestrator decides which agent to call next and what that instruction should be to build on the knowledge. We then update the task history to reflect the amount of steps that have been accomplished in achieving the overall prompt objective. Finally, we see that the execution is completed. Once again, because the max iterations is set to three, there are some remaining tasks that need to be accomplished in order to fulfill the full ask from the prompt. Finally, let's take a quick look at this code. Here we can see the implementation of our LLM orchestrator. It's very concise, importing the LLM Orchestrator class and configuring it with the necessary messaging and state store parameters. The max iteration parameters limit how many planning rounds the orchestrator will execute before completion. With Catalyst, deploying a Managed Orchestrator becomes trivial. You get the built-in monitoring, state visualization, and message tracing. Lastly, let's look at the code implementing a particular agent. It's also remarkably simple with just a few lines of code to import the Assistant Agent class. and configure it with a role, name, goal, and instructions. We'll also see how the agent connects to the message bussets in state stores with simple parameters. Thanks so much for taking the time to check out this session. If you're interested in signing up and trying out Catalyst, feel free to do so. We'd love for you to join the Diagrid community if you have any questions about Catalyst or Diagrid Enterprise.

This is one of many innovative Featured Partner sessions from Microsoft Build 2025.  View more information from this partner at https://aka.ms/Build25_Diagrid

As AI agents become more autonomous, orchestrating their behavior within reliable systems is critical. Dapr Workflows, now supporting LLM-driven agents, enables structured, fault-tolerant coordination. This session explores how Dapr Agents and Workflows power agentic AI with durable execution, event-driven scalability, and built-in observability. See how Dapr simplifies multi-agent automation, decision-making, and inter-agent collaboration for production-ready AI systems.

To learn more, please check out these resources:
 * https://github.com/dapr/dapr-agents
 * https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/
 * https://www.cncf.io/blog/2025/03/12/announcing-dapr-ai-agents/


𝗦𝗽𝗲𝗮𝗸𝗲𝗿𝘀:
 * Kendall Roden


𝗦𝗲𝘀𝘀𝗶𝗼𝗻 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻:
This is one of many sessions from the Microsoft Build 2025 event. View even more sessions on-demand and learn about Microsoft Build at https://build.microsoft.com

ODFP976 | English (US) | AI, Copilot & Agents


#MSBuild, #AI

Chapters:
0:00 - Introduction and Session Overview
00:01:01 - Core Features of Dapper
00:01:34 - Dapper's Role in Workload-Centric Development
00:06:21 - Application Interaction and Metrics Insights
00:08:02 - Using Dapper Multi App Run File
00:08:22 - Utilizing diagradevrun Command with Dapper
00:08:53 - Catalyst Workflow Visualization
00:11:42 - Dapper's Workflow Orchestration and Error Handling
00:13:21 - Examination of the LLM Orchestrator Workflow