# Let's integrate AI Agents in Event-Sourced Systems — Divakar Kumar, FlyersSoft AI Engineer · 2026-07-30 Divakar Kumar explains how to layer AI agents onto event-sourced systems to resolve ambiguous fraud cases that rule-based engines and ML models cannot score. In his architecture, bounded contexts (transaction, device, account) feed events through change feeds into a semantic layer that agents read asynchronously via a message broker in a saga-style loop. A risk analyzer agent and a behavior analyzer agent fan out, each using tools to query the semantic layer, then a third verdict agent synthesizes their outputs to decide whether to approve or block a transaction. Kumar emphasizes keeping memory short and guarding against infinite loops to meet sub-500ms SLAs. The key takeaway: event sourcing already carries the state and history an agent needs, so the cleanest way to add judgment is to layer agents onto the events you already emit. ## Questions this episode answers ### How do you integrate AI agents into an existing event-sourced system for fraud detection? Divakar Kumar describes layering an agentic system on top of existing bounded contexts (transaction, device, account) using event sourcing. Domain events flow via change feeds into projections and a semantic layer that agents read. Agents communicate asynchronously through a message broker in a saga loop, with a risk analyzer and verdict agent handling ambiguous cases that rule-based and ML systems can't resolve. [5:43](https://aiengineer.podhood.com/a001abc6-60c6-4bd8-afdc-63bee6ff8864?t=343000) ### How do you give AI agents context from multiple microservices in a fraud system? Divakar Kumar's architecture uses event sourcing with change feeds (CDC) to propagate events from bounded contexts like transaction, device, and account into projections. A worker process then builds a semantic layer, a materialized view that agents query via tools. This collects real-time data from multiple contexts without direct coupling, enabling agents to reason over a unified view of fraud indicators. [10:44](https://aiengineer.podhood.com/a001abc6-60c6-4bd8-afdc-63bee6ff8864?t=644000) ### How do you manage latency and infinite loops when using AI agents for real-time fraud decisions? For real-time processing with a sub-500-millisecond SLA, the system uses in-memory short-term memory rather than long-term storage. To avoid infinite loops, the agentic framework includes a predefined break-out matrix: if the agent reaches a certain threshold of iterations without a verdict, it exits the loop. This design ensures fast, bounded decision-making for transaction approval or rejection. [12:10](https://aiengineer.podhood.com/a001abc6-60c6-4bd8-afdc-63bee6ff8864?t=730000) ### What are the key agents in Divakar Kumar's fraud detection agentic layer? The agentic layer uses a fan-out pattern with two agents: a risk analyzer (accessing fraud histories, device trust data, and migrated business rules) and a behavior analyzer (examining transaction patterns). A third verdict agent synthesizes their outputs to reach a final decision, which is emitted as an event. This multi-agent approach reduces false positives compared to static rules or ML alone. [14:13](https://aiengineer.podhood.com/a001abc6-60c6-4bd8-afdc-63bee6ff8864?t=853000) ## Key moments - **[0:00] Introduction** - **[1:07] Declined Card** - [1:20] Divakar Kumar's $3,500 laptop purchase was declined and customer service couldn't explain why. - [2:51] Real-time context from multiple bounded contexts enables AI agents to resolve fraud gray zones. - **[3:09] Rule & ML Limits** - **[5:08] Gray Zone** - [5:24] Agentic AI targets only the gray zone of ambiguous fraud transactions, not replacing existing rule/ML systems. - **[5:43] Bounded Contexts** - [5:58] Divakar Kumar's fraud system decomposes into bounded contexts: transaction, device, account, payment. - **[8:18] Event Sourcing** - [8:24] Event sourcing with Cosmos DB captures domain events as append-only facts, enabling change feed propagation. - **[10:44] Semantic Layer** - [10:57] A semantic layer materialized from cross-context events feeds real-time context to AI agents. - **[11:43] Agent Design** - [13:16] Agent loops must include a break-out matrix to prevent infinite execution in fraud processing. - **[13:40] Orchestration** - [14:07] Fan-out AI agent pattern: risk analyzer and behavior analyzer feed a verdict agent to reduce false positives. - [15:24] Saga orchestration coordinates AI agents, payment approval, and transaction context via asynchronous messaging. - **[19:00] Live Demo** - [19:00] Any event-sourced system can support AI agents by adding a semantic layer for context. ## Speakers - **Divakar Kumar** (guest) ## Topics Multi-Agent Orchestration, Agent Memory ## Mentioned Cosmos DB (product) ## Transcript ### Introduction **Divakar Kumar** [0:13] Hello everyone, thanks for joining. So, I think—like—finally we are at the last day of the conference. Personally, I had a great experience, learned a lot of new things, so I believe by the end of the session you would have at least a few key takeaways that you could apply in your work projects. So what is it we are going to learn? So we are going to learn how to integrate AI agents in your existing system. So this system, it could be an event source system, or it could be an event-driven system, or it could be any architecture that your business has invested over the last few years,right? Because I always believe that these AI agents are not just for the chatbots or the coding assistants,right? So the real value that you could bring out of these AI agents is, like, when you start to apply these into your business workflows. ### Declined Card **Divakar Kumar** [1:07] And that is what we are going to learn. And the problem space that we are going to work on today is the real-time fraud reduction. So let me start with an example. So this is my personal experience. So, uh, exactly a month ago I purchased, uh, like, I decided to purchase this laptop that I'm using for the presentation. So it cost me around, like, $3,500. So I waited for aright moment. So I was seeing, like, whether I have a nice offer. And there was one moment. So I decided to buy. I pro- provided my card details, and then I clicked on buy button. Then my transaction got declined. So I thought, like, it was a network issue and some information has been misplaced. So I tried the second attempt, and it was failed again. Before I tried the third attempt, I got a call from the customer service asking to verify, like, if I'm doing that particular transaction. And I was like, yes, I, I was trying to do this for the past few minutes. And I asked them, like, why did you block my transaction? Do you know what the response was? They didn't know. Because I wouldn't blame them, because they didn't know, like, why it was blocked. It was somewhere in the system. Either the rule-based engine or the ML-based engine would have taken that decision. So it would have looked through my transaction history, or it would have had an average threshold beyond which, like, if it goes, like, just block the transaction. That would be the static rule that it would have had, because of which my transaction got declined. So those are the key areas. Like, those are the uncertain areas where we are trying to integrate the AI agents. Now, you might be thinking, like, what a great idiot,right? Because it is already an uncertain case. Like, why do you want to introduce an AI agent? Because it is also non-deterministic by nature,right? But the key point here that we are all trying to miss is that earlier in the rule-based engine or the ML-based engine, like, we don't have enough context. We don't have enough real-time data that gets passed on to the system. And those are the real data, like, that we are trying to capture from different bounded contexts that we have in our domain. And we are going to see, like, how we could build that architecture so that the AI agent can make use of it and, uh, come up with a verdict. ### Rule & ML Limits **Divakar Kumar** [3:31] So the domain that we are going to, uh, talk about is the real-time fraud reduction, as I mentioned before. So we had this rule-based engine, like, um, five years before. And this rule-based engine was perfectly fine. Like, it was working perfectly fine for a few of the cases. And, but, but the problem with this rule-based engine is, like, the maintainability. Because the fraudsters are trying to get intruded into a system, like, by a lot of different ways. And you just need to keep on updating these static rules day by day. And it, it, it's going to be really difficult for you to manage. And that's when, like, we started to, um, tie up with a third-party provider, like, who helped us to, uh, develop this ML model. So we, we have this, uh, ML-based approach, like, where, uh, we shared with them a transaction history or, uh, different features with them. Like, based on that, they trained the ML model. And we were able to get a risk score based on that, which, with which, like, we were, uh, able to block or approve the transaction. But the problem with either of these approaches, like, either, um, like, we, we, we were able to handle most of the transaction because it would fall below a certain threshold. Then we would approve the transaction. And if it goes beyond a certain threshold, we would be blocking those transactions. But the majority of the transaction, like, few of the transactions, like, go under the gray zone area. And this is the area where it is really uncertain for those systems to really, um, come to a conclusion whether it is an, um, fraudulent transaction or a legitimate transaction. So what we are trying to do is, like, we, we had, uh, built a system where we had both these tier-one systems, which has this rule-based or the traditional ML model. And then we also had a tier-two system, which is agentic AI approach. ### Gray Zone **Divakar Kumar** [5:24] Like, um, most of the cases would be handled re- really well by these existing systems we already had. Because our thought process is not to exclude the systems that we already had. We, we are just trying to handle a few of the areas, like, that is, the gray zone areas, with the help of agentic AI processing. ### Bounded Contexts **Divakar Kumar** [5:43] So this is the approach, like, that we decided, okay, let's move on with this approach. But then our architecture, our, um, um, domain is really complicated. So this is our different bounded contexts that we have internally in our domain. So the transaction context holds all the details about your transactions. Like, it knows about the merchants. It knows about the amounts that, um, that you transact. And everything related to a transaction would be residing on this particular context. And it doesn't have any information about the customer it is handling, or it doesn't have any information about the payments or the device details. That is what the con, uh, bounded context means,right? Because if you are from the DDD background or, um, uh, software engineering, like, you would know that these are different bounded contexts. Like, with, like, you wouldn't share the data among themselves. Like, you need to do an asynchronous way of communication. And the, um, like, all sort of things, like, that you would do in a microservice communication would necessarily be done here as well. So then we do have accounts context. All the details about the accounts, like the KYC compliant, whether the user is KYC compliant, or anything about the customer. Like, if you want to know about the customer, this would be theright context that we need to reach out to. And there is a device context. Like, we had stored, uh, all the device fingerprints, browser fingerprints, uh, the OS that they are using, um, over these device contexts. Like, that would be really helpful, like, for detecting these kinds of real-time frauds. And finally, like, we had payment context. So any sort of chargebacks or, um, uh, anything related to the payments will be residing on this particular context. So now the problem that we have with this kind of an architecture is, like, uh, we, we really, we really don't have a way or means to share these, uh, con, uh, datas across different, um, uh, bounded contexts,right? So that's where, like, we started to introduce an orchestrator layer. So earlier, like, we had this orchestrator layer. But now we also have an agentic AI inside this orchestrator. So what this orchestrator does is, like, similar to, um, a saga orchestration. So all the communication would go through this layer. And then it would be, um, communicated to other services, like, who are interested in those events. And that is how, like, we define this, uh, orchestration layer. And we also have an asynchronous way of communicating with, within other different contexts, like, through a message broker. If I zoom in a little bit on the transaction context, you could see what, what are the details that these transactions are holding. So, um, essentially, like, what happens is, like, when you have a, a particular do- domain, you will be having different events that are emitted from that system. ### Event Sourcing **Divakar Kumar** [8:35] So those are really called as domain events. And within our transaction context, like, we do have transaction-created domain event, which is the start of entire transaction. And we do have a lot of integration events. So these are the events that come from other contexts, like, payment context, uh, device context, or account context. So events like transaction rejected, payment approved, payment rejected would come from other systems to our, um, transaction context. And these entire informations are stored in our NoSQL database. Uh, we are currently using Cosmos DB as our event store. And we are following event sourcing as our methodology, uh, to store the events. So what happens is, like, whenever, uh, user initiate a command, so that goes into our event store as an event, as a business fact. So we are not mutating the state. But instead, like, we are appending all the events as when it arrives. And what it really helped us to do is, like, uh, once it arrives into the event store, so, so we have a kind of a mechanism called CDC. Or in NoSQL word, this is called as a change feed, with which, like, whenever there is a change or update happens over a table, so you will be getting notified. And those changes could be propagated into different read models. So because in, in, in a real scenario, like, you won't be able to rely entirely upon the event store for the query operation, for the read operation. What you would do is, like, in turn, like, you will be having different read models, which are optimized for the read operations. So what we really had is, like, we had multiple read models. So one for timelines, one for customer information, and one for the fraud ind- indicators, the risk view. So these are the different, uh, read model layers that we had within our transaction context. And essentially, like, you can't, um, you can't, you can't say other teams to follow the same patterns. Because event sourcing is not the one that other teams are also following. So what we did is, like, we also had this asynchronous way of communication by, uh, emitting those events into the message broker. And those, uh, those events, in turn, will be processed by a worker process. And then it will be reaching out to your projection layer. So the idea is, like, we need to gather all the datas from all these different contexts and to have or build a semantic layer, or you could call it as a materialized view, which you could further use within your agentic AI flow. ### Semantic Layer **Divakar Kumar** [11:10] So this is how the high-level flow looks like. Like, we have all these different contexts. And you could either use a CDC mechanism or a message broker to propagate those events into your projection layer. And essentially, like, you will be having this intermediate layer, like, which is a worker process. You need to massage your message events and then process it and then store them in the materialized view. So this, this is the entire high-level picture of how you could gather those datas and form a materialized view. Now, coming to the agents. ### Agent Design **Divakar Kumar** [11:43] So, so we all know, like, agents are comprised of these three main components: the language models, the tools, and the memories,right? So this language model, it, it is not necessary to be a la-large language model. It could be a SLM. It could be an open-source model. And the tools are by which, like, you could interact with the external APIs or the methods, the methods that you define in, inside your, uh, application layer. And you also need to have a memory layer. For this particular use case, like, we are using an inch, um, short memory. Because, uh, you, you can't really, um, rely on the long-term memory. Because you need to, um, adhere to the, uh, SLA that you, uh, provided to the customers. Because for, for the transaction, uh, to be processed, like, it should be sub-500 milliseconds. And we, we are currently using in-memory for this. And essentially, like, what happens is, like, whenever there is an query comes in to our logging edge model. So it has this reasoning capability, the thinking capability, with which, like, it tries to decompose the task into multiple chunks. And each of these tasks, in turn, will, uh, go into the language model, do cer-certain processing with the help of the tools. And it will see, like, if the end goal is reached. And if it is not reached, like, it will try to go on in this loop. So this is what essentially happens inside the, uh, agentic framework. But you should really know, like, when to stop this loop. Uh, because, uh, this difference, uh, this, this, this might be varying. This might be differing for different use cases. For, for our use case, like, we do have a matrix with beyond which, like, if we go, like, we, we could break out of this loop. And this could be varying for different use cases. So you should be really careful on avoiding this infinite loop. And now, coming back to our, uh, existing architecture. So what we did is, like, earlier, like, we learned about the transaction aggregate. ### Orchestration **Divakar Kumar** [13:40] So now we are emitting some events that gets translated into an integration event, which gets passed on to the message broker. And then it, it is handled under the orchestration layer. So under this orchestration layer, like, we have different sub-orchestrators. So we segregated the tier one. Earlier, like, we just had the tier one. Now we had this tier one layer, which is handling the, um, rule-based engine or the ML-based engine. And we also had now the tier two layer, which is going to be agentic AI processing. So for this agentic AI processing, like, we used fan-out pattern. So we kind of used multiple agents within this layer. And we are trying to use a fan-out pattern. Like, uh, once the, uh, event has been reached out to the, uh, tier two layer, we will be fanning out this, uh, event to two different agents. One is the risk analyzer agent. The other one is the behavior analyzer agent. And once these agents, like, come to a conclusion based on the different tools that it has, it will finally send the response to the verdict. And this verdict could be a metric. It could be just an if condition inside your application layer. Or it could be another agent. Because what we seen is, like, if we are using just the metrics, it is again going back to the same criteria, like, where we had this rule-based, um, mechanism. Uh, so, uh, there are many false positive cases that we are, uh, that we faced. So, so we, we in turn, like, we are trying to use a third agent in this verdict layer, which analyzes both the agent's responses and comes to a conclusion, which is then going to be emitted as an event back to this message broker. So this is how our saga flow continues. And it gets into the payment context. And then the payments are approved. And then it is going back to the transaction context. This entire loop is being done within our orchestration layer. And this, this is what I was talking about, two agents that we had in this tier two. So one is the risk analyst agent. Like, what are the tools that we have in this agent is that, like, we do have this, uh, kind of, uh, storing the fraud histories inside the semantic layer that we earlier see. And we are currently having a tool for that. Like, um, it will just get those details from these projections layer. And we also have a device trust layer. Like, all the device information will get stored into this semantic layer. And it will just get those chunks alone. And we also had, um, business rules trying to migrate some of the rules that we had in the rule-based engine over these tools. And these are really specific to our business use case. So we are trying to move those into these tools. And we also have a be-behavior analyst tool. So, so there, like, we are analyzing the transaction patterns with two different plugins that we have. So based on these two different agents, the responses, like, we get to a final consensus. And then that will be published as an event, which will be captured by the message broker. And this will be listened or, uh, this will be subscribed by all the different contexts which are interested in those events. Now, as, as, as we seen earlier, like, how does these, um, agents gather context? So from the projection layer. So these orchestration layer is going to consume these, um, datas from the projection layers. And how it is going to do is by the help of tools that it already has. So the transaction context, it is going to denormalize some of the cones, averages, average amounts that we had, the recent transactions, all gets into this, um, semantic layer. And the device context is going to send all the details about the device trust score, location histories, and all other, um, related information, um, about the locations, IP addresses to this semantic layer. And the account context is going to send the statuses of the accounts, the KYC status, account age, um, whether the customer has been, uh, with us for the past few years. Uh, so based on that, like, uh, it will try to validate the, uh, leg, um, uh, the, the customer based on those informations. And there is also the payment context from this. Like, we get to know about the recent, uh, payments that we, um, gathered over these contexts into the semantic layer. And, and as I, as I said earlier, so these tools get, uh, access to these projection layer, and which in turn will be used by these agents to come to a conclusion. And this is the high-level, um, architecture that we had. So it could be any event source that you could use. And basically, like, you could have a relational database or NoSQL database. In turn, like, you, you need to just create the semantic layer for you to, uh, provide enough context to these AI agents. And we do have this agentic layer in the orchestration. So we have this verdict tool and then the short-term memory. And based on that, like, whatever the result that we get gets on passed to the saga orchestration layer. So we, I, I, I have prepared a POC, uh, so based on the synthetic data. So I will just show you, like, how this works, uh, in, in, in let me run this one. ### Live Demo **Divakar Kumar** [19:18] So these are the different contexts that we have seen earlier. So transaction contexts, accounts, and device contexts. So from these, like, we will get into the projections layer. And we will be having a CDC mechanism with which, like, you will be able to progress, propagate those events back to your semantic layer, which will get in turn used by these AI agents. So here you could see, so there are multiple simulation events that we are, um, simulating into our systems. And you could see a bunch of events are currently populating. So these, um, events are propagating through different layers, the transaction layer, accounts, and then payments context. And finally, like, we also have this, uh, AI agent layer, like, which, which is going to try with, uh, tier one processing, uh, the ML processing. Let me see. I think it is just the database, which is in the serverless mode. Um, I think it is coming up slowly. So, but, but yeah, the idea is, like, you will be able to see, like, two different agents coming up with two different, uh, conclusions. And you will be having a third agent, which will take the final decision. Uh, that will be in turn emitted as an event back to your message broker. And this saga flow will be continuing as for, uh, like, how you design your business architecture. And going back to my presentation. Yeah, that's it. Uh, if you have any questions, like, you can reach out to me, uh, offline, or you can reach out to me on LinkedIn. Thank you. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.