Talk by Divakar Kumar (FlyersSoft) on integrating AI agents into an event-sourced payments and fraud system. Where rule-based engines and ML models leave ambiguous transactions (like unexplained card declines) unresolved, an agentic layer is added on top of the existing architecture rather than replacing it. Bounded contexts (transaction, device, account) provide the reasoning context; events flow through change feeds into projections and a semantic layer that agents read, communicating asynchronously via a message broker in a saga-style loop. Agents include a risk analyzer and a verdict agent, with safeguards against infinite loops and short memory, runnable serverless. Core takeaway: event sourcing already carries the state and history agents need, so layering agents onto existing events is a clean way to add judgment to production systems. # Channel Presentation Observations: "Let's integrate AI Agents in Event-Sourced Systems — Divakar Kumar, FlyersSoft" ## Video Format - **Conference talk**: The speaker opens with "finally we are at the last day of the conference" and closes with applause and an offer to "reach out to me offline or... on LinkedIn." - **Includes a live demo**: "I have prepared a POC... based on the synthetic data, so I will just show you like how this works" — a simulated multi-context fraud-detection pipeline, though the demo partially stalls ("I think it is just a database which is in the serverless mode... it is coming up slowly"). ## Intended Audience - **Backend/software architects and DDD practitioners**: The speaker assumes familiarity with concepts like **bounded contexts**, **saga orchestration**, **event sourcing**, **CDC/change feeds**, and **read models**: > "if you are from the DDD background or software engineering, like you would know that these are different bounded contexts." - **Engineers with existing legacy investment**: The talk targets teams whose businesses "invested over last few years" in various architectures, promising "at least few takeaways that you could apply in your work projects." ## Claimed Scope & Self-Description - **Stated topic**: "how to integrate AI agents in your existing system... an even [event] driven system or... any architecture." - **Positioning on AI agents**: The speaker argues agents are "not just for the chatbots or the coding assistance" — real value comes from applying them to **business workflows**. - **Practitioner, not theorist**: The speaker presents firsthand production experience ("we had this rule-based engine like 5 years before," "we started to tie up with a third-party provider... develop this ML model") from the real-time fraud detection domain. ## Demonstrated Patterns - **Concrete architecture walkthrough**: Detailed description of a tier-1 (rules/ML) + tier-2 (agentic) system with a **fan-out pattern** (risk analyzer agent + behavior analyzer agent + a third verdict agent), Cosmos DB event store, message broker, and a semantic/materialized-view projection layer. - **Named technical stack**: Cosmos DB, message broker, in-memory short-term memory (justified by a "sub 500 milliseconds" SLA), CDC change feeds. - **Personal anecdote as framing**: A story about a declined $3,500 laptop purchase and an unknowing customer-service agent opens the talk, framing the "gray zone" uncertainty problem. - **Honest limitations disclosure**: The speaker acknowledges AI agents are "non-deterministic by nature," warns about "avoiding this infinite loop," and admits false positives motivated moving from metrics to a third verdict agent. - **LinkedIn as contact channel**: The only explicit self-promotional channel mentioned is LinkedIn. ## Notes on Claims vs. Demonstration - Production-system claims (tiered architecture, third-party ML provider, bounded contexts) are **creator assertions** about FlyersSoft's internal systems; only the **synthetic-data POC** is demonstrated on screen, and even that demo is only partially completed in the transcript. # Delivery Observation: "Let's integrate AI Agents in Event-Sourced Systems" — Divakar Kumar, FlyersSoft ## Overall Tone and Register - **Conversational conference-talk style**: The speaker uses a relaxed, informal register throughout, marked by frequent **"like"** as a filler and connector: - > "So, I think like finally we are at the last day of the conference." - > "So, it's it costed me around like $3,500." - Heavy use of **"so"** to open sentences and transitions — it appears at the start of dozens of segments (e.g., "So, let me start with an example", "So, we had this rule-based engine", "So, what this orchestrator does is like..."). ## Vocabulary and Terminology - **Dense technical jargon**, delivered with the assumption of a practitioner audience: - Event-sourcing vocabulary: "domain events", "event store", "read models", "projection layer", "Cosmos DB", "change feed", "CDC", "bounded contexts", "saga orchestration" - AI vocabulary: "agentic AI", "SLM", "fan out pattern", "short-term memory", "semantic layer", "materialized view" - He occasionally **glosses terms for mixed audiences**: - > "CDC or in no sequel 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" - > "Because if you are from the DDD background or software engineering, like you would know that these are different bounded contexts" ## Recurring Phrases and Patterns - **"That is what / that is how"** as a summarizing connector: - > "And that is how like we define this orchestration layer." - > "So, this is how our saga flow continues" - **"So, this is how the high-level flow looks like"** — repeats a "high-level" framing device multiple times: - > "So, this is how the high-level flow looks like..." - > "And this is the high-level um architecture that we had." - Repeated **"we we"** and **"like like"** stutters suggest some nervousness or fast pacing, but are pervasive rather than situational. - Frequent **"you could"** / "you would"** second-person framing, addressing the audience directly as fellow engineers: - > "you could apply in your work projects" - > "you could either use a CDC mechanism or a message broker" ## Teaching Habits - **Opens with a personal anecdote** to ground the technical problem (the declined $3,500 laptop purchase and the customer-service call), then explicitly connects it to the design problem: - > "So, the those are the key areas, like those are the uncertain areas where we are trying to integrate the AI agents." - **Anticipates audience objections** rhetorically: - > "Now, you might be thinking like what a great idiot, right? Because it is already an uncertain case..." - **Signposting structure** with forward references: - > "So, what is it we are going to learn?" - > "But then our architecture, our domain is really complicated." - **Narrative history arc** as an explanatory device: rule-based engine (5 years ago) → third-party ML model → gray-zone problem → tier-two agentic layer. - **Live demo** near the end with admitted friction: - > "Um I think it is coming up slowly." - He recovers by verbally summarizing what the demo would show rather than abandoning it. ## Verbal Disfluencies - Sustained **repetition of words mid-sentence** ("it it it's going to be really difficult", "you can't you can't you can't say other teams"), and filler sounds ("uh", "um") that cluster in later segments — possibly fatigue or reliance on memory during the unscripted architecture walkthrough. - The demo portion shows the highest density of fillers, consistent with live improvisation. ## Uncertainty Notes - The talk is transcribed without an audience-audible Q&A; closing delivery is only briefly observable ("Yeah, that's it. If you have any questions..."), so **closing/pacing habits cannot be assessed**. - No slides or visuals are available, so observations about how verbal delivery coordinates with visuals are **not possible from this transcript alone**. - Word-repetition and filler patterns are clearly observable, but whether they stem from pacing, memory load, or live-demo stress is **not determinable from text alone**. # Position Extraction: "Let's Integrate AI Agents in Event-Sourced Systems" — Divakar Kumar, FlyersSoft ## Speaker - **Divakar Kumar (FlyersSoft)** is the sole speaker; all positions below are his. ## Core Thesis - AI agents deliver the most value when applied to **business workflows**, not just chatbots or coding assistants. - Agents can be integrated into existing architectures (event-sourced, event-driven, or otherwise) rather than replacing them. - The demonstrated problem space is **real-time fraud detection**. ## Motivating Example (Personal Anecdote) - A month before the talk, Kumar's ~$3,500 laptop purchase was declined twice; customer service could not explain why — the decision came from somewhere in a rule-based or ML-based engine. - His stated point: existing engines lack **real-time context** from across the domain, which is why such uncertain "gray zone" decisions occur. ## Acknowledged Tension - Kumar anticipates the objection that adding a **non-deterministic AI agent** to an already uncertain decision area seems unwise ("you might be thinking like what a great idiot"). - His rebuttal: the earlier engines lacked sufficient context and real-time data — agents, given cross-domain data, can produce better verdicts. ## Evolution of Their Fraud System (Stated History) 1. **Rule-based engine (~5 years prior)**: worked for some cases, but maintainability suffered because fraudsters constantly evolve and static rules require constant updates. 2. **ML-based approach**: partnered with a third party, shared transaction history/features, received a **risk code** to approve/block transactions. 3. **Limitation of both**: transactions below threshold approved, above blocked, but a minority fall into a **gray zone** where these systems cannot conclude. ## Proposed Architecture - **Two-tier design**: Tier 1 retains the existing rule-based/ML engines; Tier 2 is **agentic AI** handling only gray-zone cases. Kumar explicitly states the goal is *not* to exclude existing systems. ### Bounded Contexts (DDD) - **Transaction context**: merchants, amounts, transaction details; no customer/payment/device data. - **Accounts context**: KYC compliance, customer details. - **Device context**: device/browser fingerprints, OS. - **Payment context**: chargebacks, payment info. - Contexts do not share data directly; asynchronous microservice-style communication is required. ### Orchestration & Data Flow - An **orchestrator layer** (saga-style) routes all communication; an **agentic AI** sits inside it. - **Event sourcing** on **Cosmos DB** as the event store; commands appended as events (no state mutation). - **CDC / change feed** propagates events to read models (timelines, customer info, fraud/risk view), since the event store alone can't serve queries. - Events also flow through a **message broker** to a worker process feeding a **projection layer**, building a **semantic layer / materialized view** across all contexts. - Other teams are not required to follow event sourcing; the broker-based path accommodates them. ### Agent Design - Three components: **language model** (not necessarily an LLM — could be SLM/open-source), **tools**, **memory**. - **Short-term, in-memory memory only** — long-term memory would violate the **sub-500ms SLA** for transaction processing. - Agent loop: decompose task, use tools, check if goal reached; must have a **break-out metric** to avoid infinite loops (use-case dependent). ### Fan-Out Pattern (Tier 2) - Event fans out to two agents: **risk analyzer agent** (tools: fraud history from semantic layer, device trust layer, migrated business rules) and **behavior analyzer agent** (transaction pattern analysis via two plugins). - **Verdict layer**: Kumar notes that using only a metric or if-condition "is again going back to the same criteria" as the rule-based engine, which produced **false positives** they faced. So a **third agent** analyzes both agents' responses to reach the conclusion, which is emitted back to the message broker and continues the saga into the payment and transaction contexts. ## Demo (POC) - Based on **synthetic data**; shows contexts, projections, CDC into the semantic layer, and simulated events flowing through transaction, accounts, and payment contexts to the agent layer. - **Live failure noted**: the database (serverless mode) was slow to come up; the full two-agent-plus-verdict flow was described rather than fully shown. ## Generalization Claim - The approach works with **any event store** (relational or NoSQL); the key is building a semantic layer to give agents context, plus an agentic layer with verdict tool and short-term memory feeding the saga orchestration. # Video Attribution Record ## Video - **Title:** Let's integrate AI Agents in Event-Sourced Systems — Divakar Kumar, FlyersSoft - **Type:** Conference session (speaker notes it is "the last day of the conference") ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Divakar Kumar (FlyersSoft) | **Creator / Presenter** | Named in title; delivers full talk in first person, references "my personal experience" and a POC he prepared | No other identified speakers. Transcript contains no guest, narrator, or audience voices; ends with `[applause]` and a brief off-mic interjection `>> careful` from an unidentified party. ## Provenance Facts from Transcript ### Third-Party Claims / Company Claims - Personal anecdote (first-person, unverified): a ~$3,500 laptop purchase declined twice by fraud systems; customer service could not explain the block. - Company claims by presenter: - Fraud detection used a **rule-based engine ~5 years ago**, later an **ML model built with a third-party provider** using shared transaction history/features. - Production stack claims: **Cosmos DB** event store, event sourcing, CDC/change feed, message broker, projection/read models, short-term in-memory agent memory, sub-500ms SLA, fan-out multi-agent pattern with risk analyzer, behavior analyzer, and verdict agents. ### Referenced Sources / Technologies - Cosmos DB (event store), DDD bounded contexts, saga orchestration, CDC/change feed, Semantic AI agents (LLM/SLM), LinkedIn (contact channel) - No academic papers, external publications, or citations named. ### Demonstrations - **POC on synthetic data** shown live (demonstration partially stalled; presenter notes a serverless-mode database "coming up slowly"). Data explicitly labeled synthetic, not production. ## Promotional Segments - None detected. No product pitches, sponsor mentions, or calls to action beyond an invitation to reach out offline or via LinkedIn (contact, not promotion). ## Availability & Uncertainty - **Comments availability:** Not stated (no curated metadata supplied). - **Audience Q&A:** None in transcript; questions deferred to offline/LinkedIn. - Unverified claims: customer-service anecdote and internal architecture descriptions rest solely on the presenter's account. \>\> 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 few tea 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 even so system or it could be an even driven system or it could be any architecture that your business has invested over last few years, right? Because I always believe that these AI agents are more not just for the chatbots or the coding assistance, 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. 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 detection. So, let me start with an example. So, this is my personal experience. So, a exactly a month ago, I purchased uh like I decided to purchase this laptop that I'm using for the presentation. So, it's it costed me around like $3,500. So, I waited for a right moment. So, I was seeing like whether I have a nice offers and there was one moment. So, I decided to buy. I 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 I the third attempt, so I got a call from the customer service asking to verify like if I am doing that particular transaction. And I was like, yes, 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 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 have 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, the 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 a 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 domain context 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 come up with a verdict. So, the domain that we are going to talk about is the real-time fraud detection as I mentioned before. So, we had this rule-based engine like uh 5 years before. And this rule-based engine was perfectly fine like it was working perfectly fine for 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 tie up with a third-party provider like who helped us to develop this ML model. So we we have this ML base approach like where we shared with them transaction history or different features with them like based on that they trained the ML model and we were able to get a risk code based on that which with which like we were able to block or approve the transaction. But the problem with either of these approaches like either like 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 transaction. But majority of the transaction like few of the transaction like goes under the gray zone area and this is the area where it is really uncertain for those systems to really come to a conclusion whether it is an fraudulent transaction or a legitimate transaction. So what we are trying to do is like we we had built a system where we had both these tier one system which has this rule based or the traditional ML model and then we also had a tier two system which is agentic AI approach like most of the cases would be handled really well by these existing system we already had because our thought process is not to exclude the systems that we already had. We we are just trying to handle few of the areas like that is the gray zone areas with the help of agentic AI processing. So this is the approach like that we decided okay let's move on with this approach." But then our architecture, our 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 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 bounded context means, right? Because if you are from the DDD background or 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 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 complaining, whether the user is KYC compliant, or anything about the customer. Like, if you want to know about the customer, this would be the right context that we need to reach out to. And there is a device context. Like, we had stored all the device fingerprints, browser fingerprints, the OS that they are using 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 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 we we really we really don't have a way or means to share these data across different 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 a saga orchestration. So, all the communication would go through this layer and then it would be communicated to other services like who are interested in those events. And that is how like we define this 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, essentially like what happens is like when you have particular domain, you will be having different events that are emitted from that system. 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 lot of integration events. So, these are the events that comes from other contexts like payment contexts, device contexts, or account contexts. So, events like transaction rejected, payment approved, payment rejected would come from other systems to our transaction contexts. And these entire informations are stored in our NoSQL database. We are currently using Cosmos DB as our event store. And we are following event sourcing as our methodology to store the events. So, what happens is like whenever 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 once it arrives into the event store, so we have a kind of a mechanism called CDC or in no sequel 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 internal 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 in the indicators, the risk view. So, these are the different read model later layers that we had within our transaction context. And essentially like you can't you can't you can't say other teams to follow the same patterns because even 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 emitting those events into the message broker and those those events in turn will be processed by a worker process and then it will be reaching out to our projection layer. So, the idea is like we need to gather all the data 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 agent \>\> careful. \>\> 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 materials view. So, this this is the entire high-level picture of how you could gather those data and form a materials view. Now, coming to the agents. 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 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 meta methods that you define in inside your 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 you we are currently using in-memory for this. And essentially like what happens is like whenever there is an query comes into our language 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 certain 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 this depends uh this this is this might be varying. This might be differing for different use cases. For for our use case like we do have a metrics 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. 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 orchestrator. So, we segregated the tier one. Earlier like we just had the tier one. Now, we had the 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 agent AK processing. So, for this agent AK processing like we used fan out pattern. So, we kind of use multiple agents within this layer, and we are trying to use a fan out pattern like um once the uh event has been reached out to the uh tier two layer, we will be fanning out this um 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 an another region. 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, there are many false positive cases that we are 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 agents' responses and come 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 analysis agent, like what are the tools that we have in this an agent is that like we do have this 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 a business rules trying to migrate some of the rules that we had in the rule base engine over this tools and these are really specific to our business use case, so we are trying to move those into this tools. And we also have a be- behavior analysis 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 contexts? So, from the projection layer. So, these orchestration is going to consume these uh 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 counts, averages, average amounts that we had, the recent transactions, all gets into this semantic layer, and the device context is going to send all the details about the device trust score, location histories, and all other related information 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, whether the customer has been with us for the past few years. So, based on that, like it will try to validate the 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 payments that we 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 even source that you could use. And basically, like you could have a relational database or no SQL database. In turn, like you you need to just create the semantic layer for you to 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. So, based on the synthetic data, so I will just show you like how this works in in in Let me run this one. So, these are the different contexts that we have seen earlier. So, the transaction context, accounts, and device context. 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 simulating into the our systems. And you could see 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 the tier one processing, uh the ML processing. Let me see. I think it is just a 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 designed your business architecture. And going back to my presentation. Yeah, that's it. If you have any questions, like you can reach out to me offline or you can reach out to me on LinkedIn. Thank you. \>\> \[applause\]