Batch ETL can leave AI customer-support agents with stale, incomplete context when customers interact across several channels.
2
A shift-left architecture streams data with Kafka and Flink, transforms and embeds it, then writes it to a vector data store for agent access.
3
Real-time data can also improve AI answers to reporting questions because batch pipelines may leave those answers a day out of date.
Summary
The talk uses a fictional airline to explain why batch data pipelines make AI customer support unreliable. A customer may contact the airline through several channels, rebook a flight, and post an angry message, while the support agent sees only delayed or fragmented information. The proposed shift-left architecture uses Kafka and Flink to stream and transform data, create embeddings, and place the result in a vector data store. An AI agent can then access a current customer context instead of reconstructing it from several systems. The speaker connects the same architecture to reporting questions asked through AI agents, where batch data can produce answers based on an earlier point in time. The approach may also help applications that use reverse ETL to send data back into operational systems, since that process can take significant time. The talk is a concise architecture argument, supported by an airline support example rather than a detailed implementation.
Batch pipelines leave customer-support agents with incomplete context
The fictional airline has disconnected systems, data silos, and batch processing that delays the information needed by its AI support agent. Customers contact the airline through several channels, but the data is not current when the agent responds. Human support staff also spend time composing a customer case across systems. In the example, the AI does not know about a recent flight change or other interactions from the previous few hours, so it gives answers that do not make sense or misses information customers expect it to have.
Shift-left moves data preparation closer to the source of AI use
The proposed architecture replaces the batch process with real-time streaming. Kafka and Flink stream and transform the data, then the system embeds it and places it in a vector data store. The AI agent can use that store to build a unified, up-to-date customer context. The speaker presents this as a way to reduce the need for an agent to stitch together information from separate systems at query time.
Current customer context can improve first-contact support
In the revised airline scenario, the agent has information from every interaction, including a recent social-media post. The speaker says this lets the agent provide faster, higher-quality service and resolve issues on the first customer contact. The example is intended to show how real-time context can reduce repeated questions, fragmented answers, and outdated responses.
The architecture targets missing and stale information as common AI failure modes
During the discussion, the speaker identifies two common AI failure modes as having no information and having stale information. Streaming, transforming, and embedding data directly into a vector store gives the agent access to information sooner. This does not depend on the agent being able to bridge every operational system itself, which the speaker says may also be difficult for human support agents.
AI reporting answers can also suffer from batch delays
The shift-left design applies beyond conversational support. The speaker says people may ask an AI agent reporting questions, and a batch-backed agent may answer with data that is as old as the previous day. A conventional reporting interface might answer from a particular point in time, while the AI agent's answer can be delayed by the data pipeline behind it. Streaming can make those answers more current.
Reverse ETL remains a delay when applications need updated operational data
The discussion covers cases where data is sent back into operational applications through reverse ETL to support transactions. The speaker says this process can have significant delays, sometimes lasting as much as a day. For those cases, too, the speaker argues that moving streaming and data preparation earlier in the architecture can be useful.
Future airline use cases include larger contexts and multi-agent actions
After adopting the proposed architecture, the fictional airline is described as preparing for larger context windows and multimodal models, so customers could send pictures or other forms of communication. The speaker also mentions multi-agent systems that could let customers take actions in airline systems through conversation. These are presented as later extensions of the real-time data foundation.
"Streaming and transforming embedding data right into our vector data store gives the AI agent all the access it needs to provide high quality customer support."07:52
Who should watch
You are building an AI support agent that needs information from several customer-interaction systems.
Your current AI or reporting pipeline uses batch data and users complain that answers are out of date.
You send data back into operational applications through reverse ETL and need to understand where streaming could reduce delay.
