--- title: "Event Sourcing for AI Conversations: Tracking Every Decision" description: "In AI-native systems, tracking what happened matters as much as making it happen. Event sourcing gives us full replay and audit capability." canonical: https://nowah.xyz/blog/event-sourcing-ai-conversations lastModified: "2026-08-07T03:48:00.154Z" --- # Event Sourcing for AI Conversations: Tracking Every Decision In AI-native systems, tracking what happened matters as much as making it happen. Event sourcing gives us full replay and audit capability. In a traditional web application, you store the current state. The user's profile has these fields. The order has this status. The account balance is this number. If you want to know how it got to that state, you check the logs and hope they are detailed enough. In an AI-native application, knowing the current state is not enough. You need to know every step the AI agent took to get there. Not just what it did, but what it considered, what it rejected, and why. When a user asks "why did you book me on this flight instead of that one," the system needs an answer. And "I do not know, the current state just says you are booked on this flight" is not acceptable. Event sourcing gives us this capability. Instead of storing only the current state, we store a complete sequence of events that produced the current state. Every agent decision, every tool call, every user message, every state transition is an event that is persisted and immutable. ## Why event logs matter more in AI systems ![Illustration for this section](https://pics.nowah.xyz/website-media/engineering-066-img-1.webp) In a deterministic system, you can reproduce any state by running the same code with the same inputs. If you know the input to a function and the function is pure, you know the output. Logging is nice for debugging, but strictly speaking, you could reconstruct what happened from the code and the inputs. AI systems break this assumption. The same input can produce different outputs because the language model is non-deterministic. You cannot look at a user's message and predict exactly what the agent will do. You need the actual record of what it did. This makes event logs a first-class component of the system, not a debugging afterthought. The event log is not just for troubleshooting. It is the source of truth for what the AI did and why. We emit events for every meaningful action in a conversation: - **UserMessage**: the user sent a message (content, timestamp, thread ID) - **AgentThinking**: the agent's reasoning before taking action (thought content, context snapshot) - **ToolCallInitiated**: the agent decided to call a tool (tool name, parameters, reason) - **ToolCallCompleted**: a tool returned results (tool name, result summary, duration) - **MemoryRetrieved**: the agent looked up stored preferences or context (memory keys, values) - **ResponseGenerated**: the agent produced a response to the user (content, options presented) - **BookingStepCompleted**: a step in the booking saga completed (step name, result, saga state) Each event includes a timestamp, a conversation ID, a trace ID for request correlation, and the full event payload. Events are append-only. They are never modified or deleted. ## Reconstructing AI decision chains When we need to understand why the agent made a particular recommendation, we query the event stream for that conversation and reconstruct the decision chain. Here is a real example. A user complained that the agent recommended a hotel that was far from the city center despite their stated preference for central locations. We pulled the event stream and found: 1. **MemoryRetrieved**: user prefers central, walkable neighborhoods (correct preference loaded) 2. **ToolCallInitiated**: hotel search with location constraint "city center" (correct parameter) 3. **ToolCallCompleted**: provider returned 12 results, 3 of which the provider tagged as "city center" (provider data issue: one "city center" hotel was actually 4km from center) 4. **AgentThinking**: ranking by preference match; hotel X scored highest on price and amenities (agent trusted provider's location tag) 5. **ResponseGenerated**: recommended hotel X as best match for central location preference The bug was in the provider's location data, not in our ranking logic. The agent did everything right given the data it had. Without the event stream, we would have spent hours guessing. With it, we diagnosed the issue in 10 minutes and added a distance verification step to our ranking pipeline. ## Debugging with event replay ![Supporting diagram](https://pics.nowah.xyz/website-media/engineering-066-img-2.webp) Event replay is the most powerful debugging tool we have for AI-specific issues. When we identify a bug, we can replay the conversation's event stream in a debugging environment. We load the exact sequence of events, restore the exact memory state, and step through the agent's decisions one at a time. At each step, we can inspect the agent's context, the tool results it received, and the reasoning it applied. Replay does not produce identical agent outputs (non-determinism again), but it produces outputs generated from the identical event history and context. This is usually sufficient to identify whether the issue was caused by bad data, bad reasoning, bad tool parameters, or a combination. We have caught entire categories of bugs through replay that would have been nearly impossible to find through traditional debugging. Context interference bugs where a memory from a previous trip inappropriately influenced a current search. State accumulation bugs where the conversation context grew large enough to degrade response quality. Ordering bugs where the sequence of tool calls in a particular conversation triggered an edge case in our orchestration logic. ## Storage and retention Events accumulate fast. A single conversation might generate 50-100 events. A busy day generates hundreds of thousands. Over months, the event store grows to billions of entries. We tier our storage by age. Recent events (last 30 days) are in our primary database for fast access. Older events move to compressed cold storage. Very old events (over 12 months) are either archived or deleted depending on data retention policies. The tiering strategy balances cost against utility. Most debugging and audit queries are about recent conversations. It is rare to need event replay for a conversation from six months ago. When we do need it, the cold storage retrieval adds latency but the data is still there. We also aggregate events for analytics. Instead of querying raw events to understand "how often does the agent search for hotels [before flights](/blog/testing-ai-agent-before-booking-flights) vs. flights before hotels," we run batch aggregation jobs that produce summary statistics. This keeps analytics fast without requiring real-time access to the full event stream. ## Privacy considerations Event sourcing for AI conversations creates a tension with privacy. We want comprehensive event logs for debugging and audit. We also need to respect user privacy and data protection regulations. Our approach is to be strict about what we store in event payloads. We log tool call parameters and results, but we redact personally identifiable information before persisting. A flight search event stores the route and dates but not the passenger name or passport number. A payment event stores the amount and status but not the full card number. For memory\-related events, we log which memory keys were retrieved but not necessarily the full values if those values contain personal information\. A "MemoryRetrieved" event might say "retrieved user preference: seat\_preference = aisle" but would not include "retrieved user passport: \[full passport details\]\." This redaction runs at the event emission layer, not at the storage layer. By the time an event reaches the event store, it is already sanitized. This is important because it means a database breach would not expose personal information from the event stream. We also respect deletion requests. When a user requests data deletion, we purge their events from all storage tiers. The audit trail for that user is gone. This creates a debugging gap (we cannot replay conversations for deleted users), but privacy outweighs debugging convenience. ## How this differs from traditional OTA logging [Traditional OTAs](/blog/ai-travel-booking-vs-traditional-otas) log page views, clicks, and API requests. Their logs tell you which pages a user visited, what they searched for, and what they booked. This is useful for analytics but limited for debugging user-reported issues. Event sourcing for AI conversations captures a fundamentally different kind of information. It captures decisions, not actions. Not "the user clicked the search button" but "the agent decided to search for [flights with](/blog/how-to-book-flights-with-ai-guide) these parameters because the user said this and the agent's memory indicated that." The event stream is a record of reasoning, not just behavior. Conversation events also accumulate faster than page-view logs. A single user interaction on an OTA generates a handful of events (page load, search request, results rendered). A single user message in a conversational AI generates dozens of events (message received, memory retrieved, reasoning step, tool selection, tool call, tool result, response generation). The data volume per user interaction is an order of magnitude higher. This higher resolution is the trade-off. More storage cost, more complexity, more privacy considerations. But the debugging and audit capabilities it enables are proportionally more powerful. And for a product where the AI's decisions directly affect users' travel plans and financial transactions, that power is not optional. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).