Dapr in 2026: Durable Execution and Resilient Eventing for AI Agents - Yaron Schneider & Rajesh Iyer

Thank you for joining the Dapper maintainer track. I don't know if you participated in my talk yesterday about AI and Dapper. If you have, I promised you a link and I have to disappoint you that you will not be getting that link today. But follow up afterwards. My name is Erron Schneider. I'm the CTO and co-founder of Diagrid. I created two graduated CNCF project, Dapper and KIDA. And today we'll be talking about what Dapper has been stored for 26 and some of the work we've been doing throughout the year. So if you are new to Dapper and I'm just going to turn this on. Just make these things a lot easier. If you're new to Dapper, Dapper is a set of APIs that allows developers to focus on business logic and not infrastructure. It's great for platform teams, software architects, and just general engineers who want to not focus on how they interact, secure, and observe their infrastructure, but really focus on business logic. So you can integrate Dapper into your platform, and it basically acts as the missing piece for platforms, whereby it's the golden path for how to interact with infrastructure. So far platform engineering has been focused on mainly observing and creating infrastructure and Dapr is all about how do you interact with it safely and securely with all of those best practices built in. So if you'd like to learn more about the different Dapr APIs, please go to Dapr.io or docs.dapr.io and check that out. We've got a pretty big community. We are the 14th largest project in CNCF today. We graduated last year. We have a Discord community that is very thriving. So if you're into anything, AR, distributed systems, a workflow, or really anything about microservices development, please join our Discord community. We're coming close to 8.5K developers there on the Discord community. And we also have more than 4,000 individual contributors. that we passed this year. So great. We've got some notable end users. My favorite deployment of DAPR is, of course, by NASA. They're actually running DAPR on the International Space Station. So DAPR is being used there to take pictures of gloves that astronauts take during space walks. And it acts as the message bus as those gloves find their way to get processed by machine learning algorithms. It basically says, look, there's terrain. We're on this glove. It needs to be replaced. Otherwise, the astronauts just going to um get off the rails of the ship so let's talk a little bit about what we have in store for um dapper and ai what we found was that yes dapper has lots of great apis but when agents and well not just agents llms really started to come into the fore we've discovered that many of the existing dapper apis play really really well into this world of ai For example, Dapr has an API to do service discovery. It allows you to discover services in your cluster. We have one deployment in Kubernetes, another deployment on another namespace or in the same namespace. Dapr allows you to identify those by name. It'll do mutual TLS. And what we've discovered is if you integrate Dapr with pretty much any agentic framework today, you can get to agent identity, where you allow agents to discover other agents and decide who can talk to what and do what in your infrastructure. PubSub is a great way to create ambient agents. Those are agents that are back-end automation systems. They work off of event streams and not necessarily prompts. And the DAPR PubSub API lends itself really, really well into those use cases. State management, and we'll see a demo of that today, allows you to use the DAPR state API to save all of your graph state or conversational history inside of a DAPR-backed state. This gives you access to basically use any form of agentic AI framework you want, but have access to more than 30 different databases that DAPR supports and abstracts over, plus other benefits, which we'll cover later. Conversation API is an API in DAPR that abstracts LLMs, kind of like blank chain, but it does two really important things. First, it has prompt caching. So it caches semantic prompts in the DAPR process itself, meaning if you have a prompt that is very similar to the one that came before it, you're not gonna have to pay egress costs going, you know, from AWS to OpenAR, Anthropic, or even AWS Bedrock, because you're not gonna be hitting the provider to basically get a cache hit or miss. It's all going to be saved inside of the Dapper sidecar locally and of course latency is going to be a lot reduced. And the second feature that we're providing is PII obfuscation. If you don't want personal data to go into the LLM provider, the upper can actually detect email, phone numbers, social security numbers, credit card numbers, and obfuscate them. And this is true for data going into the LLM as well as coming out of the LLM. So if you're running your own model on Kubernetes and you may have put, you know, accidentally some. personal identifiable information data set, DAPR is going to make sure that even if it does come out by any chance, it's not going to get back to the end user. So what do agentic frameworks today focus on? If you've seen them, they have pretty simple programming modes. You basically get your weather agent in DAPR agents, which is a framework I'm going to cover later. We're guilty of that too. We have very simple example that started off with agents that you should never build, like weather agents, tell me what the weather is. And they're really focused on LLM abstraction. Right you basically provide a client to them you say oh it's open AI and then the agent runs a loop and it basically talks to them they are focused on tool usage which is pretty common pretty simple you give the agent an ability to talk to a bunch of tools that represent access to underlying systems and they some of them will also do very very very basic workflows and multi-agent collaboration and Something that's coming into agents today, but it's not really mature enough is the ability to create ambient agents But this is all very hard manual work where you need to integrate the agent with Kafka Pulsar AWS SQS whatever messaging system you have and this is nice, you know in the on the agentic front but They are missing a lot of things and what they're missing is Guardrails run PII. We've mentioned that right so you talked to an LLM how do you make sure that data that suppose that's going into the LLM provider isn't supposed to go in there and about tool usage well MCP is very broken when it comes to authentication How do you authenticate it when you talk to it? How do you make sure that some agents acting on behalf of other agents only have access to certain MCP servers? So they don't expose sensitive information because that MCP server could have access to your underlying database and When it comes to basic workflows most of them offer very simple checkpoints meaning It's great when it's running in a single instance, but if you're running on Kubernetes and you're scaling out to multiple instances, it's just gonna break, it's gonna fail. Or even worse, you're gonna be seeing the exact same workflow with the exact same input executed twice, and that's gonna cost at least twice than what you were supposed to pay for in regards to LLM costs or CPU and memory costs. That becomes expensive real quick. And then if your workflow is not idempotent, well, you're gonna have very severe effects in your business logic downstream. And ambient agents, we all want to create agents that look hook up into our systems, get a stream of events, identify the events and then automate things for us. But it's very difficult to create an event driven layer that hooks up into the agent because then we need the agents to understand partitioning and commits and offsets and this just becomes a pain. So what we did earlier this year, we introduced a framework called Dapper Agents in cooperation with NVIDIA that is running Dapper Agents. And Dapper agents basically has all of those missing features I talked about built in right inside of the framework. It has embedded failure recovery, which means if your agent now has a workflow that consists of 1,000 things and it fails, I think 999, it's not going to need to pick back up from the beginning. It's going to replay from that step with its state in a very low latency manner and just make sure that now you're not going to need to pay OpenAI for an additional 999 calls. And you can also execute text in parallel. You can run multiple agents. It scales beautifully. And then identity using Spiffy. Spiffy is a CNCF project. We use it heavily in DAPR. DAPR agents can basically allow you to say, hey, this agent can only talk to that agent. And they can be in separate clusters as well. And you can create these meshes of identity where you can control who can do what and where. It has multi-agent eventing, so you can wire up multiple agents together instead of needing to create a lot of boilerplate code to connect agents to underlying message brokers with Dapper agents. You basically just tell them, hey. this is my Kafka broker, this is my Pulsar broker, and Dapr will make sure that they discover each other securely, and if one agent cannot do the task it needs to do, it'll hand off to a different agent, and they can communicate transparently. The only thing you need to do is write those agents, deploy them, connect them to message broker, and not need to care about how a message is gonna get from one agent to the other. Dapr is gonna take care of all of that for you. And lastly, it is the only vendor-neutral agentic framework today. kAgent is also in CINCF, but it's very different from Dapper Agents because it's not a programmatic agentic framework. It's more focused on the DevOps layer of running agents in a Kubernetes cluster. So go to that URL, check it out. We'd love feedback. We'd love for you to try it out. But Dapper Agents cannot be the only game in town. We can't expect everyone to basically just, you know, layer on DAPR agents. And so what we're going to be introducing beginning 26 is a major piece of integration with most of the leading agentic frameworks. And some of them are actually coming very soon in 2025. I'm going to be showing a sneak peek of what we're doing with LandGraph here. But we're talking about OpenAI agents and LandGraph agents, which means you're going to be able to just use those SDKs and just make sure that DAPR is running next to them. If you're running those agents, Dapper will make sure that if they fail, it's going to recover automatically wherever these agents are running. Microsoft agent framework, Dapper is going to integrate with that too. And we have a pretty good establishment with the AWS Trans team that is very interested in seeing Dapper also integrate with their system. And they're working with us to create that integration upstream. LangFuse is an observability framework. And they're going to be publishing a piece about how you can observe Dapper agents specifically inside of LangFuse. So all these integrations we're working on pretty extensively and we would love community participation We're not doing a great job at just exposing what we need from the community in terms of work items We do have a bunch of issues in Dapper agents and there will be more issues being opened up in other aspects of Dapper We will have proper communication around this so stay tuned join our discord server Or just follow us in our blog post. It's blogs.dapper.io So let's take a look at what they mean that we can integrate Dapper and LandGraph together. If you're running LandGraph agents today, you can only use two check pointers for their state. Because if you're running a complex graph. and it has a bunch of nodes and one of them fails it's going to need to replay right land graphs give you this very simple ability yes it has many issues running at scale and this is where our second integration is going to come into play where we allow you to use the dapper workflow engine to back up land graph but we're starting with something that is also really really important just integrating the dapper state api into land graph directly and that gives us a few things So let's just go over here. I messed up the slide order, but what we're getting is the following. Instead of just using two check pointers that Langrath gives us today, which is Redis and Postgres, we suddenly get access to 30 plus databases. For example, many people want to run with DynamoDB. Why? Because an AWS solution architect will recommend DynamoDB for eight out of 10 use cases. But you can store your line graph state there. This is a major problem. Now take any other of the other databases that you've got on GCP, Oracle Cloud, Azure, all of them. The line graph ecosystem added one database in the last year, pretty much. So it's not occurring at a fast rate because adding stateful layers is a hard problem. But for DAPR, this is really our bread and butter. So we've created this DAPR check pointer integration that is literally. two lines of code that you need and then your land graph state store will be a dapper state store and dapper will get that state but with it you will also get built-in tracing you'll get built-in metrics request per second error rates and latency for all of your land graph interactions and you'll get the ability to put resiliency policies if you're using just the regular postgres land graph check pointer if it fails to save it'll just die and the process will crash but if you use dapper you can use dapper resiliency policies you can put circuit breakers retries and timeouts to make the saving aspect of things way more resilient and dapper also supports automatic client-side encryption so if you're saving your graph state and it has important information you can also have dapper automatically encrypt the state and yes dapper can also do this in some cases without actually needing access to the encryption material so i'm going to just switch real quick into my code and here we have a state graph this is just regular land graph i don't know if you've seen land graph before who here has seen line graph in action Okay, quite a few people. And this is really simple. This is just a summarization agent. Again, not something that I'd necessarily use an agent for, but it has two steps. So we have a node. This is how you create workflows with a line graph. It's kind of... It's a disgusting program model in my opinion, but it works. You basically add a node, you give it a string, generate, you point it to the generate method, you add another node, summarize, you set the entry point, the entry point is generate, and then you add an edge, right? You go from generate to summarize and from summarize to the end. And then you compile the entire thing and you run it. So Langraf does have a little bit of latency, but you know it runs. So there is nothing dapper specific here. This is literally a Langraf quick start that we would take off the website and just run it locally. But as we mentioned before, there is no way today for anyone to run this against DynamoDB. But now we're going to pair up Dapper to it and the only thing we're going to do is literally have this line of code and this has a Dapper check pointer and it has a key prefix for you to identify your data if you need to if you want to query the data. This can be anything but the most important thing is this state store name. Dapper has plugins to over 30 databases. So let's take a look at what they look like. I'm just going to scroll up a bit here because they do have some. secret key information here that they don't necessarily want to show here. This is, for example, how you'd create a Azure Cosmos DB component in DAPR, right? So we have the URL, we have the master key. This is the schema that tells DAPR how to connect our underlying infrastructure. And for this one, we have DynamoDB, right? So we've got our access schema secret keys down there, and table, your own agents, that's a very unique name. And we're calling it state store and this is really all we need to do if we want to switch from Dynamo DB to Azure Cosmos DB. The only thing we need to do is switch out the ammo. Nothing in our code changes. Nothing inside the dapper check pointer changes. So if you're running in a multi-cloud operation, this becomes very, very good for you because you don't need to maintain multiple databases if you're running without agents. If you're just using the Dapr state APIs, you can extract really easily. And if you're using a land graph agents, well, you can use those databases where otherwise you'd have to fall back to the supported ones and get all of the extra Dapr features. So let's take a look at what this looks like. I've got Dapr running locally. There's a Dapr CLI, and I'm just going to do Dapr run. And before that, I'm actually going to go back into the UI here and I'm going to go into my AWS portal and just going to zoom in a little and refresh. And we can see that we don't have anything here in our table. I'm going to run this. This runs a land graph locally with Dapper. So we should have the prompt here. Oh, yeah, created the secret key. I hope no one took a photo of that. And we have the message, tell me something amazing about the brain. So we can see that this is done, the final conversation. It was running. This is great. And how do we make sure that our workflow is actually stateful? Well, we're going to go back here and refresh the thing. And now we can see that we've got two entries. I'm going to go into this. And we can see that LandGraph is now supported by DynamoDB. And we've got all of the necessary information for LandGraph, whether this is their own data structure that's saved here. They're going to be able to pick that off if the process crashed and just resume. Again, it's a very simple checkpointing method. It has lots of... issues but we are working on other upstream integrations okay so moving on let's go back into the code here and let's take a look at a different example and I'm gonna try and scroll this up again and just go here go to cosmos DB so I am taking this YAML file copy and pasting it and then just pasting it here And we are going to run this again. So our agent is going to execute. Yeah, I have a typo here. And let's run this. So now it's going to work again. Nothing in our code changed. We just switched a YAML file, the agent run to completion. But now if we're going to Azure and we're going to refresh this, they have the most confusing UI. Then we're going to see the exact same data structure just now saved into Azure Cosmos DB. This is one of the great things about Dapper. It integrates really well into different ecosystems, and you're going to be seeing this coming up with more and more agentic AI systems. As I said, we've got OpenAI coming up, AWS Trends, Microsoft Agent Framework, and a bunch of others, and there's going to be more integration with more Dapper APIs. So the event state store for you to be able to basically kick off events and or kick off agents based on events. and have them do the work and this is all going to be integrated in a very built-in way where we're going to essentially be hiding dapper from you so you will even have to know dapper the only thing you'll need to do is just import a dapper package write your agents the same way you do and dapper will make sure that all of the identity reliability and communication between those agents is handled for you by the dapper engine behind the scenes okay Now I'm gonna be going into our second part of the day and I'm just gonna scroll back here. And talk about a Dapper use case from JP Morgan Chase. So my co-presenter unfortunately had logistical problems coming here because of the disruptions. But JP Morgan Chase has been kind enough to allow me to speak on their behalf and show you their slides. So thank you, Raj. And JP Morgan Chase basically looked into Saga orchestration. So their problem was a problem that many financial services and companies find out you know you have a very complex payment process or a business process and you basically want to coordinate multiple transactions right you want to check for fraud you want to check balance accounts you want to check for validation and you're talking to different systems and they're hosted in different places and you want to basically make sure that the entire payment process is one atomic transaction this has been a very hard challenge to solve for a long time and we've had two phased commits and all of their downfalls so jpmorgan chase basically decided to evaluate multiple workflow engines And what they wanted to show is that there's a lot of modern distributed systems architectures, and they promise efficiency and scale, and there's lots of architectures out there that promise to solve these challenges. But at the end of the day, when you add more features, they add to more complexity. So they really wanted to take a workflow orchestration engine that allows them to solve those coordinated transactions, but without adding too much complexity into their system. And so what they wanted to check was, and this is a full list here, the most important things for them was to basically be able to kick off workflows, pause workflows, terminate workflows at will, be able to debug them, see everything that's going on inside of the workflow, have support for very granular retry policies and timeouts, be able to integrate from the workflows with things like Kafka because they're running Kafka at scale, signaling a workflow when to stop based on a Kafka event, canceling workflows. and many more and of course being able to run this in a self hosted way. So they have evaluated Dapper, they've evaluated temporal, orcas conductor, AWS step functions and Camunda. And you've got a brief description of what all of them do. By the way, I'm going to be uploading those slides into the CNCF session. So next week you'll be able to download all of that. I am conscious of time. So you know. A few of these workflow engines are managed cloud providers like AWS step functions. They are different from things like Dap, Rant and Perl because they call your code from the outside and they're tied to Lambda. Dap, Rant and Perl are mostly code first workflow engines. So this is their architecture and I realize this is a bit small but this is what we have. So they use Postgres DB and they run everything inside of their AWS VPC and they have a bunch of microservices where each one of those services contains business logic specific to their payments division workflow and they wanted to be able to coordinate all of those services that you see in the middle layer and at the bottom as a single transaction. um for their payments division um zeal specifically in the us if you know that one so the technical evaluation results for dapper they found that dapper was fault tolerant so that was the most important thing for them to check meaning they are running thousands of these transactions and if they're experiencing a shutdown let's say an aws regional shutdown that their workflows are going to retain state and pick up where they left off that was the most important thing the reliability of the underlying platform making sure that there is compensation compensating transaction. If a payment fails because of a third party system fails, they want to be able to trigger compensating transactions. This is really important to make sure that your workflow engine has that built in. They want to make sure that you can do rate limiting, provide the ability to view the state of the workflow, to see what inputs and outputs basically flow through it. and really be able to schedule workflows and test them and have a really strong correlation between what they see in prod and what they're seeing in their local machines and their integration tests. So yeah, before that, they chose Dapper as their preferred workflow engine. And I've been working with them seeing how they did their POC from end to end. And we highly believe that this workflow engine is applicable to a great many of use cases, not just payment providers and agents, but really to any type of application that consists of more than two steps. And you want to make those two steps reliable and stateful and fault tolerant and make sure that whatever failure happens whether it's a network outage full cluster outage or even a cloud provider outage that your system will be able to recover with a state that you're not going to have to replay right from the very beginning and having this foundational infrastructure is a very generic problem to pretty much any form of application and this is what we provide with dapper and what we're building into all of those ai agents So thank you to Raj who pointed this out and at this point I am done and I will take it for questions if there are any Thank you Yeah, yeah, he's getting your mic, but I'm gonna repeat the question in the meantime. So we didn't lose time So the gentleman here asked if we have agent to agent demos. Yes, we do. Let me show them to you So it actually everything lives inside of the upper agents So if you go to this repo here, we've got quick starts. And then you will have, and we've got lots of them, multi-agent workflows. This is running locally and multi-agent workflows Kubernetes. So this will show you exactly how DAPR does agent-to-agent communication securely and reliably across pods. Yes.

Don't miss out! Join us at our next Flagship Conference: KubeCon + CloudNativeCon events in Amsterdam, The Netherlands (23-26 March, 2026). Connect with our current graduated, incubating, and sandbox projects as the community gathers to further the education and advancement of cloud native computing. Learn more at https://kubecon.io

Dapr in 2026: Durable Execution and Resilient Eventing for AI Agents - Yaron Schneider, Diagrid & Rajesh Iyer, JPMC

In this maintainer track we'll cover existing and upcoming features that allow developers to more easily create complex workflow based applications, as well as Agentic AI systems. We will also showcase Dapr's role as an Application Developer Platform that is filling the gap required to govern and regulate access from applications to their underlying infrastructure and providing zero-trust security, agent-to-agent discovery and event ingestion to AI agent frameworks like LangGraph, CrewAI and others