The first time an AI concierge gets it wrong, the customer doesn't think, "AI is still learning." They think, "This brand doesn't know who I am."

And they're right.

Retail is one of the most obvious use cases for GenAI agents. Customers interact with brands constantly, across every stage of the purchase and post-purchase lifecycle. The questions they ask sound simple:

  • "Where is my order?"
  • "Was my return processed?"
  • "Why was my delivery rescheduled?"
  • "What happened to my service request?"
  • "Did my exchange ship yet?"

These questions sound routine. But they're all questions about live operational reality, not product pages, not policy documents, and not last night's batch sync. They require the system to know what is true right now, while ServiceNow tickets, delivery events, and order state changes are all flowing in at the same time.

This is exactly where most AI concierge agents quietly fail.

The moment customer service becomes real-time

Imagine a customer contacts support and asks, "What's going on with my delivery?"

At that exact moment, several things may be happening in parallel. A delivery exception may have just been logged in ServiceNow seconds ago. The fulfillment team may have already triggered a re-shipment workflow. A replacement order may have been initiated but not yet approved. A carrier notification may have gone to the warehouse but not yet to the customer. The order management system may show "in transit" while ServiceNow already reflects "failed delivery attempt."

The customer isn't asking for a policy explanation. They're asking for the current truth.

Most agent architectures were never designed for this.

Why "just calling the data" breaks in production

The common approach looks reasonable at first. When a customer asks a question, the agent pulls from the order management system, the ServiceNow incident API, the carrier feed, the returns platform, and the scheduling service. It stitches those responses together and asks the LLM to reason over them.

In demos, this works. In production, it breaks.

The problem is subtle but it's fatal. There is no single "now." ServiceNow tickets update independently from order management. Carrier feeds update independently from warehouse systems. Each API call returns data from a slightly different point in time. Under load, those gaps widen. By the time the agent assembles its prompt, it's reasoning over a state that never actually existed.

The LLM doesn't know that. It fills in the gaps and produces a confident answer.

That's how you get responses that sound helpful and are operationally wrong, and why agents that look great in demos fall apart in production.

The failure customers feel immediately

Here's what that failure looks like in practice.

Customer: "Was my return processed?"
Agent: "Your return is open and being actively worked on by our team."
Customer: "I got an email saying it was completed."
Agent: "Let me check on that."

At that moment, the conversation is over. The customer no longer trusts the system. Escalation is inevitable. The AI concierge has become a liability.

Now contrast that with an agent that has access to real-time context.

Customer: "Was my return processed?"
Agent: "Yes, your return was completed 8 minutes ago. Your refund of $142.00 has been initiated and should appear within 3 to 5 business days. Is there anything else I can help you with?"

Same customer. Same model. The difference isn't intelligence. It's context.

What a retail concierge agent actually needs

To answer service questions correctly, an agent needs a continuously updated view of the customer's current situation. Not partial snapshots from five different systems, and not joins assembled at query time. A coherent, consistent picture that includes open and recently resolved ServiceNow incidents and service requests, order and fulfillment status, return and refund workflow state, carrier events and delivery exceptions, and what the customer was already told and when.

This context changes fast. A return can open and close a ServiceNow ticket in under an hour. A delivery exception can flip status multiple times in a single day.

The agent's job should be to reason, explain, and act after the truth is already established.

Why real-time context must be built before the agent runs

This is where the architecture has to change.

If you're building agent context by pulling from backend APIs at runtime, you're making the agent do join work it shouldn't have to do, and you're paying for it in latency, inconsistency, and production incidents.

If you're routing events through a stream processor into a vector store, you're solving the right problem with the wrong tool. Vector search is the right pattern for unstructured retrieval, for finding something relevant from a corpus of text. Customer service context is a different problem. You need the exact current state of a specific customer, joined across specific systems, deterministically. Using approximate retrieval for a problem that should have a deterministic answer adds cost, latency, and drift risk you don't need.

DeltaStream takes a different approach. Instead of asking agents to assemble context at runtime, DeltaStream continuously computes it as events flow in. ServiceNow incident opens, updates, and closures stream into Kafka. Delivery and carrier events stream in. Order state changes stream in. DeltaStream joins and enriches these streams in real time into materialized views that always reflect the current truth, a unified service context per customer, per order, per open service thread.

When the agent needs context, it makes a single request through DeltaStream's built-in MCP server and gets back a ready-to-use snapshot of the customer's current situation. The LLM can then do what it's good at: explain what's happening, choose the right next step, and respond with confidence.

A concrete example you can run yourself

To make this tangible, we built a full end-to-end example of a retail customer service concierge agent.

The example includes a data generator that produces realistic retail service events to Kafka, including ServiceNow incidents and requests, order lifecycle events, carrier updates, and customer notifications. DeltaStream continuously processes these streams and materializes the context the agent relies on.

Source streams from Kafka include:

servicenow_incidents for delivery exceptions, damage claims, and open service tickets; servicenow_requests for return authorizations, exchange requests, and re-delivery requests; order_events for order state changes and shipment events; carrier_events for delivery attempts and exceptions;
customer_notifications tracking what was sent, when, and through which channel.

DeltaStream materializes a unified customer_service_context view joining incident, order, carrier, and request state per customer, an open_threads view showing everything unresolved, and a recent_activity_24h rolling summary.

All of this is exposed through DeltaStream's built-in MCP server. When a customer asks a question, the agent fetches the current context in a single call and the LLM responds from a consistent, grounded picture of reality.

The full implementation, including the data generator, DeltaStream SQL, and agent code, is available in the DeltaStream examples GitHub repository:
github.com/deltastreaminc/examples/tree/main/RetailCustomerConcierge

Why connecting your source systems directly through MCP isn't enough

Everything has an MCP server now. And MCP is genuinely useful. It solves the connectivity problem and standardizes how agents talk to external systems. But MCP is a protocol, not an architecture. If your agent has five MCP servers, it still makes five calls at decision time. Five latencies, five failure modes, five systems returning data from five different points in time.

The question isn't whether your agent can connect to your systems. It's how many connections it's making while a customer is waiting for an answer.

DeltaStream has a built-in MCP server. Your agent makes one call to one endpoint and gets back one pre-joined, always-current record. You get the connectivity benefits of MCP and the consistency benefits of pre-computed context. They're not in competition. MCP solves how your agent talks to systems. DeltaStream solves what it sees when it does.

Wiring your source systems directly to the agent through MCP also doesn't fix the underlying join problem. You still rebuild join and enrichment logic per prompt, per agent, per team. As you add more agents across your org, different agents end up seeing slightly different versions of the truth. DeltaStream builds context once, continuously, in a governed way. Every agent sees the same truth. Every response is explainable.

The difference between demo agents and production agents

The difference isn't the model. It isn't the prompt. It isn't even the agent framework.

It's whether the agent reasons over fresh, consistent, real-time context, or improvises over stale fragments pulled from disconnected systems.

In retail, service reality changes fast. Orders flip state. ServiceNow tickets open and close. Customers ask questions while your systems are mid-update. An agent assembling context on demand will get it wrong at exactly the moments that matter most.

If you're building a customer concierge agent, this is the line you can't cross

If your agent is expected to represent your brand in live service conversations, it needs to know what's true right now. Not what ServiceNow said three minutes ago. Not what the order system returned before the carrier logged an exception.

Customers don't forgive confident wrong answers. They remember them.

DeltaStream makes real-time truth possible, continuously computing the context your agents need from the Kafka streams you're already running, so your concierge can stop guessing and start delivering the experience your brand promises.

If you're building enterprise AI agents, make real-time context your default. Make DeltaStream your Real-Time Context Engine.