Confluent's Sean Falconer tells LDS how streaming can keep an AI support agent aware of an order cancellation, and why the order system must still approve a refund. He explains source-version checks, replay isolation and topic-level permissions, while drawing a boundary between stream-processing guarantees and real-world actions. The interview supplies an architecture, without comparative results or a reproducible example.
A customer cancels an order. The support agent still says it is on the way. The agent may have read its information correctly; the information was already out of date.
That is the scenario Sean Falconer, VP of Product, AI Products and Strategy at Confluent, examines in written answers to Let's Data Science. His explanation follows the cancellation from the source database to an agent's response, then considers what happens when updates arrive late, a job restarts or an action is retried.
The useful distinction is between giving an agent current context and authorizing it to change something. A streaming view can help with the first. The system responsible for an order or payment must still enforce the second.
Why it matters
An answer based on yesterday's policy is a retrieval problem. A refund based on an order state that changed moments ago is also a transaction problem. Better context alone cannot settle whether the action is still valid when it reaches the business system.
Falconer is explicit about the authority boundary: "The agent reads and reasons from the streamed copy, but when it takes an action, like issuing a refund, that action goes to the order system, and the order system has the final say."
Following the cancellation
In Falconer's proposed workflow, change data capture, or CDC, reads the order database's change log and puts the cancellation into a Kafka topic. A Flink processing job combines order information with payments, shipments, accounts and support history into a shared customer view.
Confluent's Real-Time Context Engine, or RTCE, makes that prepared topic queryable through the Model Context Protocol, or MCP. The agent can then retrieve the cancellation and refund status together rather than assembling responses from several systems during the conversation.
This is a proposed architecture, not a customer deployment measured for this interview. The joins belong in the processing pipeline: current RTCE query documentation lists read-only lookups and filters, but does not support query-time joins.
A separate topic consumer can notify an application when an order changes, prompting another lookup. RTCE's lookup is not itself a subscription. Falconer also describes using Streaming Agents running in Flink to detect an event, such as a cancellation affecting an open support case, and initiate a workflow.
When a direct lookup is enough
Falconer does not argue that streaming is always the freshest route: "Querying the source system directly is the freshest answer you can get, so the case for streaming isn't about freshness for a single lookup."
His case for streaming is strongest when an answer spans several systems, query volume grows or the application needs to react without waiting for another customer question. Preparing a shared view can reduce repeated assembly work and direct query traffic to operational databases.
For a low-volume agent checking one order in one well-provisioned system, he recommends calling that system. Adding a streaming pipeline also adds components to operate; its value needs to justify that work.
Late events need rules about authority
Falconer recommends source versions, freshness limits and heartbeats that reveal when a source stops supplying updates. An application can wait while a small backlog clears, or hand the case to a person when sources disagree or stop reporting.
Those are design requirements. A record arriving last is not necessarily the newest business fact. Versions from separate systems are not automatically comparable, and processing tools do not independently know whether a shipping update should override a cancellation. Builders must encode those business rules and preserve the source information needed to apply them.
There is another gap between reading and writing. Falconer proposes attaching the version the agent read to its action request. The order system applies the request only if that version is still current; otherwise, the agent must read again.
That requires the receiving service to support and enforce the conditional change. Listening for updates helps the agent notice changes, but cannot close the race between its last read and a refund. The version check must happen where the business action is committed.
Exactly-once processing stops short of a refund
A restart can cause work to be replayed. Falconer's recommendation is to give an action a stable idempotency key, derived from the triggering event, so the receiving service can recognize a repeated request.
He warns: "The key has to come from the event, never the model's output, because a slightly different response would create a new key."
His suggested separation is to record an action request in Kafka, then let a separate executor call the payment or email service. The executor and receiving service must handle retries safely.
Apache Flink's fault-tolerance documentation distinguishes exactly-once state updates from end-to-end effects. The latter depend on replayable sources and transactional or idempotent sinks. A suitable Kafka configuration can support that guarantee; an arbitrary external API call does not inherit it.
For email, simply checking a sent ledger is insufficient if a crash can occur between sending and recording success. Our reading is that the executor needs a documented way to reconcile that uncertain outcome, rather than treating every retry as safe.
Replaying history without repeating actions
Falconer recommends a separate replay environment and output topics, with action tools replaced by stubs that record requests without sending emails or issuing refunds. Recorded tool responses can help recreate what the agent previously saw.
The team can compare requested actions with production records, then separately test restarts by processing events twice and interrupting execution. A stable key should identify the same intended action across retries.
For practitioners, an important check is that replay credentials and routing cannot reach production action tools. Falconer also suggests rejecting actions from events older than an agreed cutoff unless explicitly authorized. These are proposed safeguards; LDS did not execute this replay test.
Permissions must cover reading and acting
Confluent's access-control documentation confirms that RTCE queries are limited to topics an identity can read in Kafka. Topic-scoped DeveloperRead permits querying that topic; discovery and schema metadata have additional role requirements.
Falconer recommends separate agent identities and appropriately separated topics for teams or tenants. Filtering sensitive fields into a reduced topic is processing work. A prompt or query filter is not a substitute for an authorization boundary.
Tool permissions, customer identity, spending limits and approval requirements remain with the application or agent platform. Permission to read an order does not grant permission to refund it.
Falconer recommends tracing the request through its steps. For a useful investigation, our assessment is that the record should connect the agent identity, source versions, applicable permissions, action key and eventual result. A context-access log alone cannot explain the whole transaction.
What to watch
Confluent announced RTCE's general availability in May 2026. Current documentation supports MCP access on eligible AWS clusters, while the billing documentation identifies direct lightning-query API access as Early Access. Those access paths should not be described as having identical release status.
Confluent supplied no comparative results or reproducible example for this interview. The answers therefore do not establish improved task completion, measured decision-time freshness, fewer duplicate actions or lower total cost.
A useful evaluation would deliberately delay a cancellation, interrupt an executor and revoke an agent's access. Measure what the system refuses or repeats, alongside latency and running cost. Fast retrieval matters most when the application also knows when to stop.
Reporting note
This LDS Exclusive draws on four substantive written answers attributed to Sean Falconer and current official documentation. The order example is illustrative. LDS has not independently tested the architecture; engineering implications identified as our assessment are LDS's analysis.
Key Points #
- 1Falconer recommends a direct source lookup for a modest, single-system workload; streaming is most useful when context spans systems or must react to events.
- 2A fresh streamed view does not authorize a refund. The receiving business system must enforce versions, permissions and rules at the time of the action.
- 3External actions need stable event-derived idempotency keys and safe replay isolation; Kafka/Flink guarantees do not automatically extend to payment or email APIs.
- 4No comparative results or reproducible example were supplied, so this interview does not establish better task completion or lower operating cost.
Scoring Rationale #
Direct technical answers connect stale context, source authority, replay and permissions through one order-cancellation example, giving builders practical architecture choices while making the absence of comparative evidence explicit.
Sources #
Original reporting, with the public references used alongside it.
LDS Exclusive
Reporting based on written answers given directly to Let's Data Science by Sean Falconer, VP of Product, AI Products and Strategy, Confluent.
Practice with real Streaming & Media data
90 SQL & Python problems · 15 industry datasets
[Active Users in Target CountriesEasy](https://letsdatascience.com/problems/sql/active-users-in-target-countries-streaming)
[High-Rated Titles with ReviewsMedium](https://letsdatascience.com/problems/sql/high-rated-titles-with-reviews)
[User Churn Risk AssessmentHard](https://letsdatascience.com/problems/sql/user-churn-risk-assessment)
250 free problems · No credit card
See all Streaming & Media problems