Verdict: Bolting an LLM onto your event store is the fastest way to wreck an event-sourced system. AI agents in event-sourced systems earn their keep only when you treat them as a tier-two layer that exclusively handles the gray-zone cases a deterministic rules engine or ML model already misses — and only when you feed them a semantic layer (a per-decision materialized view) that you rebuild from the event log. With the fan-out → verdict pattern, an in-memory short-term memory, and a saga contract that re-emits the agent's decision as an event (never as an action), you can add autonomy without forking your source of truth or sacrificing a sub-500ms SLA. This is the 4-layer pattern production teams are converging on in 2026.
Last verified: 2026-07-31 · Tier-two agents handle only the gray zone · Semantic layer = per-decision materialized view · Sub-500ms SLA → in-memory short-term memory, no long-term recall on the request path · Verdict is always re-emitted as an event, never executed inline · Volatile facts: fraud-detection SLAs and Cosmos DB throughput limits change with provider updates — re-check quarterly.
What does "AI agents in event-sourced systems" actually mean?
It means an autonomous LLM- or SLM-driven agent that consumes events from an append-only log (the event store), reasons over a per-decision projection of those events, calls tools to enrich its context, and re-emits its decision as a new event on the bus — instead of mutating state directly. The event store remains the single source of truth; the agent becomes one more event producer-consumer in your saga. Nothing in the agent's architecture gives it license to bypass the event sourcing discipline your system already enforces.
This is distinct from two adjacent things teams confuse it with. It is not "give the chatbot access to the database" (that mutates state and breaks replay). It is not "wrap an ML model in an event handler" (ML models return a score; agents return a reasoned verdict grounded in cross-context tools). The agent's output is a business event — TransactionFlagged, PaymentHeld, AccountEscalated — that downstream aggregates consume exactly like any other integration event.
Why you do not let the agent handle every transaction
The single most common mistake teams make is routing every event at the agent. It is wrong on three counts, and the fraud-detection domain makes all three measurable.
1. Latency. Real-time payment rails (FedNow, Faster Payments, UPI, PIX) settle in under 10 seconds, and a fraud-decisioning system typically has to return an approve-or-decline verdict within roughly 100–200 milliseconds of receiving the transaction(DreamzTech, 2026). A multi-round LLM agent that reasons, calls tools, and runs a fan-out debate will miss that window on any meaningful share of traffic.
2. False-positive load. Rule-based transaction-monitoring systems in banking already generate false-positive rates above 90%, and in some cases above 98%, according to McKinsey(McKinsey, "The new frontier in anti–money laundering"). The fix is fewer, smarter verdicts, not "ask the LLM everything."
3. Cost and audit. Every agent invocation costs tokens and produces a reasoning trace. Routing every transaction at the agent burns budget on the ~95% of cases a tier-one rule or ML engine already resolves correctly. You also manufacture audit noise: regulators want to see exactly when a non-deterministic system touched a transaction, and "always" is the worst possible answer.
The right division of labor is two tiers:
| Layer | What handles it | Why | Typical SLA |
|---|---|---|---|
| Tier one — deterministic | Rules engine, traditional ML risk-score model | High-volume, well-understood patterns; cheap; explainable by construction | < 50 ms |
| Tier two — agentic | LLM/SLM agents with tools, fan-out + verdict | Ambiguous "gray zone" cases that fall between the approve and decline thresholds | 100–500 ms |
| Verdict emission | Saga orchestrator re-emits agent decision as a domain/integration event | Keeps the agent out of state mutation; preserves replay & auditability | < 10 ms |
The tier-two agent is invoked only when tier one returns a score inside the gray band. Everything else never touches a language model.
How do you feed context to an agent that lives in a bounded-context world?
Event-sourced systems almost always grow up inside a DDD-style bounded-context architecture — a concept Eric Evans introduced in Domain-Driven Design (2003) and one that remains the default mental model for microservices(InfoQ, 2019). In a payments stack you typically see four contexts that must not share a database: Transaction (amounts, merchants), Account (KYC status, customer tenure), Device (browser/OS fingerprints, IP history), and Payment (chargebacks, settlement). None of these contexts can lawfully read another's tables — they communicate via async events on a broker.
The agent needs all four of those views to make a reasoned verdict. The trap — and the single architectural decision this whole pattern hinges on — is where that combined view lives.
The semantic layer: a per-decision materialized view
You build a semantic layer in front of the agent. It is a subscription-based, projection-style materialized view that subscribes to the events from every bounded context via change-data-capture or a message broker, applies a worker that shapes those events for the agent, and writes the result to a denormalized store optimized for the agent's query pattern. The Materialized View pattern is never updated directly by an application — it is a specialized cache that regenerates from the event log, which is exactly the discipline you want here.
For each transaction event that lands in the gray zone, the agent's tools read only the relevant slices from this semantic layer:
- From Transaction: average ticket size, velocity over 5 min, recent merchant codes
- From Device: device-trust score, location history, IP reputation
- From Account: KYC status, account age, prior dispute rate
- From Payment: recent chargebacks and settlement failures
Cosmos DB is a popular backing store precisely because its change feed is purpose-built for this — every write to the container is a durable event, you can read from the beginning of the feed to replay all history, and multiple consumers can subscribe independently to project different read models(Microsoft Learn, "Change Feed Design Patterns"; Azure Cosmos DB blog, "Event Sourcing pattern"). You are not locked into Cosmos — a relational events table plus a streaming CDC connector works the same way — but the change feed abstracts the hardest part (durable, ordered, replayable) for you.
The critical rule: projections are disposable
A projection is derived state, not a second source of truth. If it has a bug, you fix the projection code, delete the read model, and replay the events from the beginning. Software Patterns Lexicon calls this the "disposable and rebuildable" property and it is non-negotiable for an audit-friendly fraud pipeline(Software Patterns Lexicon, "Projections and Materialized Views"). The agent reads the semantic layer for context; the event store remains the only authoritative state. Never let a tool write to the semantic layer; tools are pure consumers, and any business effect should go through a saga or process manager.
What are the 4 layers you actually build?
Here is the pattern, end to end. Each layer has a job, a contract, and a failure mode you should be able to name before you deploy.
Layer 1 — Event store + bounded contexts (unchanged)
Your existing event-sourced aggregates keep emitting domain events (TransactionCreated, PaymentApproved, DeviceFingerprintUpdated) to the event store and integration events to the message broker. Nothing about this layer changes when you add agents. This is the point: the agent is additive, not a rewrite.
Layer 2 — Semantic layer (projection workers + materialized view)
A worker process subscribes to the relevant event streams from every bounded context, shapes the events into agent-readable documents (denormalized counts, recent-item arrays, trust scores), and writes them to a separate read-optimized store. It is a classic CQRS read model — you can build several of these (a "timeline" view, a "risk indicators" view, a "device history" view) and have the agent's tools fan out across them.
Failure mode to design for: projection lag. The semantic layer is eventually consistent, so a query may briefly see state one event behind. Monitor the lag explicitly and design the agent to treat inputs as "best-known," not authoritative.
Layer 3 — Agentic tier (fan-out + verdict)
When tier one (rules/ML) returns a score in the gray zone, the saga orchestrator fans the event out to a small panel of specialized agents. Production systems converge on two reasoning agents + one verdict agent:
- Risk analyzer agent — tools:
get_fraud_history,get_device_trust. Reads the semantic-layer slices relevant to risk. - Behavior analyzer agent — tools:
get_velocity,get_pattern_deviation. Reads different slices the first agent does not need. - Verdict agent — a third agent that reads both agents' outputs and returns a final decision rather than a simple metric-based threshold. Why a third agent and not an
ifstatement? Because anifcollapses the agent tier back into a rule, re-importing the false-positive problem you were trying to escape; the verdict agent can weigh disagreement, just like a constitutional-review multi-agent pattern.
The fan-out (scatter-gather) and the debate-and-consensus patterns are the two most-cited 2026 production shapes for exactly this kind of high-stakes decision(Atlan, "Event-Driven Architecture for AI Agents"; AgentMarketCap, "Multi-Agent Debate and Consensus Architecture 2026"). The honest caveat: naive multi-agent debate does not always beat a well-designed single agent on factual recall, and agents sharing the same base model can correlate their errors. Use different models or different system prompts across the two reasoning agents to get genuine reasoning diversity.
Layer 4 — Saga orchestration (verdict back to events)
The verdict agent's output is not executed against any system. The saga orchestrator receives it and re-emits it as a domain event: TransactionFlagged, PaymentHeldForReview, AccountEscalatedToAnalyst. Downstream contexts (Payment, Account, Transaction) subscribe to that event and react — exactly the Saga orchestration pattern Microsoft's Azure Architecture Center documents for "a sequence of local transactions … if a step fails, the saga runs compensating transactions to undo the preceding changes"(Azure Architecture Center).
This is the second non-negotiable rule of the pattern, and it is the one most teams break: the agent emits an event; the saga executes work. If the agent ever writes to the database, calls a payment API, or holds the transaction inline, you have lost replay safety, auditability, and the entire reason event sourcing exists.
How do you stop the agent from looping forever?
An agent is a reasoning loop: query → tool call → reason → check goal → repeat. Without a break condition this loop is unbounded, and an unbounded loop inside a 500ms fraud SLA is a production incident waiting to happen.
Three concrete break conditions, picked deliberately:
- A step-count metric. Cap total agentic iterations (for example: ≤ 3 tool round-trips per agent). Beyond the cap, fall back to the safe default (decline + human review).
- A wall-clock budget. Sum the latency across the reasoning agents and the verdict agent. If the budget is exhausted (typical floor: 250–350 ms of the 500 ms SLA, leaving room for saga + emission), break early with the conservative verdict, not the most-recent verdict.
- A confidence gate. The verdict agent declares its own confidence; below a threshold (configurable per business segment) the event emitted is
TransactionEscalatedToHuman, not a hard decline.
The safe fallback of every break condition is always the conservative business action (hold + human review), never an approve. An infinite fast-forwards into approval is the catastrophic failure; an infinite loop that terminates into review is just slightly expensive.
Why short-term memory, not long-term memory, on the request path
The agent framework has three classic components — language model, tools, memory. For a sub-500ms real-time decision, long-term memory (vector recall over prior cases) is usually wrong on the request path because the retrieval cost eats your latency budget and the recall can introduce stale patterns. Use in-memory short-term memory: just enough scratch space to carry context across the few tool round-trips inside this single verdict. Persist any teachable signal (a confirmed fraud pattern the agent spotted) as a separate downstream process — never inline with the transaction it is currently deciding.
The analogous lesson holds for any agent system hitting a hard SLA. If you want a deeper take on the loop-cost tradeoff (cheap reasoning agent + strong judge vs. the reverse), we wrote about that in AI Agent Loop Cost in 2026: Cheaper to Run a Cheap Builder and a Strong Judge — the budget math there maps almost directly to fan-out agent latency math.
What does the failure surface look like?
| Failure | Symptom | Mitigation in this pattern |
|---|---|---|
| Agent writes state directly | Replay broken; audit gap | Verdict-only contract; saga executes; tools are read-only |
| Single agent overloaded | Latency blowout, SLA breach | Cap iterations; wall-clock budget; conservative fallback verdict |
| Two agents agree because they share a model | Correlated wrong verdicts | Use different base models or different system prompts for each reasoning agent |
| Semantic-layer projection lag | Stale context → bad verdict | Monitor lag actively; treat agent inputs as best-known, not authoritative |
Collapse verdict back into an if |
Re-imports 90%+ false-positive problem | Use a verdict agent, not a metric threshold — it weights disagreement |
| Broker / CDC outage | Tier-two unable to reach events | Tier one continues to handle everything except the gray zone; gray-zone defaults to human review |
What this means for you
If you operate an event-sourced system and you have been told to "add AI," the answer is yes, but at the right layer. The work that pays off is not "wire the LLM to the event store" — it is building the semantic layer so the agent gets real cross-bounded-context context, defining the gray-zone trigger so the agent only fires on genuinely ambiguous events, choosing fan-out + verdict so the agent's reasoning is diverse and the final call weights disagreement, and re-emitting the verdict as an event so your saga, your audit trail, and your replay all keep working.
If you are earlier in your journey and still thinking about whether to build or buy the orchestration layer at all, How to Orchestrate AI Agents Like a Company: A 5-Layer Framework covers the broader control-plane decisions, and The AI Agent Control Plane: Building the Missing Layer That Stops Agents goes deeper on the missing governance layer that almost every fan-out system needs. For teams who want to see the same set of concerns applied to research-flavored multi-agent flows, How to Build a Multi-Agent AI Research Automation System in 2026: The Environment-First Playbook walks that version end to end. And if your concern has shifted from "build it" to "stop it from sprawling across every team," AI Agent Sprawl Is the New Shadow IT: A Governance Guide for 2026 is the right next stop — the tier-two agent pattern here is itself one of the early sprawl vectors if you do not lock the gray-zone trigger.
FAQ
Q: What is an AI agent in an event-sourced system? A: An autonomous LLM- or SLM-driven program that consumes events from an append-only log, reasons over a per-decision projection of those events, calls read-only tools to enrich its context, and re-emits its decision as a new event on the bus. The event store stays the single source of truth; the agent is just another event producer-consumer in your saga.
Q: When should you put an AI agent into an event-sourced pipeline rather than a rule or ML model? A: Only when the case falls inside the gray zone — above the auto-approve threshold and below the auto-decline threshold of your tier-one rules or ML engine. Everything else should never touch a language model; the tier-two agent exists to handle ambiguity, not volume.
Q: How do you keep a sub-500ms SLA with an LMM agent in the loop? A: Use in-memory short-term memory only, cap each agent to a small number of tool round-trips, set a wall-clock budget that breaks the loop into a conservative fallback (hold + human review) before the SLA is breached, and only call the agent for the small gray-zone share of traffic — not every transaction.
Q: Does the agent write to the event store?
A: No. The agent emits an event (for example, TransactionFlagged); the saga orchestrator and downstream bounded contexts execute the actual business effect. If the agent writes state directly you lose replay safety, auditability, and the reason event sourcing exists. Tools are read-only consumers of the semantic layer.
Q: Why use a verdict agent instead of an if statement over the two reasoning agents' scores?
A: A simple threshold collapses the tier back into a rule and re-imports the false-positive problem. A verdict agent can weight disagreement and arbitrate between two divergent readings, which is the actual capability you paid fan-out + compute overhead to get.
Q: What database backs the semantic layer? A: Anything that supports an event-log + change-feed or CDC pattern. Azure Cosmos DB's change feed is purpose-built for durable replayable event sourcing (Microsoft Learn); a relational events table plus a streaming CDC connector works the same way. The discipline that matters is the projection's "disposable and rebuildable" property — never let tools write to it, and keep it a separate read-optimized store from the event store.
Discussion
0 comments