AI agents can handle ambiguous fraud cases while rule-based and ML systems continue handling clear transactions.
2
Event-sourced systems provide the history and domain context agents need through projections and a semantic layer.
3
A fan-out of analysis agents followed by a verdict agent can return a decision through the existing saga and message-broker flow.
Summary
Divakar Kumar describes an agentic layer for real-time fraud detection that sits alongside an existing rule-based engine and ML model. Those systems approve or reject most transactions, but some fall into a gray zone because they lack enough current context to explain the decision. His design keeps the existing architecture and sends only those cases to agents. Transaction, account, device, and payment bounded contexts emit events into an event store, projections, and a semantic layer. Tools expose that materialized context to agents. A risk analyzer and behavior analyzer work in parallel, then a verdict agent evaluates their responses and emits an event back into the message broker. The saga orchestration continues the case through the payment and transaction contexts. Kumar also discusses short-term in-memory memory for a sub-500-millisecond transaction target and a metric that stops agent loops. The approach is practical, although the presentation does not report production accuracy or cost results.
Agents should handle the ambiguous cases that existing fraud systems cannot explain
Kumar frames agents as a way to add business workflow judgment to systems that companies already use. His example is a declined laptop purchase where customer service could not say why the card was blocked. A rule-based engine or ML model had probably used transaction history, a threshold, or another score, but the decision was not understandable to the customer. Rule-based checks had become hard to maintain because fraudsters kept finding new ways into the system. The ML model handled most transactions, while cases near the approval or rejection boundary remained uncertain. Kumar sends those gray-zone cases to a second, agentic tier instead of replacing the first tier.
Bounded contexts keep transaction, account, device, and payment data separate
The transaction context owns merchants, amounts, and other transaction details. It does not own customer, payment, or device information. The account context contains customer details and KYC status. The device context contains device fingerprints, browser fingerprints, operating systems, and related fraud signals. The payment context contains chargebacks and other payment information. These contexts do not share data directly. Communication happens asynchronously, through an orchestration layer and a message broker, following a saga-style pattern. The agent layer is added inside that orchestration layer so it can coordinate information from the separate contexts.
Event sourcing turns domain events into the history and read models agents can use
The transaction context emits events such as transaction created, while other contexts contribute integration events such as payment approved or payment rejected. Kumar says the system stores these events in Cosmos DB as an event store and appends business facts instead of mutating state. A CDC mechanism, called a change feed in NoSQL systems, propagates changes into read models. Separate read models support timelines, customer information, and fraud indicators or risk views. Events also go through a message broker to a worker process, which transforms them before storing them in a materialized view. That semantic layer gathers data from the bounded contexts for agent tools.
The semantic layer gives agents denormalized context without changing every team's storage approach
Kumar says teams cannot be expected to adopt event sourcing just because one part of the system uses it. The architecture therefore emits events to a broker, processes them in a worker, and builds a materialized view that agents can query. The transaction data includes counts, average amounts, and recent transactions. Device data includes trust scores, location history, IP addresses, and related location information. Account data includes account status, KYC status, and account age. Payment data adds recent payment information. These projections become the source for tools that agents call while analyzing a case.
Short-term memory and explicit stop conditions keep the agent path inside transaction limits
Kumar describes an agent as a combination of a language model, tools, and memory. The model can be a large language model, a small language model, or an open-source model. Tools call external APIs or application methods. For this transaction use case, the design uses short-term, in-memory memory because the stated service-level target is sub-500 milliseconds. The agent decomposes a request, uses tools, and checks whether it has reached its goal. That reasoning can loop, so the system needs a metric that breaks the loop after a defined point. Kumar says the stopping rule will vary by use case and requires care.
Parallel analysis agents feed a separate verdict step
The orchestration layer separates the existing tier one processing from the new tier two agentic processing. Kumar uses a fan-out pattern in tier two. A risk analysis agent reads fraud history, device trust data, and selected business rules exposed as tools. A behavior analysis agent examines transaction patterns through two plugins. Their responses are sent to a verdict stage. Kumar says a simple metric or if condition can reproduce the same threshold behavior and create false positives, so the design adds a third agent to assess both responses and reach the final conclusion. The result is published as an event to the message broker.
The final verdict returns to the existing saga flow as an event
After the verdict agent decides, the result is emitted back to the message broker. Interested contexts subscribe to that event. The saga continues into the payment context, where the payment can be approved, and then returns to the transaction context. The orchestration layer manages the full loop. The proof of concept uses synthetic data and simulates events moving through transaction, account, device, payment, projection, and semantic layers. Kumar describes two analysis agents producing separate conclusions, followed by a third agent that makes the final decision. The architecture can use a relational or NoSQL event source as long as it builds a semantic layer for the agents.
"The real value that you could bring out of these AI agents is like when you start to apply these into your business workflows."00:57
Who should watch
You have a rule-based or ML fraud pipeline that handles normal cases but leaves borderline decisions hard to explain.
Your system already emits domain events and you want to add agent reasoning without replacing its bounded contexts.
You need to design multi-agent processing under a strict latency target and want a concrete pattern for memory and loop limits.
